Please Review the Safety Card Before Airdropping Your Prototype
At a recent product and engineering leadership roundtable, a PM director said: “I built a prototype that shows exactly what I want, with more clarity than any PRD I’ve ever written and my engineers weren’t excited. They were resistant.”
Then a long debate followed about changing roles and AI code quality and the shifting job market. But I don’t think any of that was the real reason for resistance. I asked a simple question: “when did you share your prototype?”
A confused look and then a hesitant, “after I finished building it.”
And there was the problem: what feels like resistance is actually an ask for inclusion.
Not “give me a more detailed specification”, not “fix your prototype’s broken code”, but “bring me along for the ride”.
Think about what happens when a PM drops a fully-formed prototype on an engineer’s desk. The PM has spent hours, maybe days, in conversation with an AI tool, exploring options, hitting dead ends, making tradeoffs, arriving at a solution that feels right to them. They’ve weathered the whole storm of the creative process.
Then they hand over the sunny outcome and say: “Here. Build this.”
The engineer looks at it and feels... something. Not excitement. Something more like being airdropped into the eye of someone else’s brain storm. The air is calm here, but they can see the wreckage of decisions they weren’t part of. Why this data model? Why this flow and not the obvious alternative? What got tried and rejected? What tradeoffs were made, and who decided?
The prototype answers “what.” It doesn’t answer any of the “whys.” And without the “whys,” the engineer can’t do their job because engineering is the art of making good local decisions when you hit unexpected constraints, and you can only do that if you understand the intent behind the thing you’re building.
Nobody likes to be airdropped into the middle of someone else’s storm. But everyone loves a good story — a clear sequence of thinking they can follow, with a beginning, a middle, and a chance to shape the ending.
Every great PM already knows this. It’s why the best PRD reviews have never been signoff sessions. They’re conversations where the team pokes at the solution together: “What happens when the user doesn’t have an account?” “What if the API call fails mid-flow?” “This edge case seems ambiguous; can we nail it down right now?”
Traditionally we justified this discussion in terms of cost. Clarifying questions, surfaced in a review, cost an hour to resolve. The same questions surfaced after engineering is underway cost a week. Surfaced in QA? A month. Now, with the cost of rework plummeting, it feels like these tradeoffs no longer hold. But there was another subtler reason for these meetings.
The PRD review worked because the document felt open. It was words on a page. It was clearly a draft of thinking, not a finished product. People felt invited to push back, ask questions, and shape the direction. The document said, implicitly: “This is what I’m thinking. Help me think better.”
A working prototype sends the opposite signal. It looks done. It runs. It has buttons that click and screens that flow. Even if the PM knows it’s held together with duct tape and AI hallucinations, the engineer sees something that looks finished and hears: “I’ve already decided. Just make it production-ready.”
That’s the resistance. It’s not about the prototype. It’s about being handed a conclusion without the reasoning.
So what do you do? You don’t stop prototyping. The ability to express product thinking as working software is a genuine superpower that we shouldn’t lose.
But you turn over your thinking in stages, even if those stages happened quickly.
At SpecStory, we’ve been working on this problem, and we call the practice an intent review. It’s distinct from a code review. A code review asks: “Did we build it right?” An intent review asks: “Are we building the right thing and does everyone understand why?”
Here’s what that looks like in practice:
Share the problem before the solution. Before anyone sees the prototype, share the customer insight or the problem statement that motivated it. Give the team the same starting point you had. Let them sit with the problem for even a few minutes before you show them your answer.
Show your exploration, not just your conclusion. What did you try that didn’t work? What tradeoffs did you make? What alternatives did you consider? This is the “story” part — the sequence of thinking that makes the conclusion make sense. If you explored three approaches and chose one, show all three. Let the engineer see why this one won.
Name your confidence level. There’s a huge difference between “this is what I think we should build” and “these are two approaches I’m deciding between” and “this is an initial exploration, let’s iterate.” Naming where you are changes how people engage with what you’re showing them.
Invite the storm, don’t shelter people from it. The messiness of the creative process isn’t a bug, it’s where the best engineering input happens. When an engineer sees the problem space, not just the solution, they bring constraints and possibilities that make the product better. That’s not resistance. That’s collaboration.
Our new tools don’t change our humanity. AI can collapse the time between idea and prototype from weeks to hours, but it can’t collapse the human need to understand why before committing to what. An engineer who understands the intent behind a prototype will make a hundred good decisions during implementation that you never anticipated. An engineer who’s just been handed a thing to rebuild will ask you about every single one.
The fastest path to production isn’t a better prototype. It’s a team that shares your understanding of the problem.
So the next time you’re excited to show your team something you built (and you should be), pause for just a moment. Don’t airdrop them into the eye of your storm.
Tell them the story of the storm first. Then show them where you landed. Then ask them where they think you should go.
That’s not slower. That’s how you get there together.