---
# === IDENTITY ===
id: business/startup/mvp-scoping-framework/2026
canonical_question: "How to scope an MVP — feature prioritization, timeline estimation, and scope lock with real tools?"
aliases:
  - "MVP feature prioritization framework"
  - "how to scope a minimum viable product"
  - "MVP feature selection MoSCoW RICE"
  - "startup MVP scoping workshop"
  - "prevent MVP scope creep"
entity_type: execution_recipe
domain: business > startup > MVP Scoping Framework
region: global
jurisdiction: global
temporal_scope: 2024-2026

# === VERIFICATION ===
last_verified: 2026-03-11
confidence: 0.88
version: 2.0
first_published: 2026-03-10

# === TEMPORAL VALIDITY ===
temporal_validity:
  status: evolving
  last_breaking_change: "No-code MVP tools (Lovable, Bolt, v0) cut build timelines by 50% in 2025; Figma added AI-powered user flow generation"
  next_review: 2026-09-07
  change_sensitivity: high

# === CONSTRAINTS ===
constraints:
  - "MVP must solve exactly one core problem end-to-end — multi-problem MVPs fail from scope creep"
  - "Feature count in V1 must be 3-7 — fewer is a prototype, more indicates overscoping"
  - "Development timeline must target 4-12 weeks — under 4 weeks is a throwaway prototype, over 12 weeks is overbuilding"
  - "Scoping process itself must complete in 7-10 days — exceeding 2 weeks signals analysis paralysis"
  - "Must-have features only in V1 — Should/Could/Won't features go to backlog with no exceptions"
  - "Scope decisions must be driven by validation data, not founder intuition or competitor feature lists"

# === SKIP CONDITIONS ===
skip_this_unit_if:
  - condition: "User hasn't validated the problem yet (fewer than 15 customer interviews)"
    use_instead: "business/startup/idea-validation-playbook/2026"
  - condition: "User already has a product and needs feature prioritization for next release"
    use_instead: "Search knowledgelib.io for post-PMF growth strategy — no dedicated unit yet"
  - condition: "User needs the full launch sequence, not just scoping"
    use_instead: "business/startup/startup-launch-checklist/2026"

# === AGENT HINTS ===
inputs_needed:
  - key: product_type
    question: "What type of product are you building?"
    type: choice
    options: ["web application (SaaS)", "mobile app", "API/developer tool", "marketplace platform", "hardware + software"]
  - key: technical_skill
    question: "What is the founding team's technical capability?"
    type: choice
    options: ["non-technical (no-code only)", "semi-technical (can edit code)", "developer (can write code)"]
  - key: timeline_constraint
    question: "What's your target launch timeline?"
    type: choice
    options: ["4 weeks (aggressive)", "6-8 weeks (standard)", "10-12 weeks (thorough)", "flexible — quality over speed"]
  - key: validation_status
    question: "How validated is the core problem?"
    type: choice
    options: ["strongly validated — 15+ interviews + willingness to pay", "moderately validated — some interviews, positive signals", "hypothesis only — not yet tested"]

# === EXECUTION METADATA ===
execution:
  required_inputs:
    - name: "Validated problem statement"
      source: "Customer interviews or idea validation process"
      format: "document"
    - name: "Target customer profile"
      source: "Founder research or persona-building"
      format: "document"
    - name: "Technical capability assessment"
      source: "Founding team self-assessment"
      format: "structured data"
  outputs:
    - name: "Locked MVP scope document"
      format: "document"
      description: "Prioritized feature list (3-7 Must-haves), user journey map, cut line, and won't-have list with rationale"
    - name: "Sprint plan with timeline"
      format: "spreadsheet"
      description: "Week-by-week development plan with task breakdown, dependencies, and risk buffers"
    - name: "V1.1 backlog"
      format: "spreadsheet"
      description: "Ranked Should-have and Could-have features for post-launch iteration"
  tools_required:
    - name: "Miro or FigJam"
      purpose: "User story mapping and scoping workshop facilitation"
      tier: "free"
      cost: "$0 (free tier)"
      alternatives: ["Whimsical", "Notion whiteboard", "physical whiteboard"]
    - name: "Google Sheets or Notion"
      purpose: "Feature inventory, MoSCoW classification, and RICE scoring"
      tier: "free"
      cost: "$0"
      alternatives: ["Airtable", "Linear", "Productboard ($20/mo)"]
    - name: "Figma"
      purpose: "Low-fidelity wireframes for scope validation"
      tier: "free"
      cost: "$0 (free tier: 3 files)"
      alternatives: ["Excalidraw", "Balsamiq ($12/mo)", "pen and paper"]
  credentials_needed:
    - service: "Miro"
      type: "OAuth"
      where_to_get: "https://miro.com/signup/"
      free_tier_limits: "3 editable boards, unlimited team members"
    - service: "Figma"
      type: "OAuth"
      where_to_get: "https://www.figma.com/signup"
      free_tier_limits: "3 Figma files, unlimited FigJam files"
  estimated_duration: "7-10 days"
  estimated_cost: "$0 (all tools have free tiers)"

