Main idea

A mockup already lets you iterate: you look at a screen, you follow a journey, you spot that a button is in the wrong place or that a piece of information is missing. What it puts on show is an intention, and the objections it invites bear on the intention.

A working product gives you something else. You don't look at it, you use it: you wait for a list to load, you repeat the same gesture three times, you discover that a filter is useless because the real data doesn't have the expected shape. That friction isn't a flaw in the representation, it is a property of the product, and no mockup can produce it since it holds neither the real data, nor the real delays, nor the repetition of use.

The shift is gradual and almost goes unnoticed: the thing first looks like a mockup, then it starts working, then you show it, then people ask for improvements, then they ask when they can use it.

Why it matters

This changes what you build first. As long as producing a usable version cost far more than producing a representation, the mockup was the only reasonable entry point into an iteration. When a Product Manager assembles screens, internal APIs and data modifications in four days, the representation stops being the economical step.

It also moves the moment of user feedback: it no longer lands on what you plan to do, but on what exists — and therefore on objections no specification review would have surfaced.

Nuances and limits

The advantage lies in the realism, not in the fact that it is code. A product fed by a test dataset shows no more real friction than a mockup: it shows less, because it gives the impression of having been put to the test.

And the mockup retains a use the product doesn't take over: exploring several directions without paying for any of them. A running product makes a direction hard to abandon, precisely because it exists.

Open questions

• Past what level of stakes does the cost of abandoning a usable version exceed the gain of having built it rather than drawn it?