Conviction matters more than ever. AI is making it easier to skip.
When everything is fast, the slow work of understanding the problem becomes the only real advantage.
Building conviction has always been one of the hardest part of product management. Reaching the point where you genuinely understand the problem well enough to commit a team to solving it.
That was true before AI. It’s even more true now. Because AI has made almost everything else in the product process faster and cheaper: generating ideas, writing specs, creating prototypes, producing analysis. The one thing it hasn’t made cheaper is the judgment to know which idea is actually worth building. And in a world where ideas are abundant, that judgment is the only thing that separates the teams that create real impact from the ones that stay busy without getting anywhere.
Ideas used to be expensive. Now they’re free.
A year ago, going from a vague concept to something tangible took weeks. You needed design time, engineering input, stakeholder conversations. The cost of exploring an idea acted as a natural filter. You only invested in the ones you had some reason to believe were worth it.
Now a PM can generate ten feature concepts in a morning. They can vibe-code a working prototype in an afternoon. Real screens, real interactions, real enough that it looks like something you could ship next week. The cost of exploring has collapsed. And that’s genuinely exciting. Cheaper exploration means faster learning, more experiments, better feedback loops.
But it also means the filter has disappeared. When ideas are cheap, the temptation is to explore everything and commit to nothing. Or worse, to commit to whatever looks most impressive in a demo, rather than whatever solves the most important problem.
The abundance of ideas makes conviction more valuable, not less. Because conviction is what tells you which of the ten prototypes is worth the six months of engineering time it will take to build it for real.
Not every company can experiment its way to conviction
When Meta wants to test an idea, they can put it in front of three billion people. They can run hundreds of experiments simultaneously. They can afford to build things, test them, and throw them away, because the cost of a failed experiment is negligible relative to the learning they get from their scale.
Most companies don’t have that luxury. If you’re a fintech with a few million customers, or a B2B company with a few thousand, every feature you build carries real cost. You can’t afford to turn every prototype into an experiment and let the data decide because you will end up confusing your customers with a new experiment every week.
At Meta’s scale, conviction and experimentation can happen in parallel. You can ship fast, learn fast, and iterate fast because the volume of feedback is immediate and enormous. At most companies, conviction has to come first. You have to understand the problem deeply, form a clear view on the solution, and commit, because you don’t have the scale to let experimentation do the thinking for you.
AI makes it tempting to behave like Meta. To generate lots of ideas, build lots of prototypes, and assume the best one will win. But without Meta’s scale, that approach just burns time and resources on things that looked good in a demo but never had a real reason to exist.
Speed makes you skip the thinking
There’s a subtler risk that I’ve started noticing when interviewing PMs or talking to other product and engineering leads. When you go from zero to a polished prototype in an afternoon, you skip the slow, unglamorous part of the process where real product thinking happens.
In the old world, writing a spec or a Confluence doc forced you to think through the details. You had to describe the edge cases in words. You had to explain what happens when the user has no data, or when the payment fails, or when they’re in a market with different regulatory requirements. The act of writing made you confront the complexity, because you couldn’t hand-wave it in a document. You had to explain it.
A vibe-coded prototype lets you skip all of that. You build the happy path, it looks beautiful, and you move on. The edge cases, the error states, the what-ifs that only surface when you slow down and think carefully: none of them exist in the prototype because the prototype never forced you to think about them.
And those details are often what make or break a feature. The difference between a product that works in a demo and a product that works in the real world is almost entirely in the details that nobody finds exciting. The loading states. The empty states. The error messages. The flow when someone changes their mind halfway through. The experience for the user who doesn’t fit your assumptions.
Excitement is not the same as understanding. And the risk is that you commit to building something you haven’t actually thought through, because the prototype made it feel like the thinking was already done.
The prototype creates false certainty
There was an accidental advantage to the old way of communicating ideas. When you wrote a Confluence doc with wireframes and a flow diagram, the roughness of the artefact set the right expectations. Nobody looked at a box-and-arrow diagram and thought the product was two weeks from launch. The medium said: this is early. Let’s discuss.
A vibe-coded prototype says something very different. It looks like finished software. And when something looks finished, people treat it that way. Stakeholders see a polished prototype and unconsciously assume the hard problems have been solved. They start asking when it goes live.
But the hard work doesn’t exist yet. Authentication, scalability, compliance, integration with existing systems, performance under load. The prototype skipped directly to the surface and left everything underneath for later.
I’ve seen this play out. A PM demos a prototype, leadership gets excited, timelines form in people’s heads. Then engineering starts building, and reality arrives. The disappointment is worse than if you’d shown a wireframe, because the expectation was set so much higher. This erodes trust between product and engineering over time. And it all started because the prototype created certainty where there should still have been questions.
What conviction actually looks like
Conviction is not the same as enthusiasm. Enthusiasm says this idea is exciting, let’s build it. Conviction says I’ve studied the problem deeply, I understand why this solution is the right one, I know what the risks are, and I’m prepared to commit the team’s time to it.
Conviction requires you to answer hard questions before you start building. What is the real problem? Who has it, and how badly? Why will this solution work when others haven’t? What are the edge cases, and how will we handle them? What does success look like, and how will we know if we’ve achieved it?
None of these questions get easier because you have a beautiful prototype. In fact, the prototype can make them harder, because it gives you something concrete to fall in love with before you’ve done the work to justify that love.
The PMs I trust most are the ones who can show me a great prototype and then immediately tell me everything that’s wrong with it. They know the edge cases they haven’t solved. They know where their understanding is weak. They know what they’d need to learn before committing engineering time. That’s conviction. It’s not certainty about the solution. It’s clarity about the problem and honesty about the gaps.
Use the tools. Do the thinking anyway.
I want to be clear: I’m not arguing against AI tools or vibe coding. I use them. My teams use them. The ability to make ideas tangible quickly is a genuine step forward for how product teams work.
But the tools don’t replace the thinking. They change the medium, not the process. You still need to understand the problem before you commit to a solution. You still need to think through the edge cases before you build the happy path. You still need conviction before you need a prototype.
Frame every prototype before you show it. Say the words out loud: this is a concept. None of this is built. Here’s what we still need to figure out.
Show the hard problems alongside the pretty screens. Put the complexity on the table. Make the gap between prototype and production visible on purpose, because if you don’t, the prototype will hide it for you.
Match the fidelity to the stage of your thinking. If you’re still exploring the problem space, a rough sketch or a doc might be the right medium. Save the polished prototype for when you’ve built conviction about the direction.
Separate exploration from commitment. Use prototypes to explore ideas. Use conviction, evidence, and proper scoping to decide what to actually build. The prototype is an input to the decision, not the decision itself.
The real competitive advantage
AI is making everything in product faster. Ideas, prototypes, specs, analysis. All of it is getting cheaper every month. The one thing that’s not getting cheaper is the judgment to know what’s worth building.
In a world where every team has access to the same tools, the teams that win will be the ones that build the deepest conviction about the right problems before they start building. Not the ones who ship the most prototypes, or move the fastest, or have the most ideas.
Speed is a tool. Conviction is a strategy. The best product teams have always known the difference. AI just made it more important to get it right.
My book, Navigating the Product Galaxy: A Practical Handbook for Product Managers, is available now on Apress, Amazon, Walmart, Apple and Google Books. If you’re building your PM career, it covers everything from strategy to stakeholder management to leading teams.