cwinvestments 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:
- Idea: what are you building? (one paragraph)
- Target user: who is the first user? (be specific: not "everyone")
- Problem: what painful problem does this solve?
- Assumption: what's the riskiest assumption? (the thing that must be true for this to work)
- 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:
- Cut the lowest-scoring Core feature
- Simplify the highest-effort feature (can you build a simpler version?)
- 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)