Everyone's talking about how AI is changing product development. And they're right. Roles are blurring. Designers write code, developers make design decisions, and the distance between an idea and a working frontend shrinks by the week.
This is real. It's happening. And it's not the interesting part.
The interesting part is what hasn't changed at all: how organizations make business decisions about what to build.
The speed that nobody talks about
Gary Hamel put it better than I can:
"Right now, your company has 21st-century Internet-enabled business processes, mid-20th-century management processes, all built atop 19th-century management principles. What constrains the performance of your organization is not its operating model, nor its business model, but its management model."
He wrote that about management in general. But it hits hardest when you look at product investment decisions specifically.
Think about how a new product idea actually moves through a typical organization. Someone has an idea. It goes into a slide deck. That deck gets presented to a steering group. The steering group has questions. A revised deck goes to another forum. Someone asks for a business case. The business case goes through finance. Another steering group reviews it. Eventually, after weeks or months of approval tourism, someone gives a green light.
Or doesn't. And the idea dies in a queue.
Meanwhile, the team that would actually build the thing could have had a working prototype ready in a fraction of that time. Not a mockup. Not a wireframe. A working, testable, clickable version of the idea that lets people react to something real instead of interpreting slides.
Why slide decks are the wrong tool for fast decisions
A slide deck is an abstraction of an abstraction. It describes what something might be. It invites interpretation. And interpretation invites debate. And debate invites another meeting.
I've watched this cycle up close many times. A 40-page deck gets presented. People nod. Someone raises a concern. The concern gets "taken offline." A follow-up meeting is scheduled. Three weeks later the same deck comes back with two slides changed and the conversation starts from scratch.
The problem isn't the people in the room. They're doing their best with the information format they've been given. The problem is that a slide deck asks people to imagine something they could just see and touch instead.
A prototype changes the conversation. You don't debate what something "might feel like." You click through it. You see what works and what doesn't. You react to something concrete instead of negotiating an abstraction.
That reaction, whether it's "yes, this is what I meant" or "no, this is completely wrong," is worth more than three alignment meetings. Both answers move you forward.
Prototyping isn't new. What comes out of it is.
I want to be clear about something: prototyping is not a new idea. Designers have been building interactive prototypes in Figma for years. Clickable flows, testable screens, realistic enough to put in front of users and get real reactions. That capability existed before AI entered the picture.
What's changed is what the prototype becomes afterward.
Before, a Figma prototype was a communication tool. It showed what to build. Then a separate team translated it into code, which took weeks or months and introduced a whole new round of interpretation gaps.
Now the prototype and the frontend converge. AI tools turn a designed concept into working code. The gap between "this is what we're imagining" and "this is what it actually does" has collapsed. The prototype isn't a step before the real thing. It's the beginning of the real thing.
That changes the economics of prototyping from "a nice design phase to have" into "the fastest route from idea to decision to production."
The structural problem underneath
But let's go back to the Hamel quote for a moment. Because the slow approval process isn't just inefficiency. It's a structural problem.
Most governance models were designed for a world where building was expensive. When building something wrong cost millions, it made sense to have multiple review layers. The cost of a slow decision was lower than the cost of a bad one.
That equation has flipped. Building is fast and relatively cheap now. Rebuilding is fast too. The most expensive thing you can do is wait. Wait for alignment. Wait for the next steering group. Wait for someone two levels up to say yes.
Organizations that still run mid-20th-century management processes, as Hamel calls them, are paying a decision tax on every initiative. Not because the governance is wrong in itself, but because it was designed for constraints that no longer exist.
The organizations that figure this out first will move faster. Not because they have better AI tools, but because they changed how decisions get made about what to build.
What this means in practice
If you're sitting in an organization where good ideas get stuck in approval loops, try this: next time you have a concept that needs a green light, don't build a deck. Build a prototype.
Not a polished product. A working version that's good enough to answer the question: should we invest in this or not?
Put it in front of the decision-makers. Let them click through it. Let them react to what they see, not what they imagine from reading slides. You'll get a decision faster, and it'll be a better one because it's based on something real.
The bottleneck in product development isn't technical anymore. Any competent team with current tools can build fast. The bottleneck is organizational: how quickly your company can decide what's worth building.
A prototype won't fix your governance model. But it will get you through it a lot faster.
