Idan Yaniv is VP of Product Design at Via, an end-to-end software platform that powers mobility for modern communities. He began his career in design, co-founding Bevy Media Ltd. before continuing to build his expertise at inkod, where he progressed from UI Designer to Head of Design. Idan led design at Carbyne before joining Via in his current role.
In our conversation, Idan discusses how AI is reshaping product development by giving individuals more agency and changing the way teams collaborate. He shares why prototypes are becoming the new language of product development, where the next bottlenecks will emerge as execution accelerates, and how leaders can create the guardrails needed to maintain alignment without slowing innovation.
AI’s expansion of individual agency across teams
Over the past year, AI has expanded individual agency faster than organizational capacity. What kind of work have you seen collapse into a single role faster than you expected?
There have been a lot of experiments — people doing things that wouldn’t traditionally be part of their job description. I wouldn’t say there’s been a full collapse or merging of roles, but boundaries are absolutely becoming blurrier. With more agency, individuals are taking on areas that would have previously been unexpected.
From where I sit leading design, I see PMs prototyping their ideas very early on. That shift from a document and a hypothesis to tangible output, helps us raise questions, create alignment, and understand edge cases that otherwise would have required much more iteration. I find myself reviewing work with PMs and having design discussions that I previously would have had only with designers. PMs are using design agents and making decisions that enable designers to build on top of that work instead of starting from scratch.
Today, our product and design teams are often prototyping directly in our product repositories, and we are working to expand this approach — bringing product and design closer to the production code that ultimately ships to users. This brings us much closer to engineering and creates questions about how we reduce the translation between PMs, designers, and engineers, so that we’re continuously building on each other’s work, rather than starting over every time.
I wouldn’t say the roles are collapsing, but actually expanding. The boundaries that used to be much clearer are no longer distinct. I think that’s a good sign.
How does engineering feel about this shift? Do they find that when a design gets to them it’s better vetted, or do they feel isolated from the beginning of the process?
Our engineers are actually getting involved earlier because ideas are being shaped into tangible output much sooner. Once I have a prototype and a direction, I want engineering involved immediately to validate that we can build it.
While this approach has allowed engineering to begin work earlier, particularly on backend and architecture, it has also created confusion when there is no clear source of truth across multiple artifacts being developed simultaneously — for example, a product prototype, a design prototype, and Figma. Some designers, including myself, have submitted pull requests into production, but it’s very contained. These types of changes can be risky when they happen at scale in a mature company with millions of users, that’s why it’s important to have strong guardrails.
This could look very different in a startup environment where founders wear multiple hats and the priority is shipping quickly. The boundaries are probably even blurrier there. At Via, due to our scale, engineers now see expected outcomes in much greater detail much earlier. For example, most of our product surfaces are maps. Translating a static Figma file into expected map behavior is incredibly difficult. Think about Google Maps and the transitions between zoom levels, when points of interest appear and disappear. Those interactions are hard to communicate.
When you can prototype that behavior instead of describing it, it creates alignment, improves quality, and increases velocity. The next question becomes how to bring that work closer to production instead of rebuilding it from scratch.
AI tools sometimes introduce friction or disruption. What have you experienced? And are there forms of disruption that are actually healthy signs of adaptation?
Absolutely. I’ve spent a lot of time over the past year thinking about how we adopt AI and change our processes. I can share a good example from one of our mobile teams. They created an incredible prototype of a very complex feature that showed how the experience would work with all the interactions. It looked amazing. They started with just a few designs in Figma to create the foundation, and then built the rest in Cursor.
When we reviewed the concept, most of the conversation centered around the prototype. It created much better alignment between leadership, PMs, designers, and engineers. It also helped us discuss scope because we could clearly see what could be phased. Then the engineers asked, “Where’s the Figma? Where are the specs?” We only had a few screens in Figma. Everything else existed in the prototype.
This was a healthy problem to have because the prototype created so much value. It improved velocity, reduced manual work, helped leadership discuss scope, gave engineers feasibility input, and communicated interactions that would’ve been difficult to explain otherwise. Our challenge now is figuring out the best way to translate those prototypes into production code.
Where I do see negative friction, though, is when PMs begin prototyping. The goal should be to define the direction, not create the final design. But, once a prototype is shared with leadership and other stakeholders, it can begin to establish expectations for what the final product should look like. That puts designers in a difficult position because once a design direction has been established, it’s much harder to challenge or rethink it. We need to be very mindful of that dynamic.
AI is changing the shape of product development constraints, but it hasn’t eliminated them. As teams become capable of doing more with the same resources, where do you see the bottlenecks shifting?
In the short term, I still think the bottleneck is translation. Going back to the prototype example, if you have an advanced prototype that represents the ideal outcome, how do you reduce the amount of engineering work required to build it? We’re experimenting with spec Markdown files, building directly on our repos, and improving our design system so it’s more effective for agents, not just humans. That’s where we can unlock even more velocity.
The value already exists, but AI helps us reach alignment faster and build conviction earlier. The remaining bottleneck is how we hand that work off. Longer term, I think the challenge shifts toward distribution and communication. If you look at companies like Cursor, Claude, or ChatGPT, they’re shipping updates almost daily. Every time I open Claude, there’s another version. The question becomes: how do users absorb that much change?
This creates a different bottleneck around distribution, marketing, and communication. It’s a healthy problem because historically, engineering velocity was the bottleneck. Now, the bottleneck may shift to helping users understand and adopt what’s changing. So, in the short term, it’s about removing the translation layer, but in the longer term it’s about managing distribution and adoption effectively.
Why leadership needs stronger guardrails
As AI gives individuals more agency, are there responsibilities that should remain firmly with a specific function instead of becoming more fluid?
I think in the short term, yes. In the long term, it’s harder to say because the models are progressing so quickly. But, the trajectory is very clear — the AI models continue giving more agency to each individual. Right now, I think there’s a big difference in the level of risk that different stage companies are willing to take.
At Via’s scale, a big change will happen when everyone adopts more of a builder mindset. This will enable team members to cover more ground, while different functions shift from being executors to contributors earlier in the process.
For example, a PM can prototype without producing a polished design. Designers can help with system thinking, identify risks in the proposed solution, and continue shaping the prototype before taking ownership later in the process. Instead of a clear handoff, designers fade in as the direction becomes more mature.
With this model, I think each team member will be able to move farther ahead while other functions act as consultants until it’s time to take ownership. The important part is making sure no one gets too far ahead before designers or engineers have had the opportunity to provide input. That’s why the guardrails matter.
With development accelerating so quickly, what areas have become more prone to breaking down?
I think the biggest risk is around the fundamentals. A couple of years ago, we spent much more time defining the problem. Why are we solving this? Why is it a priority? How do we know this is the right opportunity? How do we build conviction that we’re solving something valuable? Only after we answered these questions, would we spend time designing the solution.
AI lets you move much faster into advanced stages of building, but that creates the risk of losing focus on what you’re actually trying to solve and why it matters. Ideation, experimentation, and building have become much cheaper, so it’s tempting to explore more and more solutions instead of staying disciplined about the problem.
I’ve seen teams make progress and then come back a week later with a prototype that’s completely different. My first question is always, “What happened? How did we get from here to there?” That’s the risk. When building becomes cheaper and faster, it’s easy to keep testing new ideas without staying anchored to the original problem.
Is there anything you’ve changed your mind about over the past year as you’ve watched your teams adopt AI?
Definitely. And I’m sure there will be more changes over the next few months because everything is evolving so quickly. A few months ago, I imagined a process that would give every function much more agency. There are already many examples of companies where PMs can go end to end — from defining the solution to merging small changes into production. I used to think that designers would move further into frontend development while engineers would spend more time on backend work, architecture, and other complex engineering challenges.
Today, I look at that differently. The question I keep asking myself is: what value are we actually creating? I’m no longer convinced that value comes from PMs producing designs that are nearly as polished as a designer’s work. The value is already enormous when PMs can build conviction, clarify requirements, and define the product direction through prototypes. That’s where designers can step in and build on that foundation.
Similarly, I don’t think designers necessarily need to make pull requests. Personally, I don’t want bugs assigned to me that I don’t know how to fix. So I’ve become a little more conservative. That might change again in six months, but today I think the biggest opportunity is for PMs to create strong prototypes that establish direction, and for designers to create polished prototypes that help engineers clearly understand what should be built. I’m focused on finding ways to help product, design, and engineering extend and build on one another’s work, rather than rebuilding at every handoff, and leveraging that to accelerate the path from idea to execution.
Preparing organizations for AI-native work
Are the behaviors of your team’s top performers different compared to a year or two ago?
Sure. Today, they’re using AI to articulate and visualize their thinking. When a PM is working through complex logic, it can be difficult to absorb that by reading a document. But when they build a quick prototype, it immediately becomes much easier to understand how different states and interactions work. The same is true for engineers. Instead of explaining backend architecture or APIs through documents or spreadsheets, they can build lightweight prototypes that communicate those ideas much more clearly.
The strongest performers understand the complexity they’re dealing with and use AI to visualize it in ways that create alignment and accelerate decision-making. The output isn’t always faster code or faster design. Often it’s those side projects — small demos and prototypes — that make the main work move much faster. From a leadership perspective, that’s incredibly valuable because it creates alignment early and reduces the need to revisit decisions later.
The second thing I see is constant learning. Our top performers are always testing new tools, those problems much cheaper to solve. Instead of leaving something in the backlog indefinitely, they’re asking, “Can I solve this now because AI makes it practical?” They’re using AI to cover more ground and create more impact.
Many established companies are layering AI onto structures designed for a different era. What organizational patterns do you think will feel outdated in a year or two?
The scale and complexity of work are going to increase dramatically. If every team member is running multiple agents, the challenge becomes understanding what’s happening across all of them. That will require rethinking how we work. I suspect that some of our existing rituals, like standups, will evolve. Those checkpoints exist to create alignment, but when agents are constantly producing information, we’ll need smarter systems that decide what to surface and determine when humans actually need to get involved.
This will likely lead to smaller teams. Startups are already showing us what’s possible in this regard. Companies that once required 50 people are now operating with five or 10 people supported by AI. For larger organizations like Via, that transition will take longer because the risks are much higher, but I do think we’ll eventually see smaller teams supported by intelligent agents that help coordinate work and highlight where human judgment is needed. Communication will become one of the biggest challenges, and it will force organizational change.
What advice would you give leaders who find their orgs are moving faster but are becoming harder to align?
To be honest, I’m still figuring this out myself. It helps to establish very clear guardrails around when different functions should become involved. As individuals gain more agency, they can do more work independently, but designers still need to be involved early enough to provide their perspective, identify risks, and shape the direction before it becomes fixed.
The same is true for engineering. Once there’s a clear direction, bring engineers in early to validate the approach and identify constraints that others may not see. Being explicit about when different functions should be involved — or at least informed — is critical during this transition. Until we reach a more agentic way of working, clarity around those collaboration points is one of the most important things leaders can provide.
What does LogRocket do?
LogRocket’s Galileo AI watches user sessions for you and surfaces the technical and usability issues holding back your web and mobile apps. Understand where your users are struggling by trying it for free at LogRocket.com.