# === DISTRIBUTION ===
canonical_source: "https://knowledgelib.io/business/startup/mvp-scoping-framework/2026"
suggested_citation: "Source: knowledgelib.io — AI Knowledge Library (verified 2026-03-11)"

# === RELATED UNITS ===
related_kos:
  depends_on:
    - id: "business/startup/idea-validation-playbook/2026"
      label: "Validation data that informs MVP scope decisions"
  feeds_into:
    - id: "business/startup/startup-launch-checklist/2026"
      label: "Scope document feeds into Step 3 (Build MVP) of the launch checklist"
    - id: "business/startup/financial-model-template-library/2026"
      label: "Cost estimates from scoping feed financial model"
  related_to:
    - id: "business/startup/first-10-hires-playbook/2026"
      label: "Hiring after MVP ships and traction starts"
  alternative_to: []

# === SOURCES ===
sources:
  - id: src1
    title: "RICE vs MoSCoW (2026): Best MVP Prioritization Framework?"
    author: MVP Expert
    url: https://www.mvpexpert.com/blog/rice-vs-moscow-the-ultimate-2025-guide-to-mvp-feature-prioritization-frameworks
    type: industry_report
    published: 2025-11-01
    reliability: high
  - id: src2
    title: "Build the Right First Version By Mastering MVP Scoping"
    author: Thinslices
    url: https://www.thinslices.com/insights/build-the-right-first-version-by-mastering-mvp-scoping
    type: industry_report
    published: 2025-06-01
    reliability: high
  - id: src3
    title: "90 Days to MVP: The Ultimate Scope Creep Prevention Guide"
    author: PilotSprint
    url: https://www.pilotsprint.com/blogs/the-hidden-cost-of-mvp-scope-creep-why-less-really-is-more
    type: industry_report
    published: 2025-08-01
    reliability: high
  - id: src4
    title: "How to Prioritize MVP Features Without Overbuilding"
    author: Ministry of Programming
    url: https://ministryofprogramming.com/blog/how-to-identify-and-prioritize-core-mvp-features-in-2025
    type: industry_report
    published: 2025-01-20
    reliability: high
  - id: src5
    title: "MVP Scope and Focus in 2026"
    author: Valtorian
    url: https://www.valtorian.com/blog/mvp-scope-2026
    type: industry_report
    published: 2026-01-15
    reliability: high
  - id: src6
    title: "MVP Development for Startups: Costs, Timelines & 4-Week Launch Playbook"
    author: MVP Launchpad
    url: https://mvplaunchpad.co/blog/mvp-development-for-startups
    type: industry_report
    published: 2025-03-01
    reliability: high
  - id: src7
    title: "MVP Development Cost in 2026: Full Breakdown & Strategies"
    author: Ideas2IT
    url: https://www.ideas2it.com/blogs/mvp-development-cost
    type: industry_report
    published: 2026-02-01
    reliability: high
  - id: src8
    title: "The Complete MVP Roadmap Guide for 2026"
    author: Presta
    url: https://wearepresta.com/the-complete-mvp-roadmap-guide-for-2026/
    type: industry_report
    published: 2025-11-01
    reliability: high
---

# 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
<!-- Agents: verify ALL prerequisites before executing. Missing prerequisites = failed execution. -->

