Skeleton · MVP scope
MVP scope & cut-list
Template · v1 → first paying customer · 3 sections
An MVP that takes 6 months wasn't an MVP — it was a v1. Use this template to lock scope, define what proves it worked, and what triggers a pivot.
The skeleton
MVP SCOPE: [Product / feature name] Owner: [Name] · Engineering pair: [Name] · Target ship: [date] Today's date: [YYYY-MM-DD] · Build window: [N weeks] 1 · THE BET (1 sentence) "If we ship [thing] for [customer], they will [behaviour] within [time window]." Example: "If we ship a single-corridor IN→UAE payroll API for SMBs paying ≤ 50 employees, they will run at least one full payroll cycle through us within 30 days." 2 · BUILD (must-have for the bet to be testable) - [Capability 1] — minimum acceptable: [what "done" looks like] - [Capability 2] — minimum acceptable: [...] - [Capability 3] — minimum acceptable: [...] - [Capability 4] — minimum acceptable: [...] - [Capability 5] — minimum acceptable: [...] (Cap at 5–7. If you're at 12, you're not building an MVP.) 3 · WON'T BUILD (explicit cut-list) - [Tempting feature 1] — defer to v1.1 because [why] - [Tempting feature 2] — defer because [why] - [Tempting feature 3] — never because [why] - [Edge case 1] — handle manually for first 10 customers - [Edge case 2] — block in UI; "coming soon" - [Integration 1] — wait for v2 4 · SUCCESS CRITERIA (3 numbers, 1 timeframe) By [date], we should observe: - [Metric 1, e.g. activation rate]: ≥ [number] - [Metric 2, e.g. retention week 4]: ≥ [number] - [Metric 3, e.g. NPS or qualitative]: [target or threshold] If we hit ≥ 2 of 3: we double down — write a v1 plan, hire ahead. If we hit 1 of 3: we iterate — adjust scope, re-test for 4 more weeks. If we hit 0 of 3: we pivot or kill — decision in 2 weeks. 5 · KILL CRITERIA (the brutal honesty) Conditions under which we WILL kill, before reaching the success window: - [Condition 1, e.g. acquiring 0 paying customers in first 30 days] - [Condition 2, e.g. average activation <10% across 100 signups] - [Condition 3, e.g. NPS < 0 from first 20 users] 6 · OPEN ASSUMPTIONS (what could break this) - Assumption 1: [we believe X is true; we'll know within Y weeks] - Assumption 2: [...] - Assumption 3: [...] 7 · ROLLOUT - Internal dogfood: week [N] - 5 paying design partners: week [N+2] - Open beta: week [N+4] - Pricing live: week [N+6]
The cut-list is the document. "What we won't build" is more important than "what we will build". The discipline of writing it forces team alignment and prevents scope creep.
Most-common MVP scope mistakes
- Building the v1 of v1. "Let's just add login, then SSO, then SAML." Rule: anything not on the bet line goes to "Won't build".
- No kill criteria. Without these, you'll keep iterating instead of pivoting.
- Vanity success criteria. "Get 1000 signups" is not a success criterion. "1000 signups with 30% week-4 retention" is.
- Solo author. The MVP scope is co-signed by founder + engineering lead. If only one of you signed, it'll change in week 2.