MVP Scoper — Scoping minimum viable product...

Defines the smallest buildable product that validates a core hypothesis using feature triage, effort/impact scoring, a 2-week sprint scope, and success criteria.

Activation

When this skill activates, output:

MVP Scoper — Scoping minimum viable product...

Then execute the protocol below.

Context Guard

Context	Status
User says "MVP", "minimum viable product", "scope the MVP"	ACTIVE
User says "what should I build first" or "strip to core"	ACTIVE
User has an idea and wants to know the smallest thing to build	ACTIVE
User wants a full product requirements document	DORMANT — use PRD Writer
User wants a roadmap beyond MVP	DORMANT — use Roadmap Builder

Common Mistakes

Mistake	Why It's Wrong
"MVP means bad quality"	Minimum viable means minimum scope, not minimum quality. Ship fewer features, but polish them.
"Add just one more thing"	Every "one more thing" adds a week. The MVP is a hypothesis test, not a product launch.
"Build the whole backend first"	Start with what users see and interact with. Fake the backend if needed (wizard of oz MVP).
"Skip the hypothesis"	Without a hypothesis, you're just building. The MVP exists to test ONE assumption.
"No success criteria"	How will you know if the MVP worked? Define the test before building.

Protocol

Step 1: Define the Hypothesis

If the user hasn't provided details, ask:

1. Idea — what are you building? (one paragraph)
2. Target user — who is the first user? (be specific — not "everyone")
3. Problem — what painful problem does this solve?
4. Assumption — what's the riskiest assumption? (the thing that must be true for this to work)
5. Existing alternatives — how do people solve this today?

Hypothesis template:

## Core Hypothesis

We believe that [target users]
have a problem with [specific pain point].

If we build [proposed solution],
they will [expected behavior: sign up, pay, use weekly, share].

We will know this is true when [measurable success criteria].

### Riskiest Assumption
[The single assumption that, if wrong, makes the whole product fail]

### How the MVP Tests This
[Specifically how the MVP will validate or invalidate the assumption]

Step 2: List ALL Desired Features

Brain-dump every feature the user imagines, without filtering:

## Feature Wish List (Unfiltered)

1. [Feature A]
2. [Feature B]
3. [Feature C]
4. [Feature D]
...
[List everything — the filtering comes next]

Goal: Get everything out of the user's head so nothing feels "lost." This makes the cutting process psychologically easier.

Step 3: Score Features (Effort vs Impact)

Rate each feature on two axes:

Feature	Impact (1-5)	Effort (1-5)	Score	MVP?
[Feature A]	5	2	2.5	Yes
[Feature B]	4	4	1.0	Maybe
[Feature C]	2	5	0.4	No
[Feature D]	5	1	5.0	Yes

Score = Impact ÷ Effort (higher is better)

Impact criteria (how much does this feature validate the hypothesis?):

• 5: Directly tests the core hypothesis — users can't use the MVP without it
• 4: Strongly supports the core experience
• 3: Nice to have, improves experience but not essential to the test
• 2: Quality-of-life improvement, not related to core hypothesis
• 1: Cool idea, but doesn't help validate anything right now

Effort criteria (how long to build it?):

• 1: Hours — trivial implementation
• 2: 1-2 days — straightforward
• 3: 3-5 days — moderate complexity
• 4: 1-2 weeks — significant work
• 5: 2+ weeks — major undertaking

Step 4: Apply the MVP Cut

Three buckets:

Bucket	Criteria	Action
Core (build)	Score ≥ 2.0 AND directly tests hypothesis	Include in MVP
Defer (v1.1)	Score 1.0-2.0 OR supports but doesn't test hypothesis	Build after validation
Cut (maybe never)	Score < 1.0 OR unrelated to hypothesis	Remove from backlog

The 2-week test: After bucketing, verify the Core features fit in a 2-week sprint (10 working days):

## MVP Scope — 2-Week Build

| Feature | Effort (days) | Notes |
|---------|-------------|-------|
| [Core Feature A] | 2 | [Brief note] |
| [Core Feature B] | 1 | [Brief note] |
| [Core Feature C] | 3 | [Brief note] |
| [Core Feature D] | 2 | [Brief note] |
| Buffer (20%) | 2 | Bugs, blockers, integration |
| **Total** | **10 days** | ✓ Fits in 2-week sprint |

If it doesn't fit in 2 weeks:

1. Cut the lowest-scoring Core feature
2. Simplify the highest-effort feature (can you build a simpler version?)
3. Consider a different MVP type (see Step 5)

