Build the smallest thing that proves it

“Minimum viable product” has been used so loosely that it now mostly means “the version we ship before we run out of money”. That is not the same idea, and the difference costs people a lot.

A first version is an instrument for finding out what you are wrong about. Judge it on how quickly it does that, not on how much it does.

What is the actual question?

Before deciding what to build, write down the thing that would sink this if it turned out to be false. Usually it is one of:

• Will anyone use it? People will say they want something and then not use it. This is the most common and most expensive assumption.
• Can we do the hard part? Some builds hinge on one technical unknown. Nothing else matters until that is answered.
• Does it save the time we think? For internal tools especially: the theory is an hour a week, and the practice is that people carry on using the spreadsheet.
• Will they pay? Different from will they use it. Free use proves much less than people assume.

Whichever one it is, the first version exists to answer that. Everything not serving it can wait.

What does “smallest” actually look like?

Smaller than feels reasonable.

If the question is whether the office manager will use a job-overrun report, the first version is one list, for her, on one screen. No login if you can avoid it. No date filter. No export. Certainly no charts.

That feels unfinished because it is unfinished. It also tells you within a week whether she opens it, which is the only thing you needed to know. If she does, you now know what to build next, and you will be surprised by what she asks for.

The instinct to add the date filter comes from imagining her frustration. But you are guessing at which frustration. Ship it and find out.

What can you leave out?

More than you think. Things that feel mandatory and usually are not, at first:

• Accounts and permissions. If three people will use it and they all trust each other, a shared link buys you weeks.
• Editing and deleting. Being able to see the thing is often the whole value. Changing it can come later.
• Settings. Every configuration option is a decision you are avoiding making. Make it, hard-code it, and change it if someone complains.
• Empty and error states. Necessary before real users. Not necessary before the one person sitting next to you.
• Anything for scale you do not have. Building for a thousand users when you have four is not prudence, it is procrastination with a good excuse.

What you cannot leave out

Two things, and they are non-negotiable.

It has to be real. A clickable prototype answers a design question, never a behavioural one. People treat a demo differently from a tool they rely on.

It has to be used by a real person doing real work. Feedback from someone imagining their workflow is worth very little. Feedback from someone mid-task is worth almost everything.

What happens next

You will learn one of three things. The assumption held, and you build the next piece with confidence. It did not hold, and you have saved months. Or, the most common, it held in a different shape than you expected, and the next version is not what was on your original list at all.

All three are wins. Only the first one feels like one at the time.

This is also why we work in a queue rather than to a scope. Building the smallest thing first only helps if changing direction afterwards is free, and under a fixed scope it is the most expensive thing you can do.