What should a working prototype actually prove?

Key idea 1 of 6

The demo answers the wrong question

The team has ideas. Sketches, a deck, half a decision, maybe a demo or three, and pressure to make one of them real.

Nobody can say yet which is worth building, who it helps, or what it would cost to run. Nothing exists that anyone can actually use.

A demo does not fix that. A demo proves the idea can be demonstrated, which was never in doubt. The questions that decide whether to fund it are different:

• Does anyone reach for this on an ordinary day?
• What happens when the inputs are the real ones rather than the ones on the slide?
• What does it cost to keep running once the person who built the demo has moved on?

Working software is the fastest way to find out.

Sometimes the risky uncertainty is technical. Can two systems be made to talk to each other at all? Will the data hold up the workflow? Then feasibility is the question, and the prototype answers it. More often the idea can plainly be built. The open question is whether it should be.

Key idea 2 of 6

Building got fast, so judgment got expensive

AI is making the production layer of design fast. On Lucy Learns, the dog-training app this article comes back to, AI built working versions in an afternoon.

A month earlier, repainting every illustration in the app would have been another five days in a chat window. Once the pipeline existed, it took one afternoon.

That does not make the work worthless. It makes it strange to sell it as the production of artifacts. If a prototype that once took two weeks now takes two days, the important question becomes: did we prototype the right thing?

The scarce part shifted toward diagnosis, framing, taste and context. Knowing which questions matter. Knowing when an apparently reasonable answer is wrong for this organization. Knowing when to stop generating possibilities and commit.

So a prototype should be judged by the quality of the decision it produced, not the speed at which it appeared.

1 afternoon

to repaint every illustration in Lucy Learns, a change that a month earlier would have taken five more days

4

image models in the blind pilot, order shuffled, filenames hidden

Key idea 3 of 6

Real code, real inputs, a real Tuesday

Three things separate a prototype that proves something from one that merely exists.

It runs in real code, so the constraints that will decide the product show up now rather than in month four of the build. It runs on real inputs, the messy ones. A workflow that works on clean sample data has proved nothing about the data people actually have.

And it is used by the people who would use it on a Tuesday, in the place they would use it. Not by the sponsor in a conference room.

The last one is where most prototypes stop short, and it is the one that answers the question.

A prototype has

• Real code, so the constraints show up now rather than in month four
• Real inputs, the messy ones people actually have
• Real users, on a Tuesday, in the place they would use it

A demo has

• The clean sample data from the slide
• The sponsor, in a conference room
• Proof that the idea can be demonstrated

Key idea 4 of 6

A hallway found what no demo would have

I built a training app for our dog. The professional trainer’s handouts were written for a person sitting still, and practice happens in a hallway with a leash in one hand. It is a small product and every decision on it is mine, which makes it useful evidence here.

I judged the versions AI built. The write-up says which decisions the AI made faster and which it never touched. The two decisions that mattered most were both made by using the thing rather than by looking at it.

Voice commands came out after a couple of sessions. The build was fine. The idea was wrong, and the mistake was mine, one the AI did not flag up front either.

A handler saying next step brightly at a phone is saying words in the cue voice, at a dog. The dog is being taught that words in that voice are for her, and she was distracted by every command. No demo would have found that. A hallway did, and listening came out.

The illustrations went through a blind pilot: four image models, the order shuffled, the filenames hidden. Two pictures failed and were redrawn until strangers read them right. The first versions looked finished. Finished is not the same as understood.

Key idea 5 of 6

A prototype ends in one of three calls, with the next cost attached

There are three honest calls:

• Build: it works, people reached for it, and here is what the next step costs.
• Kill: it did not, and here is what we learned that stops us spending on it again.
• Park: the idea is sound and the moment is wrong, and here is what would have to change.

1. Buildwhat the next step costs
2. Killwhat stops us spending on it again
3. Parkwhat would have to change

A prototype that talks a team out of something expensive has paid for itself. The cheapest product decision a team can make is the one it makes before the build starts. A working prototype makes that decision available.

Key idea 6 of 6

AI is how it gets built, not what it is for

AI is part of how the thing gets built, and sometimes part of what the idea is. It is not what the prototype is for.

Where it genuinely helps, you will see it in the build. Where it does not, you will hear that too. A prototype that flatters the tools that made it has stopped being an instrument and started being a demo again.