Step 5: Choose MVP Type

Not every MVP requires writing code:

MVP Type	Build Time	Best For	What You Learn
Landing page	1-2 days	Validating demand	Do people want this enough to sign up?
Wizard of Oz	1-2 weeks	Service-based products	Can you deliver value with manual processes?
Concierge	1 week	High-touch products	What does the customer actually need?
Single feature	2 weeks	Tool/SaaS products	Does the core mechanic work?
Piecemeal	1 week	Marketplace/platform	Can you connect supply and demand?
Video/demo	2-3 days	Complex products	Do people understand and want this?

Decision tree:

Is the riskiest assumption about DEMAND (will people want this)?
├── Yes → Landing page MVP or Video MVP
│         (Validate demand before building anything)
└── No → Is the riskiest assumption about VALUE (can you deliver)?
    ├── Yes → Wizard of Oz or Concierge MVP
    │         (Deliver value manually, automate later)
    └── No → Is it about USABILITY (can people figure it out)?
        └── Yes → Single Feature MVP or Piecemeal MVP
                  (Build the core mechanic, skip everything else)

Step 6: Define Success Criteria

## MVP Success Criteria

### Primary metric (must hit to continue):
- [Metric]: [Target] within [Timeframe]
- Example: "50 signups within 2 weeks of launch"
- Example: "10% of free users convert to paid within 30 days"
- Example: "Users return 3+ times per week"

### Secondary metrics (supporting signals):
- [Metric]: [Target]
- [Metric]: [Target]

### Kill criteria (stop if):
- [Metric] below [threshold] after [timeframe]
- Example: "Fewer than 20 signups after 2 weeks of promotion"
- Example: "Zero paying customers after 30-day free trial"

### What happens next:

| Result | Action |
|--------|--------|
| Hit primary metric | Proceed to v1.1 — add Deferred features |
| Mixed results | Run 2-3 user interviews to understand why. Iterate MVP. |
| Failed kill criteria | Pivot: change target user, problem, or solution |

Step 7: Build the MVP Spec

Assemble the final MVP specification:

## Tech Stack Recommendation

| Layer | Recommendation | Rationale |
|-------|---------------|-----------|
| Frontend | [Framework] | [Why — speed, familiarity, ecosystem] |
| Backend | [Framework/service] | [Why] |
| Database | [DB] | [Why] |
| Hosting | [Platform] | [Why — deployment speed, free tier] |
| Auth | [Solution] | [Why] |

### Build vs Buy decisions:
- [Component]: Build / Buy / Skip for MVP
- Auth: Use [Clerk/Supabase Auth/NextAuth] — don't build auth from scratch
- Payments: Use [Stripe] — don't build payment processing
- Email: Use [Resend/SendGrid] — don't build email infrastructure

MVP build rule: Buy or use existing services for everything except your core differentiator. Only build what makes your product unique.

Output Format

# MVP Scope — [Product Name]

## Hypothesis
[From Step 1]

## Feature Triage

### Core (Build in MVP)
| Feature | Impact | Effort | Days |
[Core features table]

### Deferred (v1.1)
| Feature | Impact | Effort | Rationale |
[Deferred features table]

### Cut
| Feature | Rationale |
[Cut features with brief explanation]

## MVP Type
[Selected type from Step 5 with rationale]

## Build Plan
[2-week schedule from Step 4]

## Success Criteria
[From Step 6]

## Tech Stack
[From Step 7]

## Risks
| Risk | Mitigation |
[Top 3 risks and how to address them]

Completion

MVP Scoper — Complete!

Hypothesis: [One-line summary]
MVP type: [Type]
Core features: [Count] ([X days] to build)
Deferred features: [Count]
Cut features: [Count]
Build timeline: [X weeks]
Success metric: [Primary metric + target]

Next steps:
1. Validate the hypothesis with 5 target users before building (show the spec)
2. Set up the tech stack
3. Build Core features in priority order
4. Launch to [initial audience: waitlist, beta group, community]
5. Measure success criteria at [timeframe]

Level History

• Lv.1 — Base: Hypothesis template with riskiest assumption, feature brain-dump + impact/effort scoring, 3-bucket feature triage (core/defer/cut), 2-week sprint fit test, 6 MVP types with decision tree, success criteria with kill criteria, tech stack recommendation with build/buy guidance. (Origin: MemStack Pro v3.2, Mar 2026)