Scoping Your MVP (Part 2)

Feature Decision Table

List every feature you want and evaluate. Remember the MVP mindset from Lesson 1: clarity and focus beat feature bloat.

Priority Definitions

• P0 = Must have for MVP (build first)
• P1 = Should have if budget allows (build second)
• P2 = Nice to have (v1.1 after launch)
• P3 = Not needed yet (v2+)

Goal: Only build P0 features in your MVP.

Your Feature List Exercise

Step 1: List every feature you think you need

Step 2: Fill out the decision table

Step 3: Count your P0 features

• 3-5 features → Good scope
• 6-8 features → Probably too many, review
• 9+ features → Definitely too many, cut more

Step 4: For each P0 feature, ask "If I removed this, would the MVP still test my riskiest assumption?"

• Yes → Move to P1
• No → Keep as P0

Reality check: Instagram launched with 3 features: upload photo, apply filter, share to feed. That's it.

The 80/20 Analysis Worksheet

Instructions: For each feature:

1. Rate value to users (1-10)
2. Rate build complexity (1-10, ask developer)
3. Calculate ROI (value / complexity)
4. Sort by ROI descending

Example Analysis

Decision Rules

• ROI > 2.0 + Tests Risk = Build
• ROI > 2.0 + Can't Fake = Consider building
• ROI < 1.5 = Defer unless tests critical assumption
• Can Fake = Always defer unless tests risk

Insight: The features you're most excited about often have the worst ROI.

User Story Templates: Developer-Ready Format

Developers can't work from "As a user, I want to see my order history."

They need specifics.

Template Format

## Feature: [Name]

### User Goal
[What user is trying to accomplish and WHY]

### Acceptance Criteria
- [ ] Specific observable behavior 1
- [ ] Specific observable behavior 2
- [ ] Specific observable behavior 3

### Explicitly Out of Scope for MVP
- Thing 1 we're NOT building
- Thing 2 we're NOT building
- Thing 3 we're NOT building

### Reference Examples
- [App/Site Name]: [Specific feature URL or screenshot]
- [App/Site Name]: [Specific feature URL or screenshot]

### Edge Cases / Questions for Developer
- What happens if [edge case]?
- How do we handle [scenario]?
- Is [assumption] realistic for MVP timeline?

### Success Metrics
- How we'll know this works: [measurable outcome]

Example: Bad vs Good User Story

BAD (what founders write):

"As a user, I want to see my order history."

GOOD (what developers can work from):

Feature: Order History View

User Goal
User needs to check status of recent orders without
calling support, and see past orders to re-order items.

Acceptance Criteria
[ ] User can view list of all their orders (most recent first)
[ ] Each order displays: order date, items (first 3 + count),
    total amount, current status
[ ] User can click any order to see full details page
[ ] Status shows one of: Processing, Shipped, Delivered, Cancelled
[ ] Status updates when user refreshes page (real-time not required)

Explicitly Out of Scope for MVP
- Filtering by date range
- Searching orders
- Exporting to PDF
- Cancelling orders from history page (contact support instead)
- Sorting options (always newest first)
- Tracking numbers (show on detail page only)

Reference Examples
- Amazon order history (desktop)
- DoorDash order tracking (mobile app): Past orders tab
- Grubhub order history: Simple list view

Edge Cases / Questions for Developer
- What happens if order has 50+ items? (Show first 5 + "and 45 more")
- Do we need pagination or infinite scroll? (Pagination, 20 per page)
- If user has 0 orders, what do they see? ("No orders yet" + CTA)

Critical: The "Explicitly Out of Scope" section is as important as the criteria. It prevents scope creep.

Reuse vs Build Custom: The Decision Framework

Never Build These Yourself (Use Existing Services)

When to Build Custom

Build custom if:

• It's your core differentiation (recommendation engine, matching algorithm)
• It tests a risky assumption (novel UX pattern, unique workflow)
• No existing service does what you need (rare)
• Integration cost > build cost (very rare)

Don't build custom because:

• "We might need custom features later" (you can migrate later)
• "I don't want to pay 3% fees" (your time costs more)
• "We want full control" (you'll never use that control)
• "It's not that hard to build" (it's always harder than you think)

Rule of thumb: If Stripe/Firebase/Twilio does it, use them. If it's your secret sauce, build it.

Scope Commitment Contract

Problem: Founders change scope mid-project, blowing budget and timeline.

Solution: Sign this contract with yourself before starting.

I commit to the following scope for MVP v1:

Core features (P0 - must build):
1. [Feature 1]
2. [Feature 2]
3. [Feature 3]
4. [Feature 4]
5. [Feature 5]
Total P0 features: [Number - should be 3-5]

Features I'm explicitly NOT building in v1:
1. [Deferred feature 1]
2. [Deferred feature 2]
3. [Deferred feature 3]
4. [Deferred feature 4]
5. [Deferred feature 5]

Riskiest assumption I'm testing:
[One sentence: The thing that, if wrong, kills the business]

Success criteria for MVP:
- Metric 1: [e.g., 100 signups in 30 days]
- Metric 2: [e.g., 20% conversion to paid]
- Metric 3: [e.g., 50% weekly retention]

Budget commitment:
- Total budget: $[Amount]
- Contingency (20%): $[Amount]
- Maximum I will spend: $[Total + Contingency]

Timeline commitment:
- Target launch: [Date]
- Hard deadline: [Date + 4 weeks]

Signature: ________________
Date: ________________
Accountability partner: ________________

Mid-Project Feature Request Protocol

When I want to add a feature mid-project, I must:

1. Does this test my riskiest assumption?
2. Can I test this after launch with 10 users manually?
3. Will MVP fail without this?
4. What feature am I removing to add this? (1-for-1 swap only)

I will NOT:

• Add features without removing others
• Increase budget for nice-to-haves
• Extend timeline for non-critical features
• Override this process because "it's quick"

Complete Scoping Checklist

Phase 1: Foundation (1-2 hours)

• Complete Riskiest Assumption Framework
• Identify 1-2 assumptions that kill business if wrong
• Decide: Prototype, MVP, or Market-Ready?
• Choose Path 1 (Fast Validation) or Path 2 (Differentiation)
• Set budget and timeline boundaries

Phase 2: Feature Definition (2-3 hours)

• List all potential features (brain dump)
• Apply 3-Question Filter to each feature
• Complete Feature Decision Table
• Complete 80/20 Analysis Worksheet
• Identify P0 features (should be 3-5)

Phase 3: Specification (3-4 hours)

• Write user stories for each P0 feature (use template)
• Identify reference examples for each feature
• List edge cases and questions for developer
• Complete Build vs Buy Decision Table
• Document what's explicitly NOT in scope

Phase 4: Commitment (30 minutes)

• Complete Scope Commitment Contract
• Share with accountability partner
• Set mid-project feature request protocol
• Define success metrics

Phase 5: Validation (1-2 hours)

• Review: Does this MVP test riskiest assumption?
• Count P0 features (3-5 is good, 6+ is too many)
• Estimate: Can this ship in 2-4 months?
• Check: Is budget realistic for scope?
• Red flag check: Any "nice to haves" in P0?

Phase 6: Developer Handoff (1 hour)

• Package all user stories
• Share Build vs Buy decisions
• Clarify what's NOT in scope
• Schedule weekly demo reviews
• Set up mid-project check-in process

Once your scope is ready, learn how to hire developers who can execute on your specifications effectively.

Success Criteria

You've scoped correctly if:

• You can explain your MVP in 1-2 sentences
• You have 3-5 P0 features - not 10, not 15
• Every feature tests your riskiest assumption
• You're using existing services for 80% of functionality
• You have a longer list of what you're NOT building than what you are
• Developers can start building from your user stories
• You can defend every scope decision
• Your timeline is 2-4 months, not 6-8
• You have a process for mid-project feature requests
• You know exactly what you're trying to learn

Red Flags You've Scoped Wrong

• "We'll need this eventually, might as well build it now" → No. Build it when you need it.
• "All our competitors have this feature" → Competitors spent years iterating. You're starting from zero.
• "This will only take a few days to add" → Famous last words. Always takes longer.
• "Users will expect this" → Early adopters forgive missing features if core value is strong.
• "We can't launch without proper infrastructure" → Yes you can. Every successful startup did.
• "I don't want to look unprofessional" → Professional means solving the problem, not having every feature.
• "But what if we need to scale?" → You'll have revenue to rebuild when you need to scale.
• "The developer says we should build it properly" → Developers are trained to build properly. You're trying to validate quickly.
• "It's my vision, I need all these features" → Your vision isn't what you build first. It's what you build toward.

Cost Reality Check

Here's what things actually cost (US/Western Europe rates, divide by 2-3 for Eastern Europe/Asia). For detailed cost breakdowns, see Lesson 2: MVP Cost Guide.

Simple MVP (Instagram clone, basic marketplace)

• Professional: $30-60K, 3-4 months
• Budget: $15-25K, 4-6 months

Medium Complexity (Two-sided marketplace, moderate integrations)

• Professional: $60-120K, 4-6 months
• Budget: $30-50K, 6-9 months

Complex (Fintech, heavy backend, complex business logic)

• Professional: $120K+, 6-12 months
• Budget: Don't even try

Reality Check Math

Developer says 500 hours at $50/hour = $25,000

Actual cost:

• Their estimate: 500 hours
• Reality: 700-900 hours (40-80% overrun is normal)
• Hidden costs: $2-5K (services, tools, fixes)
• Actual spend: $35-50K

Budget the high end. Always.