- [ ] **Problem validated** through 15+ customer interviews with confirmed pain point and willingness to pay — if not: [Idea Validation Playbook](/business/startup/idea-validation-playbook/2026)
- [ ] **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 they will code, use no-code, or outsource
- [ ] **Budget range established** — see Cost Breakdown below for benchmarks by approach
- [ ] **3-5 beta users committed** to testing the MVP once built

## Constraints
<!-- Hard rules. Agents: enforce throughout execution. Violating these = broken output or legal risk. -->

- The MVP must deliver the core value proposition end-to-end — a user must complete the primary workflow from signup to outcome without manual intervention. A great MVP in 2026 is a single complete workflow, not a feature list. [src5]
- Feature count in V1 must be 3-7 Must-haves. More than 7 means scope is too broad — apply the deletion test more aggressively. [src1]
- Development timeline must target 4-12 weeks. If buffered estimate exceeds 12 weeks, cut scope — do not extend timeline. [src6]
- Only Must-have features ship in V1. Should/Could/Won't features go to backlog. No exceptions, no "just one more." [src1]
- Scope decisions must be data-driven: validated customer pain, not competitor feature lists or founder intuition. [src4]
- The scoping process itself must complete in 7-10 days. Spending more than 2 weeks means analysis paralysis — lock and build. [src6]

## Tool Selection Decision

```
Which path?
├── Founder is non-technical AND wants speed
│   └── PATH A: No-Code Scoping — 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
```

| Path | Tools | Cost | Speed | Output Quality |
|------|-------|------|-------|---------------|
| A: No-Code Free | Miro Free, Sheets, Canva | $0 | 5-7 days | Good — functional scope doc |
| B: No-Code Premium | Miro, Notion, Figma | $0-$30/mo | 5-7 days | High — visual + structured |
| C: Developer | FigJam, Linear, Figma | $0 | 4-6 days | High — dev-ready tasks |
| D: Workshop | Miro, Productboard, JIRA | $50-$150/mo | 7-10 days | Excellent — enterprise-grade |

## 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 is the filter for every subsequent decision. If a feature does not serve this sentence, it does not belong in V1.

