Copy this into a doc and fill it with the founder before any proposal. If a field is hard to fill, that’s the risk — resolve it before scoping, not during the build.
The worksheet
1. User
Who is the single user this MVP serves? Name a person, not a segment.
Example: “A founder running outbound sales herself.”
2. Problem
What painful, frequent problem does that user have? One paragraph, their words.
Example: “Pipeline review takes 20 minutes of clicking through stale records.”
3. Must-win workflow
The one workflow that must work end-to-end at launch. Everything serves this.
Example: “Open pipeline → see scored deals → approve drafted outreach in 30 seconds.”
4. Non-goals
What we are explicitly NOT building. Write at least three.
Example: reporting dashboards, mobile app, Salesforce migration.
5. Risks (riskiest first)
What could kill this? Order by danger, not convenience.
Example: AI enrichment quality; email deliverability; sub-100ms UI.
6. Acceptance criteria
What does “demoable” mean per slice? Observable behavior, not code.
Example: “Rep completes Friday review live on staging in under a minute.”
7. Launch metric
One number that says the MVP worked.
Example: “Review time under 60 seconds for 4 consecutive Fridays.”
FAQ
When should we fill this in?
Days 1–2 of scoping, on the extraction call. It should take one sitting, not one sprint.
Who fills it in?
Founder + Timebase together. The founder brings the problem; we bring the constraint thinking.
What if the must-win workflow is unclear?
Then scoping pauses. An unclear workflow is the most expensive bug you can ship — resolve it before any slice is priced.
Can we change non-goals later?
Yes — as new slices, priced separately. The list exists so changes are decisions, not drift.
Used in: 10-Day MVP Scoping Playbook · Build vs Buy: Internal Tools · CRM case study