MVP Scope Prioritizer

What it does

The MVP Scope Prioritizer runs a messy feature/request pile through an evidence-based prioritization pipeline and decides, with justification, what's IN and what's OUT of the first release. It chains five industry-standard frameworks in a fixed order, each layer feeding and auditing the previous one:

1. JTBD (Jobs-to-be-Done / Ulwick ODI) — Reduces every raw idea to a "when <situation>, I want to <goal>, so that <benefit>" job statement and merges duplicates serving the same job (the #1 cause of backlog bloat). Prioritization targets jobs, not features.
2. Kano Model (Kano 1984) — Classifies each job into 5 classes: Must-be (absence kills), Performance (more is better), Attractive/Delighter (unexpected delight), Indifferent and Reverse. MVP rule: all Must-bes + the 1-2 highest-RICE Delighters; Indifferent/Reverse never enter.
3. RICE (Intercom / Sean McBride 2016) — RICE = (Reach × Impact × Confidence) / Effort. The Impact scale is fixed (Massive 3 → Minimal 0.25); Confidence is a deliberate penalty that automatically pulls down evidence-free "great ideas."
4. MoSCoW (DSDM) — Converts the RICE ranking into a scope commitment: Must / Should / Could / Won't. DSDM discipline: the Must slice must be ≤ 60% of total effort budget so a risk buffer remains.
5. User Story Mapping (Patton) + INVEST + WSJF — Lays the Musts along a user-journey backbone to extract a walking skeleton (the thinnest end-to-end working slice); each story passes an INVEST check, acceptance is written as Given/When/Then, and ties are broken with WSJF = Cost of Delay / Job Size.

Output: a trimmed scope where each candidate carries a RICE score + Kano class + MoSCoW slice + acceptance criteria, tagged with a 0-100 MVP Maturity Score.

When to use it

• You have a scattered feature/request list and need to decide what to build first and what goes in the first release.
• The backlog is bloated and needs an objective scope cut.
• A stakeholder says "let's also add this" and you need to bind it to a numeric accept/defer decision.
• At pre-seed/MVP stage you need to define the smallest learning release that tests the riskiest assumption cheaply.

Method / frameworks

The frameworks cross-check each other: if Kano calls something Must-be but RICE comes out low, the Effort is bloated (wrong solution) — question the solution, not the formula. No candidate with Confidence ≤ 30% can be a Must; propose a cheap learning experiment (spike/landing-test) first. A single candidate eating >40% of capacity alone gets sliced or pushed to Should/Could. Numeric thresholds (60% Must budget, 30% Confidence floor) are typical ranges, calibrated to team capacity; when data is missing it's flagged transparently in gaps. Sources: RICE (Intercom), MoSCoW (DSDM), Kano (1984), JTBD/ODI (Ulwick), User Story Mapping (Patton 2014), INVEST (Wake 2003), WSJF (SAFe).