How to decide what goes in v1, and the three questions that resolve most arguments about it.
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.
Apply this to your own startup in My Full Journey (free account).