The Problem We Don't Talk About

The same ritual unfolds across product teams everywhere. Designers sketch ideas that need engineering validation. PMs draft requirements that need dev or UX review. Engineers build features that need product iteration. And somewhere in between all these handoffs, magic is supposed to happen.

But instead, the time spent on coordination in the handoffs is silently devouring our most productive hours.

The real bottleneck isn't just our staff count, code architecture, or design systems; it's the cognitive tax of constantly translating ideas across disciplines. It's what we call "tool mismatch syndrome," and it's costing us more than we realize.

Familiar Process: Coordination Overhead & Tool Mismatch

Here is a picture we are all familiar with:

The PM began by doing competitive analysis and drafting requirements, only to hit a blocker that stalled progress. The designer then created mockups, which introduced their own context-switching overhead. When the time came for the PM-UX review cycle, the actual feedback was quick, but the asynchronous delay stretched things out significantly. Engineering estimation followed, which was fairly short but still added coordination overhead. Finally, implementation spanned multiple days, with the PM and designer already moving on to the next project.

The actual work was a matter of hours, stretched across multiple days, with countless context, tool switches, Slack threads, and "quick sync" meetings.

And after all that? We discovered the fix didn’t actually hit the mark. The real solution might have been as simple as a copy tweak, something we could have checked in minutes if we’d been set up for it.

New Process: The AI Flood Changes Everything

Enter the AI revolution; suddenly, the rules of the game have shifted. Tools like Cursor, Figma Make, and AI-powered design assistants aren't just making us faster, they're fundamentally changing how product teams operate.

Here's what that same feature development process looks like today:

PMs and designers can go from an idea to a live prototype for developers to take and deploy in production, within a few hours.

The Mindset Shift: From Coordination to Creation

This shift is fundamentally changing how product teams think about validation and iteration. We were driven by tool-dependent thinking, such as "our designs should be feasible for engineering," "let me create a ticket for dev," and "this requires a sprint planning discussion."
Now, we use a new framework we call outcome-dependent thinking. We ask ourselves, "How can we test this today?" "What's the fastest way to get user feedback?" "Can we add this to the system without a full development cycle?"

The real breakthrough isn’t technical, it’s psychological. Once you can move from idea to testable prototype in minutes instead of weeks, the old handoffs and bottlenecks start to disappear. We’re no longer locked in a linear chain, waiting on one another - we’re working in parallel, inside the same tool, speaking the same language. That shift frees us to focus less on process and more on what matters: delivering user value. 

When teams start working this way, something deeper shifts, too. The walls between roles begin to dissolve, replaced by a shared sense of ownership. Designers, engineers, and product managers no longer stay in their own swim lanes; they’re motivated by the same outcome and focused on collective problem-solving.

The Dependency Reduction Revolution

The most powerful aspect of AI-powered development isn't speed. It's the dependency reduction. When PMs can prototype interfaces and designers can implement these stencil templates, the traditional bottlenecks start to dissolve.

This doesn't mean roles become irrelevant. It means each discipline can focus on its highest-value contributions:

• PMs spend more time defining priorities and focusing on execution, and less time drafting specs and backlog grooming
• Designers focus on user experience innovation, not pixel-perfect handoffs
• Engineers tackle complex architecture problems, not simple UI changes

Empowering Non-Developers to Help Shape Product Outcomes

One of the biggest changes in our workflow is that designers and product managers are no longer limited to ‘handoffs’ - they can contribute directly to outcomes that shape code. This removes bottlenecks and lets each person act on ideas without waiting in line for developer bandwidth.

Metav (Designer): Over the past month, I’ve been able to expand my role into areas that used to feel off-limits, while still owning my regular UX work on new flows and features, for example:

1. Delivering long-pending UI fixes independently, that developers can directly import
2. Testing design concepts on the real product interface, helping me identify edge cases, and produce more accurate solutions faster 
3. Designing and implementing custom prototypes for our platform in just two days - something previously considered out of scope

‍Idan (PM): Last week, I created multiple live prototypes, which originated from customer feedback. The goal was to improve how admins navigate and act within the system, not just adjust the UI. Concretely, I:

1. Surfaced key data points that had been buried in the backend, so they’re visible where admins make day-to-day decisions.
2. Rolled out changes directly, such as copy updates or feature flags, without lengthy waits or bottlenecks.
3. Prototyped and validated faster by building and deploying testable flows or experiments within hours.

Because each increment was small and targeted, I could send it for devs to review and deploy, validate with users, and refine in real time - turning raw feedback into working product improvements within hours.

And the real added value? Developers are freed from the endless stream of "quick fixes" and "simple changes" that used to consume 40-60% of their time. Instead, they can refine and prepare the changes proposed by PMs and designers for production, while focusing on what they do best: tackling complex technical challenges, building robust architecture, and developing the foundational systems that power this autonomous product workflow.

Creating a New Pattern in the System

With more than 20 products already in the system, each with different user goals and data, creating a flow that meets all of their needs meant a long and complex process with many alignment sessions.

The challenge we identified was that, while our platform includes multiple modules, each with its own administrative pages and setup requirements, we didn’t have a structured configuration flow in place. Onboarding an admin into each module meant relying on manual documentation, which is time consuming and creates unnecessary friction for both administrators and our teams.

We set out to design a unified configuration and onboarding experience. This flow would guide admins across all modules in a consistent, structured way.

To move in that direction, our first priority was gathering requirements across teams and consolidating them into a single foundation. Rather than treating each module as its own effort, we aligned on shared patterns, constraints, and goals that could serve everyone. With this groundwork in place, we were able to shape a stencil or pattern - our master design and code direction - that enables updates in one place to intelligently cascade throughout the product.

Stencil-powered code and design systems mean that a change in one place can be intelligently propagated throughout the entire product experience, without an engineer making manually updatesing in every instance.

• Designers can build stencil frameworks, where, once a cross-system pattern or feature infrastructure is defined, AI can replicate and extend it seamlessly across the product. 
• This maintains consistency, empowering others with freedom to create, guided by principles, while massively reducing repetitive development work.
• PMs are no longer limited to writing JIRA tickets. With AI copilots and safe guardrails, they can directly prototype UI changes, quickly close backlog items, and even adjust business logic, transforming the role from requirement writers into lightweight builders.

Once we gathered all the needs and constraints, we used Figma and Cursor and asked for concrete referenced examples in our code base, rather than starting from scratch. This gave us about five variations, which we analyzed together, evaluating pros, cons, and what we liked. From this, we created three different real system prototypes and moved forward with a clear go/no-go decision.

Instead of relying only on Figma, Docs, or Jira tickets, we formalized the pattern in Cursor with the developers. As a result, once the front-end was built, anyone could reuse the pattern across 20+ products without needing a designer or developer, while still preserving consistency and quality.

Looking Forward: The New Product Development Paradigm

This shift isn’t just about moving faster, it’s about changing how product teams work at their core. By reducing dependencies and working with the same tools, PMs, designers, and engineers can act in parallel instead of waiting in line. Feedback turns into product changes the same day, and every role contributes directly to outcomes. Engineers focus on deep technical challenges, while PMs and designers stay closely engaged in shaping the product with a hands-on approach. The result is a way of building that’s both more efficient and more creative, where user value is delivered at the pace of imagination, without the overhead that used to slow us down.