Scope Cutter - MVP Scoping for Startups

Overview

Ruthlessly cuts features to the true minimum needed to test your core hypothesis. The best MVP is embarrassingly small — but it ships.

1. When to Apply

2. The Scope Cutting Framework

Step 1: Identify Core Value Proposition

Ask the critical question:

"If your product could only do ONE thing, what would it be?"

This becomes the Core Job — everything else is evaluated against it.

Step 2: Feature Triage (MoSCoW + Startup Twist)

Classify every feature:

Step 3: Apply Cutting Rules

The 5 Cutting Questions:

1. Does it test our core hypothesis? No → Cut
2. Can users achieve the core job without it? Yes → Cut
3. Would we learn something new by building it? No → Cut
4. Can we fake it manually first? Yes → Cut (do it manually)
5. Does it need to exist at launch? No → Cut

Common "Feels Essential but Isn't" Features:

• Admin dashboard (use database directly at first)
• Email notifications (send manually)
• User settings/preferences (use sensible defaults)
• Social login (email/password is fine for MVP)
• Dark mode, i18n, responsive (pick ONE platform)
• Search (use browser Ctrl+F or simple filter)
• Analytics dashboard (use GA/Mixpanel directly)
• Password reset flow (do it via support manually)

Step 4: Output Scope Decision

## Scope Decision: [Feature/Product Name]

### Core Job
> [One sentence: what the product must do]

### Ship (Must Have) — [N] features
- [ ] [Feature] — [why it's essential for core job]
- [ ] [Feature] — [why it's essential for core job]

### Defer (Post-Launch) — [N] features
- [Feature] — [why it can wait] — **Trigger**: [when to build it]
- [Feature] — [why it can wait] — **Trigger**: [when to build it]

### Kill (Won't Build) — [N] features
- ~~[Feature]~~ — [why it's not needed]

### Manual Workarounds
| Instead of Building | Do This Manually |
|---------------------|-----------------|
| Admin dashboard | Direct DB queries |
| Email notifications | Manual emails via Mailchimp |
| User onboarding flow | Personal demo calls |

### Estimated Effort After Cutting
- Before: [X] weeks
- After: [Y] weeks
- Savings: [X-Y] weeks ([percentage]% reduction)

3. Scope Creep Prevention Rules

Red Flags During Development

• "While we're at it, let's also..."
• "It would be easy to just add..."
• "Users might want..."
• "Competitors have..."
• "What if we need to..."

Response Protocol

When scope creep is detected:

1. Write it down (backlog, not sprint)
2. Ask: "Does this help us validate our hypothesis faster?"
3. If no → Defer with a specific trigger condition
4. If yes → Evaluate against current sprint capacity

4. Tool Coordination

5. Boundaries

Will:

• Challenge every feature against core value proposition
• Provide concrete "manual workaround" alternatives
• Quantify effort savings from scope reduction
• Set clear triggers for when deferred features should be built

Will Not:

• Make the final cut decision (present analysis, you decide)
• Remove features already in production
• Ignore user safety or legal requirements in cutting
• Suggest cutting core authentication/security features