MVP Scoping Framework: From Feature List to Locked Scope

Purpose

This recipe produces a locked MVP scope document — a prioritized feature list of 3-7 Must-have features, a user journey map with defined start-to-value path, a sprint-by-sprint development timeline with risk buffers, and a documented won't-have list that prevents scope relitigating during development. The output is ready to hand to a development team or load into a no-code builder and start building on day one. [src2]

Prerequisites

• Problem validated through 15+ customer interviews — Idea Validation Playbook
• Target customer profile — clear definition of who the MVP serves (one segment only)
• Solution concept — rough idea of what the product does (not how — that is this recipe's output)
• Technical capability assessed — founder knows whether to code, use no-code, or outsource
• Budget range established — see Cost Breakdown below
• 3-5 beta users committed to testing once MVP is built

Constraints

• MVP must deliver core value end-to-end — one complete workflow from signup to outcome. A great MVP in 2026 is a single workflow, not a feature list. [src5]
• 3-7 Must-have features in V1 — more than 7 means scope is too broad. [src1]
• 4-12 week development timeline — if buffered estimate exceeds 12 weeks, cut scope. [src6]
• Must-have features only in V1 — Should/Could/Won't to backlog, no exceptions. [src1]
• Scope driven by validation data, not founder intuition or competitor feature lists. [src4]
• Scoping process itself must complete in 7-10 days. Over 2 weeks = analysis paralysis. [src6]

Tool Selection Decision

Which path?
├── Founder is non-technical AND wants speed
│   └── PATH A: No-Code Free — Miro Free + Google Sheets + Canva wireframes
├── Founder is non-technical AND has budget for tools
│   └── PATH B: No-Code Premium — Miro/FigJam + Notion + Figma
├── Founder is semi-technical or developer
│   └── PATH C: Developer Scoping — FigJam/Excalidraw + Linear/GitHub Issues + Figma
└── Team with dedicated product manager
    └── PATH D: Structured Workshop — Miro + Productboard + Figma + JIRA

Execution Flow

Step 1: Define the One-Sentence MVP Rule

Duration: 2-4 hours · Tool: Any text editor or whiteboard

Write the MVP scope sentence: “This MVP helps [specific user] achieve [specific outcome] through [one primary workflow].” [src5] This sentence filters every subsequent decision. Define the “aha moment” and map the minimum path from signup to value in 3-5 steps. If the path exceeds 5 steps, simplify. [src4]

MVP Scope Sentence Template:
"This MVP helps [AUDIENCE] achieve [OUTCOME] through [ONE WORKFLOW]."

Example — project management SaaS:
"This MVP helps freelance designers track project deadlines through
a single-view task board with client-facing status links."

Aha moment: Client clicks shared link and sees real-time project status.
Minimum path: Sign up → Create project → Add tasks → Share link → Client views.

Verify: Scope sentence passes “one workflow” test; minimum path is 3-5 steps · If failed: If sentence uses “and” between outcomes, you have two MVPs — pick one

Step 2: Build the Feature Inventory (20-40 Features)

Duration: 4-6 hours · Tool: Miro (user story mapping) or Google Sheets

List every feature that could support the user journey — aim for 20-40 features. Do not filter during this step. Group by journey stage: onboarding, core workflow, output/delivery, account management, infrastructure. Write user stories: “As a [user], I want [action] so that [outcome].” [src2]

Verify: 20+ features listed; all journey stages covered · If failed: If <20 features, brainstorm with co-founder or beta users

Step 3: MoSCoW Classification + Deletion Test

Duration: 3-4 hours · Tool: Google Sheets or Notion

Classify every feature using MoSCoW. Apply MoSCoW first, then RICE as tiebreaker between Must and Should categories. [src1] For each Must-have candidate, run the deletion test: “If I remove this, can the user still complete the core workflow?” If yes, it is not Must-have. [src4]

RICE Tiebreaker Formula:
Score = (Reach × Impact × Confidence) / Effort
- Reach: users affected/month    - Impact: 3/2/1/0.5
- Confidence: 100%/80%/50%       - Effort: person-weeks

Verify: 3-7 Must-haves; core journey completable with Must-haves only · If failed: If >7 Must-haves, scope too broad — apply deletion test more aggressively

Step 4: Value vs Effort Scoring and Cut Line

Duration: 2-3 hours · Tool: Google Sheets (2x2 matrix) or Miro

Score each Must-have and Should-have on Value (1-5) and Effort (1-5). Plot on 2x2 matrix: Quick Wins (high value, low effort) → build first; Strategic → build next; Fill-ins → if time; Traps → cut. [src1] Draw the cut line. Create V1.1 backlog. Document won't-have list with reasoning. [src8]

Verify: Cut line drawn; core journey intact above line; V1.1 backlog created · If failed: If journey incomplete above line, promote one Should-have (swap 1:1 with lowest-value Must-have)

Step 5: Technical Task Breakdown and Timeline

Duration: 4-8 hours · Tool: Linear, GitHub Issues, or Google Sheets

Break each feature into 2-8 hour tasks. T-shirt size (S <4h, M 4-8h, L 8-16h, XL 16-32h), then convert to hours. Map dependencies. Plan sprints at 60-70% productive time. Add 30-50% risk buffer (first-time teams) or 20-30% (experienced). [src2]

Verify: Buffered timeline is 4-12 weeks; all tasks ≤32 hours · If failed: If >12 weeks, return to Step 4 and move lowest-value Must-have below cut line [src8]

Step 6: Scope Validation with Beta Users

Duration: 1-2 days · Tool: Figma (wireframes), Zoom/Meet (calls)

Create lo-fi wireframes of the core user journey. Present to 3-5 beta users. Ask: “Would this solve your problem?” and “What’s missing that would make this unusable?” Only add features flagged by multiple users. [src4]

Verify: 3+ beta users confirm scope solves their problem · If failed: If rejected, revisit the outcome definition in Step 1, not the feature list

Step 7: Constraint Verification and Scope Lock

Duration: 2-4 hours · Tool: Google Docs (scope document)

Run final constraint checklist: 3-7 features, 4-12 weeks, budget covers cost +20%, core journey complete, validation-driven, won't-have list documented. Both product and technical leads sign off. After lock: no changes without formal review; any addition requires removing an equal-effort feature (1:1 swap rule). [src3]

Verify: All constraints pass; scope document finalized and distributed · If failed: Address failing constraints before locking — do not lock incomplete scope

Output Schema

{
  "output_type": "mvp_scope_document",
  "format": "document + spreadsheet",
  "columns": [
    {"name": "scope_sentence", "type": "string", "description": "One-sentence MVP definition"},
    {"name": "must_have_features", "type": "array", "description": "3-7 prioritized Must-haves with user stories"},
    {"name": "user_journey_map", "type": "string", "description": "3-5 step path from signup to aha moment"},
    {"name": "sprint_plan", "type": "object", "description": "Week-by-week plan with tasks and risk buffer"},
    {"name": "buffered_timeline_weeks", "type": "number", "description": "Total dev weeks including buffer"},
    {"name": "v1_1_backlog", "type": "array", "description": "Ranked Should-have features for post-launch"},
    {"name": "wont_have_list", "type": "array", "description": "Excluded features with documented reasoning"},
    {"name": "estimated_cost", "type": "number", "description": "Total estimated development cost"}
  ]
}

Quality Benchmarks

If below minimum: Re-run Steps 3-4 with stricter deletion test. If scoping exceeds 14 days, force a lock — imperfect scope with a deadline beats perfect scope without one.

Error Handling

Cost Breakdown

2026 benchmarks: simple web app (no-code) $5K-$15K; standard SaaS MVP $25K-$75K; complex/AI-enabled $50K-$150K. [src7]

Anti-Patterns

Wrong: Including every feature competitors have

Founders match competitor feature sets in V1, creating a bloated 6+ month MVP. Competitors have years of development — matching them is neither possible nor desirable. [src4]

Correct: Build one thing better than anyone else

Win by solving one problem exceptionally well. The unique wedge from validation is your scope anchor. [src5]

Wrong: Letting timeline stretch to “get it right”

“Just two more weeks” compounds into months. A FinTech startup spent $500K over 6 months and never launched because scope kept expanding. [src3]

Correct: Set hard deadline and cut scope to fit

If features do not fit in 12 weeks, the answer is fewer features, not more time. Launch imperfect, iterate with real feedback. [src8]

Wrong: Building admin dashboards before core product

Admin panels, analytics, user management — “comfort features” that delay launch without testing core assumptions. [src4]

Correct: Build only what tests your core value proposition

Use a spreadsheet as your admin panel for V1. Every feature must answer: “Does this solve the validated problem?” [src5]

Wrong: Treating edge cases as Must-have requirements

“But what if a user has 500 projects?” Edge cases in V1 get UX constraints and helpful error messages, not 3-week engineering efforts. [src5]

Correct: Design around constraints, build for the common case

V1 serves the 80% use case. Edge cases get limits, fallback workflows, and clear messaging.

When This Matters

Use when a founder or agent needs to produce an actual MVP scope document — prioritized features, development timeline, and locked scope — not a strategy document about what an MVP is. Requires validated problem data as input; produces a build-ready scope document as output. Also use when scope creep is happening during development and the team needs to re-scope with formal constraints.