What should version one of a new product contain?

The question that decides everything

Not “what does this product need in order to be good?” — that question has no natural stopping point, and answering it is how twelve-month version ones happen.

The question is: what has to be true for this to work at all?

Every product plan rests on assumptions. Some are safe. One or two are load-bearing, and if they are wrong, nothing else matters. Version one exists to test those.

Finding the load-bearing assumption

Write your plan as a list of statements that must all be true. For a booking product it might be:

1. People want to book this kind of thing online rather than by phone.
2. We can get accurate availability data.
3. Suppliers will keep their listings current.
4. People will pay a booking fee.

Now rank them by how much it would hurt to be wrong, not by how likely they are. In that list, (3) is usually the killer — plenty of marketplaces have died of stale listings — and it is the one most plans assume away.

Version one should be whatever tests the top of that list.

What this looks like in practice

If the risk is will anyone use this, build the thinnest possible real version and put it in front of real users. Not a prototype with dummy data — something that genuinely works for a narrow case.

If the risk is can we even get the data, build the data pipeline and nothing else. No interface. Prove the data exists, is accurate and can be refreshed, then decide whether to build the product on top of it.

If the risk is will people pay, build the payment path early even if everything around it is crude. Intent to pay and actual payment are different things and only one of them is evidence.

If the risk is can this be done technically at all — common with computer vision, hardware or anything at scale — build the hard part first, in isolation, before any product thinking happens.

What to leave out

Almost everything, and specifically:

• Accounts and login, unless the product is meaningless without them.
• Settings and preferences. Pick sensible defaults. Preferences are a way of avoiding a decision.
• Admin interfaces. You can edit the database directly for a while. It is unpleasant and entirely survivable.
• Edge cases. Handle them manually and keep a note of how often they occur. That note tells you which ones to actually build.
• Anything described as “we’ll need it eventually”. Eventually is not now, and about half of it never arrives.

The thing you must not leave out

Analytics. A version one that ships without measurement teaches you nothing, which defeats the purpose of building it.

Decide before launch what result would count as success and what would count as failure, and make sure you can tell the difference. “We’ll see how it goes” produces a product nobody can honestly evaluate six months later.

How you know version one is scoped right

Two tests.

The sentence test. You can describe it in two sentences without using “and also”. If you cannot, it is still two products.

The disappointment test. Looking at the scope should feel slightly uncomfortable — it should seem like less than the product deserves. That discomfort is the correct feeling. A version one that feels complete is a version one that will take too long to teach you anything.

After it ships

Resist the urge to immediately build everything you cut. Half of it will turn out not to matter, and you now have real users telling you which half.

That is the entire return on building something small: not that it was cheaper, though it was, but that the next decision is made with evidence instead of opinion.