Functional Requirements - Learning Module

Loading content...

0/273

MVP Definition

The Paradox of Less Is More

In 2007, Dropbox's MVP wasn't a product at all—it was a 3-minute video. Drew Houston realized that building the actual sync technology to validate whether people wanted file syncing would take months. Instead, he created a video demonstrating what the product would do. The waitlist exploded from 5,000 to 75,000 overnight. The product was built; the company is now worth billions.

Contrast this with the countless startups that spent years perfecting features nobody wanted, the enterprise projects that delivered comprehensive solutions to the wrong problem, the engineering teams that polished their architecture while competitors captured the market with 'inferior' products that actually shipped.

The Minimum Viable Product (MVP) is not about building less—it's about learning faster. It's the smallest thing you can build that lets you test your riskiest assumptions with real users. Defining an effective MVP is one of the most difficult skills in product development, requiring the discipline to cut features you love and the wisdom to include features you'd rather defer.

What You Will Master

By the end of this page, you will understand: (1) the true meaning and purpose of MVP, (2) how to identify the right scope for your MVP, (3) viability criteria that ensure your minimum is actually viable, (4) the difference between MVPs and prototypes, (5) common MVP anti-patterns that waste time and resources, and (6) how to evolve beyond MVP once validated.

What MVP Really Means

The term 'Minimum Viable Product' was coined by Frank Robinson and popularized by Eric Ries in 'The Lean Startup.' Yet despite its widespread use, MVP remains one of the most misunderstood concepts in product development.

The Definition:

An MVP is the smallest product increment that enables you to collect the maximum amount of validated learning about customers with the least effort.

Every word matters:

Smallest — Not 'small,' but the absolute minimum. Every feature must justify its existence.
Product increment — It must be something real that users can experience, not just a plan.
Validated learning — The goal is learning, not building. Building is the means, not the end.
Maximum learning — You're optimizing for insight, not for feature count.
Least effort — Time and resources spent building are time and resources not spent learning.

Both Words Matter Equally

Teams often emphasize 'Minimum' at the expense of 'Viable' (producing embarrassing unusable products) or 'Viable' at the expense of 'Minimum' (producing comprehensive V1s that took too long). Both words must be satisfied simultaneously.

MVP Is Not:

Common MVP Misconceptions

•A half-baked product — MVPs must work. Users should be able to complete their task, even if the experience isn't polished.
•Version 1.0 — MVP comes before V1. V1 is what you build after validating your MVP learnings.
•A beta version — Betas test whether the product works. MVPs test whether the product should exist.
•A prototype — Prototypes demonstrate concepts. MVPs deliver value and collect real user behavior data.
•An internal release — MVPs go to real users in the real world, not just internal testers.
•A license to be sloppy — 'It's just an MVP' doesn't excuse poor quality in what you do include.
•The final scope — MVPs are meant to evolve. If your MVP works, you expand it. If it fails, you pivot.

The Build-Measure-Learn Loop:

MVP exists within the broader Lean Startup Build-Measure-Learn feedback loop:

Build — Create the smallest thing that can test your hypothesis
Measure — Collect data on how real users interact with it
Learn — Analyze data to validate or invalidate your hypothesis
Iterate — Build the next smallest thing based on learnings

The MVP is what you build to enter this loop for the first time. Its purpose is to accelerate your path through the loop, not to be a final destination.

Identifying What to Include in Your MVP

The hardest part of MVP definition is deciding what makes the cut. Include too little, and the product isn't viable. Include too much, and it isn't minimum. The key is to identify your riskiest assumptions and include only what's needed to test them.

The Assumption Mapping Process:

MVP Scoping Steps

•Identify all assumptions — What must be true for this product to succeed?
•Rank by risk — Which assumptions, if wrong, would kill the product?
•Rank by testability — Which assumptions can be tested with a product?
•Focus on intersection — High-risk, testable assumptions define your MVP scope
•Define the minimum needed to test — For each focus assumption, what's the least you can build?

assumption-mapping.md
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
# Assumption Mapping: AI Meal Planning App
 
