Test the riskiest assumption first.

A team can now go from idea to clickable prototype in an afternoon. The screens look finished, the flow works and the demo is persuasive. So the prototype often ends up testing the part of the product that was least in doubt: whether it can look good.

The expensive surprises come from elsewhere. Nobody has the problem badly enough. The team can't build the hard part. The AI behaves differently on real inputs. Or buyers like it and don't pay.

What a prototype can and can't tell you

Brian Balfour of Reforge put it plainly: "prototypes are for discovery, not delivery" ("The AI Prototyping Mastery Ladder", 11 December 2025). In an earlier piece (20 November 2025) he listed what they test well: interactions, whether people understand a workflow, edge cases and points of confusion. He also listed what they test badly: whether a problem exists, and whether there is demand.

That split is the whole point. A prototype is one kind of test among several. Choosing the test is a judgment call, and it should follow the uncertainty rather than whichever tool happens to be open.

Find the assumption that would sink you

Write down everything that has to be true for the product to work. Then ask two questions of each: how unsure are we, and what happens if we are wrong? The assumption that is both uncertain and fatal goes first. Everything else waits.

Then match the test to the kind of uncertainty.

Three projects, three different risks

Motionshift. Motionshift was an AI video startup that Lucie co-founded and led on product. Continuous interviews and an assumption map set the direction. The team chose to build first for marketers on a deadline. Designers looked like the natural first users, but their expectations of what the tool could do were very high. Later, the team needed to know whether users would find the new AI features useful before the tool could do them. So the AI flow was storyboarded and compiled as a film in After Effects, because the product wasn't coded yet. Another assumption failed in the build itself: users wanted a flexible timeline, and a team of three could not build one. The editor kept only the essentials, and a timeline came back later for an ad's key sections alone.

Movido. Movido is a physio app for the days between appointments. The quiet risk was the bad day, when a patient in pain can't follow the plan. At first the only option on an exercise was to start it, so a patient could push through or quietly skip. We explored swapping and postponing, dropped swap, and let patients postpone by three days and say why. The prototype was refined round by round with Movido's product manager.

LEGO. For LEGO's employee event app, which Lucie managed, the first question was structure. The sitemap came first, with the open questions marked. Two dashboard versions were wireframed, because the right one depended on how people would use the app during the event. The team also named a risk no screen would show: a social wall is empty on the first morning of an event, so the recommendation was to add photos from the previous year.

None of these risks would have shown up in a polished demo.

What to do Monday

• List every assumption your product depends on. Aim for twenty.
• Score each one on uncertainty and on the damage if it's wrong. Circle the one that scores high on both.
• Write the result that would prove it wrong, before you run any test.
• Pick the cheapest test from the table that fits that kind of uncertainty.
• Put a date on the decision: continue, change or stop.

AI expands what a small team can build in a week. Judgment decides what is worth building at all. Finding the riskiest assumption is how our Product & Strategy work begins.

Where this leadsProduct & Strategy