What is the smallest useful version of a product?

Why “minimum” can become unusably small

“Minimum viable product” is one of the most useful ideas in product development, and one of the most misread. In practice, the emphasis often falls on minimum: build as little as possible, as quickly as possible, and see what happens.

The problem is that a product can be so minimal that nobody can actually get value from it. When that version fails to attract or keep users, you learn very little. Was the idea wrong, or was the product simply too thin to judge? You can’t tell.

Thinking about the smallest useful version moves the emphasis on to usefulness. The question becomes: what is the least we can build that still lets a real person solve their real problem? That version may be very small, but it has to work.

Define the core outcome

Start with the outcome a user should get, written from their point of view. Not “the app has a calendar”, but “I can see at a glance what is happening today”. Not “users can upload a CV”, but “I know whether this role is worth applying for”.

A good core outcome is specific enough that you could watch someone and tell whether they got it. If you have more than one, pick the one that matters most to the problem you set out to solve.

Remove everything that does not support the outcome

List every feature you think the product needs, then go through the list and ask of each one: does the core outcome fail without this? If not, it waits.

Things that usually wait include:

• settings and customisation
• multiple user roles and permissions
• integrations with other tools
• admin dashboards and reporting
• support for rare edge cases

This step is usually uncomfortable, because many of the removed items are genuinely good ideas. They are just not the ideas being tested.

Preserve enough quality for a realistic test

Small doesn’t mean careless. The parts that remain need to be good enough that people judge the idea, not the rough edges. If a product is confusing, slow or unreliable, people stop using it for reasons unrelated to whether the idea is valuable.

Focus quality on the core path: the steps a user takes to reach the core outcome. Everything on that path should be clear and dependable. Everything off it can be plain.

Decide what can remain manual

Much of what a mature product automates can be done by hand at the start. Onboarding can be a conversation. Data can be entered by you. Reports can be written up rather than generated. Payments can be invoiced.

Doing things manually has two benefits. It lets you test the outcome sooner, and it shows you exactly which parts of the process matter before you commit to automating them.

Choose one user and one main use case

A first version that tries to serve everyone usually serves nobody well. Pick one type of user and one main situation in which they use the product, and design for that.

For example, a product for older adults and their families might start by focusing on the person looking at the display each day, and leave the family-management side simple until the core display is right.

Define the evidence the first version should produce

A first version is a test, so decide in advance what it should tell you. Will you learn whether people complete the main task? Whether they come back? Whether they would pay? The guide on testing a software idea before building too much covers how to choose these signals.

If the version you are planning can’t produce the evidence you need, it is the wrong version — no matter how small.

Examples

• Daily View’s first version is a calm display of the date, time, today’s activities and what happens next. Its open question is how much information is useful before clarity becomes clutter, which is exactly the kind of question a small, focused first version can answer.
• Role CV’s live beta concentrates on one outcome: helping a person assess a role against their experience, see the gaps that matter and prepare a more tailored application.
• Proper Treathas started with the parts that define the experience — the voucher design and the QR-based redemption flow, including partial redemption — before building the full sale and redemption system.

When to add more

Add to the product when evidence tells you to: when users repeatedly hit the same limit, when a manual step becomes the bottleneck, or when a missing feature is clearly stopping people from getting the core outcome.

Be wary of adding features because individual users request them. A request tells you someone has a need; it doesn’t tell you the best way to meet it, or whether other users share it. Look for patterns, and add the smallest change that addresses them.