## All Assumptions
| ID | Assumption                                              | Risk | Testable |
|----|---------------------------------------------------------|------|----------|
| A1 | Users want personalized meal plans (not generic)        | HIGH | YES      |
| A2 | Users will input their dietary restrictions             | MED  | YES      |
| A3 | Users will follow the meal plans we generate            | HIGH | YES      |
| A4 | AI can generate appealing, healthy meal combinations    | HIGH | YES      |
| A5 | Users will pay $10/month for this service               | HIGH | YES      |
| A6 | Users want shopping lists for their meal plans          | MED  | NO*      |
| A7 | Users prefer mobile app over web                        | LOW  | NO**     |
| A8 | We can acquire users for under $5 CAC via social media  | MED  | NO**     |
 
* Can infer from later behavior, not MVP focus
** Marketing/channel hypothesis, not product hypothesis
 
## Focus Assumptions (High Risk + Testable)
1. A1: Users want personalized meal plans
2. A3: Users will follow the meal plans 
3. A4: AI generates appealing meals
4. A5: Users will pay $10/month
 
## MVP Scope to Test Focus Assumptions
 
To test A1 (personalization demand):
- ✓ Collect dietary preferences/restrictions
- ✓ Generate meal plan based on inputs
- ✗ 50 cuisine options (3 is enough to show personalization)
 
To test A3 (users follow plans):
- ✓ Daily meal plan display
- ✓ Track meal completion checkbox
- ✗ Calendar integration (nice, not essential to learn)
- ✗ Recipe details (link to external for MVP)
 
To test A4 (AI meal quality):
- ✓ Generate 7-day plan with AI
- ✓ Allow user to swap individual meals
- ✗ Unlimited regeneration (2 regenerations shows if they like AI output)
 
To test A5 (willingness to pay):
- ✓ Trial period, then paywall
- ✓ $10/month pricing displayed
- ✗ Annual option (monthly sufficient for validation)
- ✗ Multiple plan tiers (one tier tests the core hypothesis)
 
## Final MVP Scope
1. Onboarding: Collect 5 dietary preferences
2. Generation: AI generates 7-day meal plan
3. Display: Daily meal view with checkboxes
4. Swap: Allow 2 meal swaps per day
5. Linking: Link to external recipes (not build our own)
6. Payment: 7-day trial, then $10/month
 
## What's Explicitly NOT in MVP
- Mobile app (web responsive)
- Shopping list generation
- Recipe database
- Social sharing
- Nutritionist chat
- Macro/calorie tracking
- Pantry inventory
 
## Success Metrics
- A1: >60% complete onboarding preferences
- A3: >30% mark at least one meal complete per day
- A4: <20% swap rate (indicates satisfaction with AI)
- A5: >5% convert to paid after trial

The Core Journey Test

Your MVP should enable the complete core user journey, albeit simply. If your app is about getting personalized meal plans, users must be able to get a personalized meal plan. They can't just 'sign up for waitlist'—that's a landing page, not an MVP.

Viability Criteria: When Minimum Isn't Enough

The 'Viable' in MVP is often neglected. A product that's minimum but not viable teaches you nothing—users abandon it before you can learn anything. Viability requires meeting threshold standards across multiple dimensions.

The Viability Checklist:

MVP Viability Dimensions
Dimension	Question to Ask	Minimum Viable Standard
Functional	Can users complete the core task?	100% of core journey must work, not 80%
Reliable	Does it work every time?	Core functions must not fail; edge cases can be manual
Usable	Can users figure out how to use it?	No training needed for core flow; polish optional
Performant	Is it fast enough to not frustrate?	Core actions < 3 seconds; users will wait for value
Valuable	Does it solve the intended problem?	Users accomplish what they came for
Secure	Is user data protected sufficiently?	Basic security (HTTPS, auth); compliance for sensitive data
Legal	Are we legally allowed to operate?	Terms of service, privacy policy, required licenses

Viability Varies by Context:

The viability bar differs dramatically by product type and audience:

Context-Dependent Viability

