What goes in version one

One complete path, not several partial ones

The most common way a first version goes wrong is that it contains four features, each about seventy per cent finished, and no way for anybody to actually do anything.

This happens because features are how we talk about products, and paths are how people use them. A user doesn't experience your feature list. They arrive with a job, and either they finish it or they don't.

So pick one path. One kind of user, doing one job, from arriving to finishing. Build that path all the way through, including the boring parts: the empty state, the error when they type the wrong thing, the email that confirms it worked. Then stop.

The parts people cut that they shouldn't

Three things get cut from version one and shouldn't be, because cutting them means nobody can complete the path.

The failure case. What the user sees when the payment declines, the upload is too large, or the third-party service is down. If the answer is a blank screen, the path isn't complete.

Getting data out. People will want to export, download or forward the thing they made. Leaving this out feels harmless and produces support requests you answer by hand.

The first-run experience. An empty account with no data in it is where every user starts and where almost no version one has been tested.

The parts people keep that they shouldn't

Settings. Almost every setting in a version one is a decision the team couldn't make. Make the decision instead and remove the setting. You can add it back once somebody asks twice.

The second user type. Admins, managers, viewers. Every additional role multiplies the states you have to build and test. One role in version one.

Anything about scale. Caching, queues, sharding, a job runner. None of these belong in version one unless the thing genuinely does not work without them. Slow is a fine problem to have and it means people are using it.

Design polish beyond legibility. It should be clear, aligned and readable. It does not need to be distinctive yet, because you're about to change most of it.

How to hold the line once you've drawn it

Version one gets bigger through good ideas, not bad ones. Bad ideas are easy to refuse. A genuinely good idea, arriving in week three from someone whose judgement you trust, is what actually moves the date.

The mechanism that works is boring: everything raised that isn't on the plan gets written down and not started. It sits on a list. Once a month you go through the whole list together and decide what moves into the plan. Nothing gets added any other way.

Writing something down is what stops it being started. It also stops the idea being lost, which is the objection people raise, and it turns "no" into "not this month", which is easier to say and easier to hear.

The test

Give it to somebody who has never seen it, with no instructions, and watch. Don't help. If they finish the job, version one is done. If they get stuck, the thing they got stuck on is the next piece of work, and it's a better piece of work than anything on your feature list.