/mvp-scoper

name: memstack-product-mvp-scoper
description: "Use this skill when the user says 'MVP', 'minimum viable product', 'scope the MVP', 'what should I build first', 'strip to core', or needs to define the smallest build that validates a product hypothesis. Do NOT use for full PRDs or roadmap planning."
version: 1.0.0
license: "Proprietary, MemStack™ Pro by CW Affiliate Investments LLC. See LICENSE.txt"

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