Choosing what not to build: a scoping method for version one

Scoping a first release usually happens by addition. Someone lists the features, everyone adds the ones they care about, and the list is trimmed at the end when the estimate comes back too high. The trimming is done under time pressure, by whoever is loudest, and the result is a product that does eight things adequately and nothing convincingly.

The alternative is to scope by subtraction from a single job. It's uncomfortable, it produces a smaller product, and in our experience it's the difference between a launch that teaches you something and one that doesn't.

Name the one job

Write one sentence: the specific job a specific person is hiring this product to do. Not a market, not a segment, a job. "A PG owner needs to know who has paid rent this month without opening a notebook." That sentence is now the only thing with veto power over scope.

If the sentence has an 'and' in it, you have two jobs and you should pick one. Products that do one job convincingly get used; products that do two jobs partially get evaluated and abandoned.

Sort every feature into three buckets

• Load-bearing: the job is impossible without this. There are usually fewer of these than people expect, often three or four
• Supporting: the job is possible but unpleasant without this. These are real candidates, but only after everything load-bearing works end to end
• Adjacent: good ideas that serve a different job. These are not v1, regardless of how cheap they look or how much someone wants them

The adjacent bucket is where the argument happens, and it's worth having explicitly rather than by attrition. A feature being cheap is not an argument for including it. Every feature has a permanent cost in support, testing, and the attention of whoever uses the product.

Manual is a feature, temporarily

A surprising amount of v1 scope is automation of something that happens twice a week. Onboarding, verification, refunds, escalations: all of these can be done by a person with a spreadsheet and an inbox for the first few months, and doing them manually teaches you what the automated version should actually do.

We've shipped platforms where admin approval was a WhatsApp message to an operations lead for the first quarter. It cost almost nothing, and the automation that replaced it was better for having watched the manual process fail a few times first.

Decide what would make you cut it

Before the build starts, write down what you expect the launch to show and what result would make you stop. Not a target you'd celebrate, a threshold below which you'd change direction. Teams that skip this rarely stop, because after launch every number can be explained.

This is also the honest test of whether the launch is really a test. If there's no number that would change your plan, you aren't validating anything, and you should scope for the product you've already decided to build rather than pretending otherwise.

Build the unglamorous parts properly

Cutting scope is not the same as cutting quality, and the parts worth doing properly in a v1 are rarely the visible ones. Authentication, payment state, and the data model are expensive to change later and cheap to get right now. The visual polish is the opposite.

“A first release is not a smaller version of the final product. It's the smallest thing that can honestly answer the question you're asking.”

The method, compressed

1. 1Write the one job in a single sentence with no 'and'
2. 2Sort every proposed feature into load-bearing, supporting, or adjacent
3. 3Build all the load-bearing work end to end before touching supporting
4. 4Do low-volume operations manually and watch what happens
5. 5Write the number that would make you change direction, before launch
6. 6Spend the saved effort on the data model, auth, and payment state

The output is a product that looks smaller than the one in the original plan and tells you considerably more. That trade is almost always worth making.