•Consumer apps — Higher bar for UX polish; users have alternatives and little patience
•Enterprise B2B — Higher bar for reliability and security; lower bar for UX if value is clear
•Developer tools — Higher bar for functionality; developers tolerate rough edges for powerful features
•Healthcare/finance — Much higher bar for security and compliance from day one
•Internal tools — Lower bar across the board; known users, controlled environment
•Early adopters — More tolerant of friction if they get exclusive access or value
•Mass market — Minimal tolerance for friction; higher polish required

The Embarrassment Test:

Reid Hoffman, LinkedIn co-founder, famously said: 'If you're not embarrassed by the first version of your product, you've launched too late.'

This is often misquoted to justify shipping garbage. The full context matters:

Embarrassed about missing features → Good. Ship it.
Embarrassed about bugs in core functionality → Bad. Fix it.
Embarrassed about rough design → Depends on audience.
Embarrassed about security holes → Very bad. Fix it.

The embarrassment should come from what's missing, not from what's broken.

Viability Isn't Optional

An 'MVP' that's too broken for users to complete the core journey isn't a product—it's a prototype. Users encountering bugs or dead ends don't provide data on whether they want your product; they provide data on whether they tolerate broken software (they don't).

Types of MVPs: Beyond the Product

The most efficient MVPs often aren't products at all. Before writing code, consider whether a more minimal approach could validate your assumptions faster.

The MVP Spectrum (Least to Most Investment):

Types of MVPs
MVP Type	What It Is	Best For Testing	Example
Landing Page	Page describing product; measures signups	Demand: Do people want this?	Buffer started with a landing page explaining the concept
Explainer Video	Video showing what product would do	Understanding: Do people get the value prop?	Dropbox's 3-minute demo video
Concierge MVP	Manually deliver the service to each customer	Value: Will people pay for the outcome?	Food on the Table: founder manually planned meals for early users
Wizard of Oz	Product looks automated but humans process behind the scenes	Experience: Does the flow work?	Zappos: photos of shoes, manually bought when ordered
Piecemeal/Frankenstein	Combine existing tools to deliver experience	Workflow: Does the process work?	Groupon v1 was WordPress + Apple Mail + PDF coupons
Single Feature	Build one feature of the eventual product	Core value: Is this feature compelling?	Twitter started as status broadcasts only
Smoke Test	Full product design, test conversion before building	Purchase intent: Will people actually buy?	Pre-sales with refund guarantee

Deep Dives on Key MVP Types:

Concierge MVP:

Instead of building software to deliver your service, you manually do what the software would do for early customers. This validates whether customers want the outcome before you invest in automation.

Advantages:

Zero engineering investment to start
Deep learning from direct customer interaction
Flexibility to change approach instantly

Disadvantages:

Doesn't scale (by design)
Some products can't be delivered manually
May not reflect true automated experience

concierge-mvp.md
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
# Concierge MVP: AI-Powered Wardrobe Styling Service
 
## Hypothesis
Users will pay $30/month for AI-generated outfit suggestions that 
match their existing wardrobe to weather and calendar events.
 
## Full Product Vision (Never Build This First)
- User uploads wardrobe photos
- AI catalogs and tags items
- App pulls weather + calendar
- AI suggests daily outfits
- User rates outfits; AI learns preferences
- Cost: 6-12 months development, $500K+
 
## Concierge MVP
Week 1-4 Plan:
- Recruit 20 beta users (pay $30 if continue after trial)
- Users send wardrobe photos via Google Form
- Founder manually catalogs items in spreadsheet
- Founder checks weather + users share calendar
- Founder emails outfit suggestions each morning
- Users reply with feedback
 
Investment:
- Time: ~2 hours/user/week (40 hours/week for 20 users)
- Cost: $0 (founder time)
- Duration: 4-week validation
 
## Validation Metrics
- Retention: Do 80%+ read daily emails?
- Engagement: Do 50%+ follow suggestions (self-reported)?
- Payment: Do 50%+ pay after trial?
- Satisfaction: NPS > 40?
 
## Learning Outcomes
 
WHAT WE LEARNED:
✓ Users loved getting outfit suggestions (12/20 said "magical")
✓ Weather matching was highly valued
✗ Calendar integration was rarely useful (formal events sparse)
✗ Users had less wardrobe than assumed (simpler matching needed)
✗ $30 was too high; $15 felt right
✓ 11/20 converted to (simulated) paid after trial
 
PIVOTS FOR ACTUAL PRODUCT:
- Drop calendar integration (save 2 months dev)
- Simplify wardrobe cataloging (fewer items than expected)
- Price at $15; upsell advanced features
- Add capsule wardrobe recommendations (unexpected request)
 
## Investment Decision
✓ Proceed with reduced-scope build
Expected payback: 6-month development cost recovered in 18 months
Without Concierge MVP: Would have built wrong features, wrong price

Manual Before Automated

Before building an algorithm, can a human do it? Before building integration, can you copy-paste? Before building a dashboard, can you email spreadsheets? Automation is expensive; validation is cheap. Validate the value before automating the delivery.

Scoping Techniques: Cutting to the Bone

Most MVP scoping fails not from lack of ideas but from inability to cut. Every feature feels essential until you apply rigorous scoping techniques.

The Brutal Prioritization Framework:

Cutting Questions

•Can users complete the core journey without this? If yes, cut it.
•Does this test a hypothesis, or is it 'nice to have'? If nice-to-have, cut it.
•Could we manually handle this for the first 100 users instead of building it? If yes, defer it.
•Is this for user experience or for our convenience? If the latter, cut it.
•Would launching without this prevent learning? If no, cut it.
•Could we link to an existing solution instead of building our own? If yes, link.
•What's the simplest possible implementation that achieves 80% of the value? Do that version.

Scope Reduction Strategies:

MVP Scope Reduction Patterns
Pattern	Full Scope	MVP Scope	Effort Saved
Reduce Platforms	iOS, Android, Web	Web only (responsive)	60-70%
Reduce Role Types	Customer, Admin, Partner	Customer only	50%
Reduce Data Variants	Handle all currencies	USD only	30%
Reduce Entry Points	5 ways to start workflow	1 primary path	40%
Reduce Integrations	Connect to 10 services	Manual import CSV	60%
Reduce Configurability	User customizes everything	Sensible defaults only	40%
Reduce Error Handling	Graceful recovery for all	Happy path + critical errors	30%
Reduce Historical Data	10 years of history	Current data only	20%
Reduce Polish	Animations, microinteractions	Functional, clear, plain	20%
Reduce Scale Prep	Built for 1M users	Built for 1,000 users	30%

scope-reduction.md
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
# Scope Reduction: Artisan Marketplace MVP
 
## Original Vision (6+ months)
- Multi-vendor marketplace
- Seller dashboard with analytics
- Buyer accounts with order history
- Advanced search with filters
- Payment: cards, PayPal, Apple Pay
- Shipping calculation + label printing
- Review and rating system
- Wishlists and favorites
- Email marketing integration
- Mobile apps (iOS, Android)
- Admin dashboard
- Fraud detection
- Multi-currency
 
## MVP After Brutal Prioritization (6 weeks)
 
### What We Keep (Core Journey: Browse → Buy → Receive)
1. Product listing pages (manual upload by us)
2. Product detail page with images + description
3. Single checkout flow (shipping address, card payment)
4. Order confirmation email
5. Seller email notification for new orders
 
### What We Cut (and How We Handle It)
| Cut Feature        | Handling Strategy                          |
|--------------------|--------------------------------------------|
| Seller dashboard   | Email order details; sellers respond       |
| Buyer accounts     | Guest checkout only                        |
| Advanced search    | Browse by category; manual curation        |
| PayPal, Apple Pay  | Card only via Stripe                       |
| Shipping calc      | Flat rate; refine based on real orders     |
| Label printing     | Sellers handle shipping manually           |
| Reviews            | Curate testimonials manually               |
| Wishlists          | "Email me when back" for sold out          |
| Email marketing    | Manual Mailchimp; no integration           |
| Mobile apps        | Responsive web                             |
| Admin dashboard    | Direct database queries by founder         |
| Fraud detection    | Manual order review; Stripe's basic flags  |
| Multi-currency     | USD only                                   |
 
### MVP Feature Count
Initial wish list: 40+ features
After prioritization: 8 features
Reduction: 80%
 
### Success Criteria
- 500 visitors in first month
- 20 orders completed
- 50%+ seller satisfaction with process
- Payment processing < 3% failure rate
- Customer support manageable by 1 person
 
### After MVP Validation
If successful → Build seller dashboard (highest conversion barrier)
If struggling → Investigate why, pivot before building more

Scope Creep Kills MVPs

The most common MVP failure mode is gradual scope creep. 'Since we're building accounts anyway, let's add password reset. And if we have password reset, we should have email verification. And since we're sending emails...' Each addition is reasonable; together, they delay launch by months.

MVP Anti-Patterns: What to Avoid

Despite widespread knowledge of MVP principles, teams repeatedly fall into the same traps. Recognizing these anti-patterns helps you avoid them.

MVP Anti-Patterns

•The 'MVP V3' — Team keeps iterating on MVP indefinitely without shipping. The MVP becomes the product, but product was never validated. Launch. Then iterate.
•The 'Complete MVP' — Every feature is in scope; MVP ends up taking 12 months. If your MVP takes more than 12 weeks to build, it's probably not minimum.
•The 'Perfect MVP' — Polishing and refinning delays launch. 'We'll launch after one more iteration.' Ship the 80% solution; polish based on feedback.
•The 'Invisible MVP' — MVP is built but never shown to users. 'We're not ready for real users yet.' An unseen MVP teaches nothing.
•The 'Vanity MVP' — Collects vanity metrics (signups, page views) instead of validation metrics (usage, payment, retention).
•The 'Feature Parity MVP' — 'We can't launch until we match competitor X's features.' You can; differentiation beats parity.
•The 'Nobody Will Pay MVP' — Giving MVP away free avoids testing the hardest assumption: will people pay?
•The 'Ignore Feedback MVP' — Collecting user feedback but not acting on it. Learning means changing based on evidence.
•The 'We Know Better MVP' — Disregarding negative signal because 'users don't understand our vision.' They understand their problems.

The Most Dangerous Anti-Pattern: Fake Viability

This occurs when teams ship something 'minimum' that users can't actually use:

Sign-up walls before demonstrating value
Broken core flows with 'we'll fix it' attitude
Missing critical steps in the journey ('just imagine the payment worked')
Technical debt so severe users encounter bugs immediately

When users encounter a fake-viable MVP, they leave. But the lesson isn't 'users don't want this product'—it's 'users couldn't evaluate this product.' Critical learning is lost.

Signs Your MVP Has Problems

•Taking > 12 weeks to build
•More than 20 features
•Multiple user role types
•Complex integrations
•'Phase 2' has core features
•Team uncomfortable showing it
•Users can't complete core task

Signs Your MVP Is Right-Sized

•Built in 4-12 weeks
•5-10 features maximum
•Single primary user type
•Manual processes for edge cases
•Complete core journey
•Team eager to get feedback
•Clear metrics for success

Time-Box Your MVP

If you can't define what's in your MVP, time-box it: 'What can we build in 6 weeks that tests our core hypothesis?' Time constraints force prioritization decisions that endless scope discussions never resolve.

Measuring MVP Success

An MVP succeeds if it generates validated learning—not if users love it. You might learn that your hypothesis was wrong, and that's a successful MVP. The metrics you choose determine what you learn.

The Metric Hierarchy:

MVP Metrics by Validation Goal
Validation Goal	Primary Metric	Secondary Metrics	Watch Out For
Problem-Solution Fit	Task completion rate	Time to complete, error rate, abandonment point	Usability issues conflated with value issues
Demand Validation	Signup/waitlist conversion	Landing page time, return visits, email open rate	Vanity signups that never activate
Value Hypothesis	Retention (Day 1, 7, 30)	Session length, feature usage, return rate	Forced engagement (notifications) inflating numbers
Monetization Hypothesis	Conversion to paid	Trial-to-paid conversion, churn, price sensitivity	Deep discounts distorting willingness to pay
Referral/Virality	K-factor, NPS, sharing rate	Organic signups, word-of-mouth attribution	Incentivized referrals that don't indicate organic spread

Defining Success Criteria Before Launch:

Before launching your MVP, define explicit success criteria. What numbers would convince you to:

Double down — Strong signal; expand investment
Iterate — Promising signal; refine and test again
Pivot — Weak signal on core hypothesis; change direction
Kill — No signal; stop before wasting more resources

Without pre-defined criteria, you'll rationalize any result as success.

success-criteria.md
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
# MVP Success Criteria: Recipe Subscription Service
 
## Hypothesis
Home cooks will pay $8/week for curated recipes and automated shopping lists.
 
## MVP Definition
- 4-week trial
- Weekly email with 5 recipes + shopping list
- Stripe payment for $8/week after trial
- Manual curation (by founder)
 
## Success Criteria (Decide BEFORE launch)
 
### DOUBLE DOWN (Strong Signal)
- Trial signup: > 1,000 users
- Trial engagement: > 50% open weekly emails
- Conversion: > 10% convert to paid
- Retention: > 70% Month 2 retention
→ Proceed with full product build
 
### ITERATE (Promising Signal)
- Trial signup: 300-1,000 users
- Trial engagement: 30-50% open emails
- Conversion: 5-10% convert to paid
- Retention: 50-70% Month 2 retention
→ Investigate drop-off; test improvements
 
### PIVOT (Weak Core Signal)
- Trial signup: < 300 users (demand exists but not finding us)
  → Test different channels before pivoting
- Engagement: < 30% open emails (content/format wrong)
  → Test different recipe styles
- Conversion: < 5% (price or value mismatch)
  → Test different prices $4-12 range
→ Major change to offering or audience
 
### KILL (No Signal)
- Can't acquire 100 users despite $500 ad spend
- < 10% open emails after 2 weeks
- 0 paid conversions
- Qualitative feedback uniformly negative
→ Abandon this direction; thesis was wrong
 
## Timeline for Decision
- Week 0-4: Run trial, collect data
- Week 5: Analyze results against criteria
- Week 6: Execute decision (build/iterate/pivot/kill)
 
NO MOVING GOALPOSTS: These numbers were set before launch.

Avoid Selective Metrics

After launch, there's temptation to focus on the one metric that looked good while ignoring the five that looked bad. Great signups but no engagement means the conversion works and the product doesn't. Measure the complete picture.

Beyond MVP: Evolution and Scaling

A successful MVP is a beginning, not a destination. Once you've validated your core hypothesis, you face new challenges: how to evolve the product, when to address technical debt, and how to scale what you've proven.

The Post-MVP Roadmap:

Post-MVP Evolution Stages

•Strengthen core value — Before adding features, ensure the core experience is excellent. Polish what works before adding what's missing.
•Address highest-value gaps — Based on MVP feedback, which missing features caused the most friction or churn?
•Refactor strategic debt — The MVP likely has shortcuts that will slow future development. Address architectural issues before they compound.
•Expand user segments — If MVP targeted power users, consider mainstream users. If targeted one industry, consider adjacent industries.
•Add monetization depth — More pricing tiers, enterprise features, add-ons for validated segments.
•Build for scale — Only after product-market fit is proven, invest in infrastructure for growth.

When to Throw Away the MVP:

Sometimes the right move is to rebuild from scratch. Indicators that MVP rewrites are justified:

Validation succeeded, but MVP was never meant to scale — Concierge MVPs can't grow; code MVPs might have been intentionally quick-and-dirty
Core architecture blocks critical features — If adding necessary features requires rearchitecting everything, start fresh with the right architecture
Technical debt is compounding faster than feature delivery — When every feature takes 3x longer due to MVP shortcuts
Product has pivoted significantly — If you've pivoted to a different product, carrying forward old code may hurt more than help

When NOT to Throw Away the MVP:

'It's messy' — Clean it incrementally instead
'We learned a lot and could do it better' — So apply learnings to new features, not rewrites
'New framework/language is better' — Technology preferences aren't business reasons
'New team members don't like the old code' — Help them understand it instead

post-mvp-decisions.md
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
# Post-MVP Decision Framework
 
## Current State Assessment
 
### What MVP Proved
- Core value hypothesis: VALIDATED ✓
- Target audience: Power users in small agencies
- Price point: $20/user/month acceptable
- Core feature: Automated reporting saves 5 hrs/week
 
### What MVP Revealed (Unexpected)
- Users want team collaboration (not just single user)
- Integration with Slack is high-value
- Mobile access is low priority
- Onboarding is significant friction point
 
### Technical Reality
- Codebase: Monolith with 40% test coverage
- Scalability: Handles ~100 concurrent users
- Technical debt: 3 significant areas need attention
- Time to add feature: 2-3x slower than ideal
 
## Post-MVP Priority Stack
 
### Phase 1: Strengthen Core (Weeks 1-6)
Focus: Improve onboarding, retention
| Priority | Item                      | Impact         |
|----------|---------------------------|----------------|
| 1        | Onboarding improvements   | -30% churn     |
| 2        | Performance optimization  | +20% satisfaction |
| 3        | Critical bug fixes        | -50% support tickets |
 
### Phase 2: Expand Value (Weeks 7-14)
Focus: Top requested features from validated users
| Priority | Item                      | Impact         |
|----------|---------------------------|----------------|
| 1        | Team collaboration        | +40% revenue (multi-seat) |
| 2        | Slack integration         | +15% retention |
| 3        | Advanced reporting        | +Enterprise tier |
 
### Phase 3: Address Debt (Weeks 15-18)
Focus: Enable sustainable growth
| Priority | Item                      | Impact         |
|----------|---------------------------|----------------|
| 1        | Refactor auth system      | +Security, +Features |
| 2        | Add integration tests     | -Regression bugs |
| 3        | Migrate to microservices  | +Scale capacity |
 
### Phase 4: Scale (Weeks 19+)
Focus: Growth infrastructure
| Priority | Item                      | Impact         |
|----------|---------------------------|----------------|
| 1        | Horizontal scaling prep   | Handle 10x users |
| 2        | Analytics infrastructure  | Better decisions |
| 3        | Second market expansion   | New segment     |
 
## Decision: Rewrite or Iterate?
DECISION: Iterate
 
Rationale:
- MVP architecture supports Phase 1-2 features
- Technical debt is localized, not systemic
- Rewrite would delay growth by 3-4 months
- Incremental refactor during Phase 3 is sufficient

MVP Is a Phase, Not a Product

The biggest mistake is treating MVP as a destination. It's a validation stage. Once validated, you're no longer building an MVP—you're building a product. The constraints that defined MVP (minimum, fast, learning-focused) give way to product constraints (quality, scalability, user delight).

Summary: Mastering MVP Definition

MVP definition is the art of building just enough to learn what you need to know. Done well, it accelerates your path to product-market fit. Done poorly, it wastes months building the wrong thing or produces something too broken to learn from.

Key Takeaways

•MVP is about learning, not launching — The goal is validated learning with minimum effort, not shipping a minimal product.
•Both words matter equally — Too minimal isn't viable; too viable isn't minimum. Find the intersection.
•Focus on riskiest assumptions — Include only what's needed to test hypotheses that would kill the product if wrong.
•Consider non-product MVPs first — Landing pages, videos, concierge, and piecemeal approaches often validate faster than code.
•Viability has multiple dimensions — Functional, reliable, usable, performant, valuable, secure, legal. Meet minimums on all.
•Cut brutally but not randomly — Use systematic questions to determine what makes the cut.
•Define success criteria before launch — Know what numbers mean double down, iterate, pivot, or kill.
•MVP is a phase, not a product — After validation, evolve deliberately from MVP to product.

Module Complete:

Congratulations! You've completed the Functional Requirements module. You now possess the complete toolkit for:

Identifying core features that define your system's identity
Capturing requirements through user stories and use cases
Prioritizing features using industry-standard frameworks
Defining MVPs that are genuinely minimum yet truly viable

These skills form the foundation for everything else in system design. With clear requirements, you can now proceed to the remaining phases of the System Design Framework: non-functional requirements, estimation, high-level design, deep dives, and validation.

Module Complete

You've mastered Functional Requirements—the critical first step in any system design. You can now identify what a system must do, capture those requirements precisely, prioritize for maximum impact, and scope MVPs that validate your riskiest assumptions. These skills distinguish engineers who build the right things from those who merely build things right.