2026-11-04
November 4, 2026
AI made the demo cheap. It did nothing to make the belief behind the demo true.
A product owner on your program shows up on Monday with a working prototype. It was built over the weekend, it clicks through, it has real-looking data, and the sponsor is already saying "can we just ship this?" Two years ago that demo would have taken a team six weeks and a discovery budget. Now it takes an afternoon and a good prompt. That is a genuine gain, and I am not going to argue otherwise.
But look at what the demo actually proves. It proves the screen can exist. It does not prove anyone wants the screen, that they will change their behavior to use it, that it can run at your scale, or that it survives contact with legal. A prototype is a fast answer to one question: can this be built? Programs fail on the other questions.
The failure mode has changed shape. We used to lose months because discovery was slow and expensive. We now lose months because discovery is fast and convincing, and a convincing artifact quietly retires the skeptical questions nobody got around to asking. The TPM's job at this stage is not to slow the prototype down. It is to make sure the team knows which belief the prototype was built to test, and which beliefs it left untouched.
That is what assumption mapping is for, and it is the method in today's issue.
Start with where the risk lives. Marty Cagan's framing of the four big risks (SVPG, 2017) is still the cleanest checklist: value (will people use it and pay for it), usability (can they work out how), feasibility (can we build it with the time, skills and technology we have), and business viability (does it work for sales, legal, finance, brand). A vibe-coded prototype is a strong instrument for exactly two of those: usability, because people can react to something real, and a first pass at feasibility. It is a weak instrument for value, and nearly blind on viability.
Notice what that means for how teams now behave. The cheap risks get tested thoroughly, because the tool makes them cheap. The expensive risks get skipped, because the prototype already "feels validated." Effort flows to what is easy to measure, which is the oldest failure in program management in a new costume.
The new discovery bottleneck is selection, not production. Paweł Huryn makes the sharpest version of this point in his 2026 discovery guide: when shipping is the cheapest experiment, "speed multiplies waste," and the metric that matters becomes time to learn, the gap from idea to validated insight. His practical split is worth stealing. Safe, reversible ideas can simply be built behind a feature flag and measured in real use. High-risk or hard-to-reverse assumptions still need a deliberate experiment before anyone commits. The skill that separates those two groups is not prompting. It is judgment about reversibility and consequence, which is a program-management skill.
A prototype's polish is a confidence signal, and it is miscalibrated. Peter Gerdes at Framna puts it well in Not every prototype deserves to survive: a prototype can look nearly finished while hiding architectural, security and scalability gaps, and past a point more prompt iterations add polish rather than insight. His rule of thumb is that an hour or two of focused experimentation usually shows whether a concept is promising. Dean Peters arrives at the same place from the product side in Vibe First, Validate Fast, Verify Fit: use the cheapest prototype that tells the harshest truth, and keep probes disposable, narrow and honest. The word that matters there is harshest. Most demos are optimized to be flattering.
What the TPM adds. Three moves, in order.
First, make the hypothesis explicit before the prototype is shown. "We built this to find out whether X" is a sentence that should exist in writing before the demo, because after the demo everyone will remember the experience and forget the question.
Second, put the untested beliefs on the wall next to the tested ones. The sponsor's excitement is attached to the whole bundle (value, viability, scale) while the evidence covers one slice. Your job is to make that gap visible without making anyone feel foolish for being excited.
Third, rank the gaps by what kills the program if wrong, not by what is easy to check. Compliance review, a data-access dependency owned by another org, a pricing assumption nobody has said out loud: these are usually the load-bearing walls, and they are rarely the thing a prototype reveals.
Why this is leadership work, not a workshop. For directors and VPs the stakes are the roadmap. A prototype-driven org will approve more ideas faster, and the approval criterion quietly drifts from "we have evidence" to "it looks real." If you do not install a different gate, your portfolio fills with convincing things nobody validated, and the cost shows up two quarters later as rework, scope fights, and a team that cannot say why it is building what it is building.
The fix is cheap and cultural: make "what is the riskiest thing we have not tested?" a standing question in every review where a demo appears.
Try this week. Take the next prototype or demo that lands on your program and, before the review, write three lines at the top of the doc: the one assumption this prototype tested, the one assumption that would kill the program if wrong and has no evidence yet, and who owns finding out. Open the review by reading those three lines aloud.
What it is. A team exercise that turns an idea's hidden beliefs into explicit, testable hypotheses and plots them on a 2x2 of importance versus evidence, so you test the most dangerous unsupported belief first rather than the most convenient one.
When to use it. Right after a prototype, concept or proposal gets traction and before a team commits budget. It is especially useful when a sponsor is enthusiastic and the evidence base is thin.
How to run it:
When NOT to use it. When the idea is reversible and cheap enough that shipping it behind a flag is itself the test; mapping a hypothesis you could simply measure by next Tuesday is ceremony.
Source and detail: David J. Bland, How assumptions mapping can focus your teams on running experiments that matter (Strategyzer).
Not every prototype deserves to survive (Peter Gerdes, Framna) — A clear case for treating AI-built prototypes as exploration, not foundations: polish hides architectural and security gaps, and iteration past the first hour or two adds shine rather than insight. Useful to forward to a sponsor who wants to "just ship" the demo.
Vibe First, Validate Fast, Verify Fit (Dean Peters) — Published in June 2025, so older than the rest, but the "proof-of-life probe" idea and the rule of the cheapest prototype that tells the harshest truth hold up well in the current tooling.
What Is Product Discovery? The Ultimate Guide for PMs, 2026 Edition (Paweł Huryn, The Product Compass) — July 2026. The argument that shipping is now the cheapest experiment, and the split between build-and-measure for reversible ideas and formal tests for risky ones, is the most usable framing I found this year.
"The most expensive way to test your idea is to build production-quality software."
— Jeff Patton, as cited by Dean Peters
Don't miss what's next. Subscribe to Critical Path: