Most MVPs are too big. Not because the team is undisciplined, but because nobody made the cuts explicit before the work started. The result is a v1 that does six things adequately and none of them in a way that proves the idea. This worksheet is a set of questions you answer in order. Each one forces a decision you'd otherwise discover halfway through the build, when changing course is expensive.
Work through it in one sitting, out loud or on paper, with whoever owns the budget in the room. Write short, plain answers. If you can't answer a question, that's the signal, you've found something to resolve before anyone writes code.
1. The single job
What is the one job this MVP does for the user?
Write it as a sentence: "It lets [user] [do thing] so they can [outcome]." One job. If you find yourself using "and," stop and pick the half that matters more.
This is the hardest question because every additional job feels reasonable in isolation. The discipline is holding to one. A scheduling tool that also handles invoicing, reminders, and reporting is four products. For a first build, choose the job that, if it works, makes the rest worth building, and the one that, if it fails, means you should stop.
Good answers are specific about the moment of use. "Helps with operations" is not a job. "Lets a dispatcher reassign a driver in under ten seconds when a job falls through" is a job.
2. The one user
Who is the single user or segment this is for?
Name a real person or a tight segment. Not "small businesses", that's a market, not a user. "An owner-operator HVAC company with three to eight trucks and no office manager" is a user you can picture, interview, and build for.
The narrower the segment, the sharper the product. You can widen later. Building for everyone at the start usually means building for no one, because the features that serve one group dilute the experience for the next.
If two segments come to mind, pick the one you can reach this month. Reachability beats size for an MVP, you need users you can actually put it in front of.
3. The success metric
What single number tells you this worked?
Pick one metric you can measure within weeks of launch, not quarters. It should move when the product delivers its single job and stay flat when it doesn't.
- Good: "60% of invited users complete the core action at least twice in their first week."
- Weak: "Users like it." You can't act on a feeling.
- Misleading: "Total signups." Signups measure your landing page, not your product.
If you can't name a metric, you can't tell success from motion. Decide now what number you'll check and where it comes from. If measuring it requires instrumentation, that instrumentation is part of the build, put it on the must-have list in the next step.
4. Must-haves vs. later
What is required for the single job, and what can wait?
Make two columns. Move everything that isn't strictly required to make question 1 true into the "later" column. Be ruthless. "Later" doesn't mean never, it means not needed to learn whether this works.
A feature is a must-have only if the single job is impossible without it. Login might be a must-have if the data is personal; it might be skippable for a first internal pilot. Notifications usually feel essential and usually aren't, for v1.
The "later" column is doing real work here. It's where you park good ideas without letting them expand the build. Keep the list, it becomes your roadmap once the MVP teaches you what's actually worth doing next.
5. The riskiest assumption
What has to be true for this to work, that you're not sure is true?
Every product rests on assumptions. Most are safe. One or two are not, and those are what an MVP exists to test. List your assumptions, then circle the one that would kill the project if it's wrong.
Common shapes:
- Demand: "People will change how they work today to use this."
- Feasibility: "We can pull clean data out of their existing system."
- Value: "This saves enough time that they'll pay for it."
The riskiest assumption is rarely the one that's most fun to build. If your biggest risk is whether anyone wants this, a polished UI doesn't reduce that risk, a conversation with ten users might. Naming the real risk keeps you from building confidently in the wrong direction.
6. How you'll test it
What's the cheapest thing that gives you a real answer to question 5?
Match the test to the assumption. Sometimes the cheapest test isn't software at all.
- A demand assumption might be tested with a landing page and ten sales calls.
- A feasibility assumption might be tested with a one-off script against a real data export, no interface.
- A value assumption might be tested by doing the work manually for one customer and seeing if they'd pay.
The goal is the maximum amount of learning for the minimum amount of building. If a spreadsheet and a week of manual effort can answer the question, do that before committing to a system. Our process leans on this, prove the risky part first, then build around what survives.
7. What "done" means for v1
How will you know the MVP is finished, not perfect, finished?
Write the exit condition before you start, or you'll keep adding "just one more thing." Done for an MVP means: the single job works for the one user, the success metric is being measured, and the riskiest assumption is being tested. That's it.
State it concretely: "v1 is done when an owner-operator can complete the core action end to end on real data, and we can see the success metric in a dashboard." Anything not required to hit that condition is, by definition, in the "later" column.
This question protects the budget. A v1 with a defined finish line ends, ships, and teaches you something. A v1 without one drifts into a v2 nobody scoped and nobody approved.
Takeaway
Fill this out and you'll have something most teams skip: an explicit, agreed-upon scope and a clear thing you're trying to learn. The point of an MVP isn't to build a small version of the final product, it's to answer the riskiest question as cheaply as possible, then decide what to do next with evidence instead of opinion.
If you've worked through the worksheet and want a second set of eyes on the cuts, or help building the version that survives them, get in touch. The hardest part is usually deciding what not to build, and that's easier with someone who has no attachment to the long list.