A working prototype used to cost a week of somebody's time, so it got built only when a question was worth a week. That cost did the thinking for you: it forced a decision about what was worth finding out.
It now costs an afternoon, and the forcing function went with it. Teams are producing more prototypes than ever and learning about the same amount, because the expensive part was never the building.
A demo that impresses is not validation
This is the failure mode, and it is comfortable enough that most people do not notice they are in it.
You build the thing, you show it to people, they say it looks great, and you write that down as evidence. It is not evidence. Almost nobody tells you your idea is bad while looking at something you obviously worked on, and a polished artefact makes that reflex stronger rather than weaker.
Generation makes this worse in a specific way. It is now easy to produce something that looks finished before you understand the problem, and a finished-looking thing invites reactions to the surface rather than the premise. You get feedback on the button colour for an idea nobody needed.
The prototype that teaches you something has a way to come out badly. If there is no result that would change your mind, you have not run a test.
Write down what would make you stop, before you build
This is the whole method, and it takes about fifteen minutes.
Before generating anything, write one sentence: the thing that has to be true for this to be worth building. Then write what you would see if it were false. Be concrete enough that somebody else could look at the result and reach the same verdict without you in the room.
Bad version: we think users want faster reporting. Nothing can falsify that. Better version: if we show this to six people who complained about reporting, at least half will try to use it unprompted, and the ones who do will get to a report without asking us how.
The second one can fail on a Tuesday afternoon. That is the property you are looking for.
Match the prototype to the question you are actually asking
Most wasted prototypes answer a question nobody was asking. There are four common questions and they want different artefacts.
- Does anyone want this? You need a description, not a build. A landing page, a written pitch, a short demo video. Building working software to test desire is the most expensive way to ask.
- Can people actually use it? You need a clickable front end with no real logic behind it. Whether the data is fake is irrelevant, because you are watching where somebody hesitates.
- Does the hard part work? You need a narrow technical spike on the one risky mechanism and nothing else. No interface at all.
- Will they pay, or change how they work? You need the smallest real thing that delivers value once, to one person, by hand if necessary. This is the only one where the software has to genuinely function.
AI has made the second and third cheapest by a wide margin, which is why teams reach for them by default. That is fine when they are the question, and expensive when the real doubt was the first one.
What AI prototyping is good and bad at
Knowing where the tool is strong changes what you can attempt in a day, and knowing where it is weak stops you drawing a conclusion the prototype cannot support.
- Good: plausible interfaces fast, several alternatives instead of one, throwaway code you were never going to keep, and filling a screen with realistic-looking data so people react to something concrete.
- Bad: anything depending on your real data, your real volumes, or your real edge cases. A prototype that works on invented data has told you nothing about the messy input it will actually meet.
- Dangerous: it looks finished at a stage where it is not, so viewers assume decisions have been made that nobody made. Say out loud that it is a prototype, and it will still be misread. Make it look rough on purpose if the audience is senior.
A loop that fits in a day
None of this needs a sprint, and giving it a sprint is how it becomes a small project with a sunk cost attached.
- Morning: write the claim and what would falsify it. One sentence each, by hand, before you open anything.
- Then: pick the cheapest artefact that could produce that signal, using the four questions above.
- Afternoon: build it and stop when it can answer the question. The urge to keep polishing is the urge to stop testing.
- Next day: put it in front of the smallest number of real people who could tell you. Watch what they do rather than asking what they think.
- Then write the verdict down before you discuss it, so the conversation cannot quietly rewrite what you saw.
The part that got harder
Prototyping is not the skill any more. Anybody can produce something that looks convincing, and the number of convincing-looking things competing for a team's attention went up sharply.
What is scarce is being willing to define failure in advance and then honour it. That was always the difficult half, and it used to be protected by the cost of building: you thought carefully because a week was expensive. Now that an afternoon is cheap, nothing forces the thinking except a decision to do it.
The teams that get value out of fast prototyping are not the ones producing the most prototypes. They are the ones that kill ideas quickly, which is only possible if somebody wrote down what killing it would look like.