Then define the "aha moment" — the exact point where the user first experiences the core value. Map the minimum path from signup to aha moment in 3-5 steps. If the minimum path exceeds 5 steps, simplify the journey. [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 status.
```

**Verify**: Scope sentence passes the "one workflow" test; minimum path is 3-5 steps; aha moment is clear
**If failed**: If you cannot write the sentence without using "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 board) or Google Sheets

List every feature that could support the user journey — aim for 20-40 features. Do not filter during this step. Group features by journey stage: onboarding, core workflow, output/delivery, account management, infrastructure. [src2]

For each feature, write a one-line user story: "As a [user], I want to [action] so that [outcome]." Include non-functional requirements: authentication, data persistence, basic security, error handling.

```
Feature Inventory Structure (Google Sheets):
| # | Feature | User Story | Journey Stage | Category |
|---|---------|------------|---------------|----------|
| 1 | Email signup | As a user, I want to create an account | Onboarding | Functional |
| 2 | Task creation | As a designer, I want to add tasks to a project | Core workflow | Functional |
| 3 | Shared status link | As a designer, I want clients to see progress | Output | Functional |
| 4 | Password reset | As a user, I want to recover my account | Account mgmt | Non-functional |
| ... | ... | ... | ... | ... |
```

**Verify**: Inventory has 20+ features; all journey stages covered; user stories are specific (not vague)
**If failed**: If fewer than 20 features, the solution concept is underdeveloped — brainstorm with co-founder or beta users

### Step 3: MoSCoW Classification + Deletion Test

**Duration**: 3-4 hours
**Tool**: Google Sheets or Notion (add MoSCoW column to inventory)

Classify every feature using MoSCoW. Apply MoSCoW first, then use RICE as a tiebreaker between Must and Should categories. [src1]

- **Must-have**: MVP cannot ship without this — user cannot complete core journey. Apply the deletion test: if you remove this feature, can the user still achieve the core outcome? If yes, it is not Must-have. [src4]
- **Should-have**: Important but workaround exists — ship in V1.1 (2-4 weeks post-launch)
- **Could-have**: Nice to have — ship if time permits or in V2
- **Won't-have**: Explicitly out of scope — document the reasoning to prevent relitigating

Target: 3-7 Must-have features, 5-10 Should-have, rest is Could/Won't. [src1]

```
MoSCoW Deletion Test (run for every Must-have candidate):
Q1: If I remove this, can the user still complete the core workflow? → Yes = not Must-have
Q2: Is there a manual workaround for V1? → Yes = Should-have (automate in V1.1)
Q3: Does this feature test our core value assumption? → No = Could-have at best

RICE Tiebreaker (for Must vs Should borderline features):
Score = (Reach × Impact × Confidence) / Effort
- Reach: estimated users affected per month (number)
- Impact: 3 (massive), 2 (high), 1 (medium), 0.5 (low)
- Confidence: 100% (data-backed), 80% (educated guess), 50% (speculation)
- Effort: person-weeks required
```

**Verify**: 3-7 Must-have features identified; core journey completable with Must-haves only; every Must-have survives the deletion test
**If failed**: If more than 7 Must-haves, your scope is too broad. Challenge each one: "Is there a manual workaround for V1?" Move workaround-able features to Should-have

### Step 4: Value vs Effort Scoring and Cut Line

**Duration**: 2-3 hours
**Tool**: Google Sheets (2x2 matrix) or Miro (visual plot)

Score each Must-have and Should-have feature on two dimensions (1-5 scale). Plot on a 2x2 matrix to visualize build order. [src1]

```
Value vs Effort Matrix:
                    HIGH VALUE
                        │
    ┌───────────────────┼───────────────────┐
    │                   │                   │
    │   STRATEGIC       │   QUICK WINS      │
    │   Build next      │   Build first     │
    │   (high effort,   │   (low effort,    │
    │    high value)     │    high value)    │
    │                   │                   │
HIGH├───────────────────┼───────────────────┤LOW
EFFORT                  │                  EFFORT
    │                   │                   │
    │   TRAPS           │   FILL-INS        │
    │   Cut from MVP    │   Build if time   │
    │   (high effort,   │   (low effort,    │
    │    low value)      │    low value)     │
    │                   │                   │
    └───────────────────┼───────────────────┘
                        │
                    LOW VALUE

Build order: Quick Wins → Strategic → Fill-ins → (never Traps)
```

Draw the cut line: everything above ships in V1, everything below goes to backlog. Create the V1.1 plan: first 3-5 features from the backlog, targeted 2-4 weeks after launch. Document the won't-have list with explicit reasoning — this prevents scope relitigating during development. [src8]

**Verify**: Cut line drawn; core journey completable above the line; V1.1 backlog created; won't-have list documented with reasons
**If failed**: If cut line leaves user journey incomplete, one or more Should-haves must be promoted to Must-have (swap 1:1 with lowest-value Must-have)

### Step 5: Technical Task Breakdown and Timeline Estimation

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

Break each Must-have feature into technical tasks (2-8 hour units). Identify dependencies. Flag high-risk items (new technology, external APIs, uncertain requirements). Use T-shirt sizing first, then convert to hours. [src2]

```
Task Breakdown Template:
| Feature | Task | Size | Hours | Depends On | Risk |
|---------|------|------|-------|------------|------|
| Email signup | Auth provider setup | M | 4-6h | None | Low |
| Email signup | Signup form + validation | S | 2-3h | Auth setup | Low |
| Task board | Data model design | M | 4-6h | None | Low |
| Task board | Drag-drop UI | L | 8-12h | Data model | Medium |
| Shared link | Public URL generation | M | 4-6h | Task board | Low |
| Shared link | Real-time status view | L | 8-16h | Task board | High |

T-shirt Sizes: S (<4h), M (4-8h), L (8-16h), XL (16-32h)
Constraint: No single task over 32 hours — decompose further if needed.

Sprint Planning:
- Sprint length: 1 week (small teams) or 2 weeks (larger teams)
- Productive time: 60-70% of total hours (rest = meetings, planning, overhead)
- Bug allocation: 15-20% of each sprint
- Testing allocation: 10-15% of each sprint
- Scope buffer: 1 sprint reserved at end for must-fix issues

Risk Buffer:
- First-time teams: add 30-50% to total estimate
- Experienced teams: add 20-30%
- New technology or external APIs: apply 2x multiplier to those specific tasks
```

**Verify**: Total buffered timeline is 4-12 weeks; all features have task breakdowns; dependencies mapped; risk items flagged
**If failed**: If buffered timeline exceeds 12 weeks, return to Step 4 and move the lowest-value Must-have below the cut line. The answer is fewer features, not more time. [src8]

### Step 6: Scope Validation with Beta Users

**Duration**: 1-2 days
**Tool**: Figma (lo-fi wireframes), Zoom/Google Meet (user calls)

Create low-fidelity wireframes of the core user journey (signup → aha moment) using Figma or Excalidraw. Present the MVP scope and wireframes to 3-5 committed beta users. Ask two questions: "Would this version solve your problem?" and "What's missing that would make this unusable?" [src4]

Only add features that multiple beta users flag as blockers. Single-user requests go to backlog. If a critical gap is identified, evaluate adding it as a Must-have — but swap 1:1 with the lowest-value existing Must-have to maintain the 3-7 feature constraint.

**Verify**: 3+ beta users confirm the scoped MVP would solve their problem; no critical gaps identified by multiple users; beta users commit to testing within 1 week of launch
**If failed**: If beta users say the MVP would not solve their problem, the scope sentence from Step 1 is wrong — revisit the outcome definition, not the feature list

### Step 7: Constraint Verification and Scope Lock

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

Run the final constraint checklist and produce the locked scope document. Both product and technical leads must sign off. [src3]

```
Scope Lock Checklist:
[ ] Feature count is 3-7 Must-haves (not more)
[ ] Development timeline is 4-12 weeks (buffered)
[ ] Budget covers development + 20% contingency
[ ] Core user journey completable end-to-end with Must-haves only
[ ] Every Must-have survives the deletion test
[ ] Scope driven by validation data, not assumptions
[ ] Won't-have list documented with reasoning
[ ] V1.1 backlog prioritized
[ ] 3+ beta users validated the scope
[ ] Product lead and technical lead both sign off

After lock:
- No scope changes without formal review involving both leads
- Any addition requires removing an equal-effort feature (1:1 swap rule)
- Scope document is distributed to entire team as single source of truth
```

**Verify**: All 10 checklist items pass; scope document finalized and distributed; team aligned on what is and is not in V1
**If failed**: If any constraint fails, address it before locking. Do not lock an incomplete scope — it will unravel during development

## Output Schema

```json
{
  "output_type": "mvp_scope_document",
  "format": "document + spreadsheet",
  "columns": [
    {"name": "scope_sentence", "type": "string", "description": "One-sentence MVP definition (audience + outcome + workflow)", "required": true},
    {"name": "must_have_features", "type": "array", "description": "3-7 prioritized Must-have features with user stories", "required": true},
    {"name": "user_journey_map", "type": "string", "description": "3-5 step path from signup to aha moment", "required": true},
    {"name": "sprint_plan", "type": "object", "description": "Week-by-week plan with tasks, dependencies, risk buffer", "required": true},
    {"name": "buffered_timeline_weeks", "type": "number", "description": "Total development weeks including risk buffer", "required": true},
    {"name": "v1_1_backlog", "type": "array", "description": "Ranked Should-have features for post-launch", "required": true},
    {"name": "wont_have_list", "type": "array", "description": "Explicitly excluded features with documented reasoning", "required": true},
    {"name": "estimated_cost", "type": "number", "description": "Total estimated development cost for MVP", "required": true}
  ],
  "expected_row_count": "1 (scope document)",
  "sort_order": "N/A",
  "deduplication_key": "scope_sentence"
}
```

## Quality Benchmarks

| Quality Metric | Minimum Acceptable | Good | Excellent |
|---------------|-------------------|------|-----------|
| Must-have feature count | 3-7 | 4-6 | 5 (sweet spot) |
| Scoping process duration | ≤14 days | ≤10 days | ≤7 days |
| Beta user scope validation rate | 60% confirm | 80% confirm | 100% confirm |
| Timeline estimate accuracy (actual vs plan) | Within 2 sprints | Within 1 sprint | On schedule |
| Scope changes during development | <3 additions | <2 additions | 0 additions |
| Won't-have list completeness | 10+ items documented | 15+ items | 20+ items with reasoning |

**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

| Error | Likely Cause | Recovery Action |
|-------|-------------|----------------|
| Cannot narrow to 7 or fewer Must-haves | Scope sentence defines multiple outcomes | Rewrite scope sentence with one outcome; split into two MVPs if needed |
| Beta users say scoped MVP won't solve problem | Wrong outcome targeted, not wrong features | Return to Step 1; redefine the outcome based on what beta users actually need |
| Timeline estimate exceeds 12 weeks | Too many features or tasks under-decomposed | Return to Step 4; move lowest-value Must-have below cut line; re-estimate |
| Team disagrees on MoSCoW classification | No clear decision-maker or data-driven criteria | Product lead makes final call; use RICE scores as objective tiebreaker [src1] |
| Scope creep during development (new features added) | No formal change control process | Enforce 1:1 swap rule: any addition requires removing equal-effort feature [src3] |
| Feature inventory too small (<20 features) | Solution concept underdeveloped | Brainstorm with beta users; review competitor features (for ideas, not copying) |

## Cost Breakdown

| Component | Solo/No-Code | Small Team (2-3 devs) | Outsourced/Agency |
|-----------|-------------|----------------------|-------------------|
| Scoping tools (Miro, Sheets, Figma) | $0 | $0 | $0-$150/mo |
| Scoping workshop facilitation | $0 (founder time) | $0 (team time) | $2,000-$5,000 |
| Wireframes/prototyping | $0 (Figma free) | $0-$200 | $1,000-$3,000 |
| MVP development (post-scoping) | $0-$500 (no-code tools) | $0 (salary) | $15,000-$75,000 |
| **Total scoping cost** | **$0** | **$0-$200** | **$3,000-$8,000** |
| **Total through MVP launch** | **$0-$1,000** | **$1,000-$5,000** | **$20,000-$80,000** |

Development cost benchmarks for 2026: simple web app (no-code) $5K-$15K; standard SaaS MVP $25K-$75K; complex/AI-enabled $50K-$150K. [src7] If estimated cost exceeds $80K, scope is almost certainly too large — cut features until cost drops.

## Anti-Patterns

### Wrong: Including every feature competitors have
Founders list competitor features and try to match them in V1. This creates a bloated MVP that takes 6+ months. Competitors have years of development behind their feature sets — matching them is neither possible nor desirable. [src4]

### Correct: Build one thing better than anyone else
Your MVP wins by solving one problem exceptionally well. The unique wedge from your validation is your scope anchor, not the competitor's feature matrix. [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. Without a hard deadline, scope creep is guaranteed. [src3]

### Correct: Set a hard deadline and cut scope to fit
Time-box the MVP. If features do not fit within 12 weeks, the answer is fewer features, not more time. Launch imperfect and iterate with real user feedback. [src8]

### Wrong: Building admin dashboards and analytics before core product
Admin panels, analytics dashboards, user management — these are "comfort features" that delay launch without testing core assumptions. They make founders feel productive without generating learning. [src4]

### Correct: Build only what tests the core value proposition
Every feature in V1 should help answer: "Does this product solve the validated problem?" Non-essential infrastructure can be manual or missing. Use a spreadsheet as your admin panel for V1. [src5]

### Wrong: Treating edge cases as Must-have requirements
"But what if a user has 500 projects?" Handle edge cases through UX constraints (set limits), fallback workflows, and clear messaging — not through full feature systems in V1. [src5]

### Correct: Design around constraints, build for the common case
V1 serves the 80% use case. Edge cases get a helpful error message or manual workaround, not a 3-week engineering effort.

## 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.

## Related Units

- [Idea Validation Playbook](/business/startup/idea-validation-playbook/2026) — validation data that informs MVP scope decisions (run before this recipe)
- [Startup Launch Checklist](/business/startup/startup-launch-checklist/2026) — full launch sequence where MVP scoping is Step 3
- [First 10 Hires Playbook](/business/startup/first-10-hires-playbook/2026) — hiring after MVP ships and traction starts
- [Financial Model Template Library](/business/startup/financial-model-template-library/2026) — cost estimates from scoping feed financial projections