Practical founder guide
MVP scope worksheet
Identify one risky assumption before expanding a feature list.
An early product can have very few features and still be expensive to learn from. If the intended user, task, or uncertain assumption is unclear, a short feature list may produce a smaller version of the wrong product.
This editorial worksheet connects the scope of a minimum viable product to a decision. Deliver enough of an outcome to learn something useful, while stating honestly what the test can and cannot establish. The worked example is hypothetical.
Start with one user doing one task
Complete:
[A specific user] needs to [complete a task] when [a situation occurs]. Today they use [the current alternative].
“Freelance designers preparing a weekly review of unpaid invoices” is easier to investigate than “all small businesses.” This is a choice for the test, not a claim that the eventual business must serve only that group.
If the current alternative is unclear, begin with the customer interview worksheet. A proposed feature is not a substitute for understanding the task.
List assumptions before choosing features
| Assumption | Evidence now | Cost of being wrong | What to learn next |
|---|---|---|---|
| The problem happens in the intended context | ____________ | ____________ | ____________ |
| The consequence matters to the user | ____________ | ____________ | ____________ |
| Your approach improves the task | ____________ | ____________ | ____________ |
| You can deliver it responsibly | ____________ | ____________ | ____________ |
| You have a workable way to reach or charge users | ____________ | ____________ | ____________ |
Choose an assumption with meaningful uncertainty and a consequence for your next decision. A technically interesting test can be the wrong priority if no one has demonstrated a reason to use the outcome.
YC’s MVP lecture and transcript discusses delivering a limited initial product, learning from initial users, and restricting scope. The tables here apply those principles to a decision record; they are not official YC templates.
Match the test to the question
| Uncertainty | A possible test | What it would not prove |
|---|---|---|
| Whether the problem occurs | Discuss or observe a recent task with consent | That someone will buy a solution |
| Whether an explanation is understood | Show a truthful offer and ask the reader to explain it back | That the service works |
| Whether the outcome helps | Deliver a limited version manually, disclosing that work | That delivery will scale economically |
| Whether a workflow is usable | Let an intended user try a working prototype | That they will keep using it afterward |
| Whether someone will commit | Offer a clearly defined trial or paid pilot you can fulfill | That broader demand or retention is established |
A waiting list measures willingness to leave contact information under the offer shown. It does not demonstrate that the product delivered its outcome. Track each step separately rather than calling every signup a validated customer.
Never imply a feature is available when it is not. Explain what a trial actually provides. Some products need substantial safety, technical, or regulatory work before a live trial is appropriate; a small scope does not remove those responsibilities.
Copy the one-page scope worksheet
| Decision field | Your plan |
|---|---|
| Intended user and task | ____________________ |
| Assumption being tested | ____________________ |
| Current evidence and limitations | ____________________ |
| Smallest useful outcome to deliver | ____________________ |
| What is manual or simulated, and how you disclose it | ____________________ |
| What is deliberately outside this test | ____________________ |
| Recruitment or access method | ____________________ |
| Observation or measure | ____________________ |
| Decision criterion chosen before testing | ____________________ |
| Time, spending, and other stopping limits | ____________________ |
| Safety, privacy, and consent requirements | ____________________ |
| Review date and next decision | ____________________ |
Choose the criterion for your context. This worksheet supplies no universal conversion rate or participant count. Explain why the proposed evidence would justify the next small step and what would remain uncertain even if the criterion is met. Strategyzer’s Test Card explains the value of defining an assumption, experiment, measure, and threshold in advance.
Worked example: a hypothetical reminder review
A founder wants to help designers organize payment reminders. Instead of building automated billing, they propose a manual trial: use a redacted invoice summary to prepare a review list, which the designer checks before sending reminders themselves.
The founder discloses the manual work. They exclude bank access, automated messages, and handling client funds. Before the trial, they specify what to observe: whether the designer can use the list to complete a review, where corrections are needed, and whether the designer returns when the task recurs.
This fictional example is not evidence that the product is wanted. A useful manual delivery would still leave questions about repeated use, willingness to pay, acquisition, data protection, and the cost of operating the service.
Save the plan, then add results separately
- What happened: actual observations, including incomplete attempts and problems.
- What you infer: which assumption became more or less plausible, and why.
- What else could explain it: recruitment bias, an unusually helpful facilitator, timing, or a changing task.
- What you will do: repeat, alter the approach, investigate another uncertainty, or stop.
If a result is ambiguous, report it as ambiguous. Changing the criterion afterward can make a weak result appear stronger without improving the product. Use what you learned to choose the next test rather than expanding scope automatically.
For a practical weekly rhythm, connect your review to the founder action plan. The useful output is a better next decision and an honest evidence record, not a larger backlog.