How to decide what goes in v1, and the three questions that resolve most arguments about it.
12 min read · Level 2
Every feature seems small, every one is justified by a real user need, and together they turn three weeks into six months. The cost is not only the time — a larger v1 is more to maintain and slower to change when you learn you were wrong, and the speed of that loop is what actually determines whether you find product-market fit. Doing something manually for the first ten customers is not a compromise; it is the cheapest specification you will ever write.
Scoping is deciding what is in v1 and — much harder — what is not. The useful discipline is to sort every proposed feature against the single workflow you are testing.
Three questions resolve most arguments: Does the core value work without this? Can a human do it manually for the first ten customers? Would a user abandon at this exact point if it were missing?
Because scope creep is the default. Every feature seems small, every one is justified by a real user need, and together they turn three weeks into six months.
And because the cost is not just time. A larger v1 means more to maintain, more to change when you learn you were wrong, and a slower loop — which is the thing that actually determines whether you find product-market fit.
The scheduling MVP. Proposed features and the verdict:
Feature — Verdict — Why
Generate a rota — In — This is the core value
Import drivers from CSV — In — Without it nobody can start
User accounts and login — In — Cannot save work otherwise
Email the rota to drivers — Out — They already have WhatsApp
Mobile app — Out — Rotas get built at a desk
Handle holiday requests — Out — Manual for now — we will do it for them
Multi-depot support — Out for v1 — But it excludes half the ICP, so it is next
Reporting dashboard — Out — Nobody asked. Nobody at all.
Note 'handle holiday requests': the answer is we will do it manually for the first ten customers. That is not a compromise, it is a deliberate technique — you learn exactly how the feature should work by doing it by hand, which is far cheaper than guessing and building.
First-time founders often keep features because a single customer asked. One request is not a signal; it is a data point. Wait for the pattern.
The second mistake: building the admin panel, settings page and billing system before anyone uses the product. For the first ten customers you can change a database row by hand and take payment by invoice. Both take minutes and neither needs building.
The third: cutting the thing that makes it work in order to hit a deadline. Cutting features is right; cutting the core workflow's quality is not.
Get it all out first, then sort. Arguing feature by feature as they arrive is exhausting and inconsistent.
If yes, it is out of v1. This alone removes most of the list.
For ten customers, almost anything can be done by hand — and doing so teaches you how it should work.
If they genuinely cannot proceed, it is in. If it is merely annoying, it is out.
Cut features come back as arguments. A written list with the reasoning ends the argument in ten seconds.
Doing it by hand for the first customers is a technique, not a failure. It is the cheapest possible spec.
Before starting the build, and every time someone proposes adding something to it.
Once you have real customers and product-market fit, this discipline loosens — then you are building for retention and expansion, not for a single test.
In Stripe's early days the founders would, on hearing that someone wanted to try it, offer to set it up there and then on the person's laptop. The practice became well known in startup circles precisely because it was so obviously unscalable — and it taught them exactly where integration actually broke.
Doing it by hand for the first customers is a technique, not a stopgap. It produces a specification you could not have guessed at.
The most reliable way for scope to grow is a single customer asking for something and the founder treating it as a requirement. One request is a data point. The pattern only becomes visible around the fifth or sixth time, and building before then reliably produces features nobody else wanted.
Write requests down, do not build them. Wait for the pattern, and keep the cut list with reasons so the argument only happens once.
Create a free account to read the rest and apply it to your own startup.