Unlock This Playbook
Create a free account to access execution playbooks
Already have an account? Sign in
Chapter 4: Solution Design & Architecture
Prioritization frameworks, Build vs. Buy, No-Code revolution.
The Art of Saying No
Feature bloat kills startups. Your backlog of "good ideas" will always exceed your capacity to execute. The difference between successful founders and struggling ones isn't their ability to say yes—it's their discipline to say no.
Effective prioritization isn't about what to build. It's about what not to build.
The Core Insight
Every feature you add increases complexity, slows velocity, and dilutes focus. Your goal isn't to build more—it's to build only what matters for finding product-market fit.
Bug #1: Building Based on Opinions
In the absence of frameworks, feature decisions get made by whoever argues loudest. This leads to bloated products that try to do everything and delight no one.
The Bug
"The CEO wants feature X, so we're building it."
Decisions based on opinions (even the founder's) lead to products designed for imaginary users. HiPPO (Highest Paid Person's Opinion) kills startups.
The Fix
Use prioritization frameworks.
MoSCoW for scope definition, Kano for lovability, RICE for quantitative ranking. Let frameworks—not opinions—drive decisions.
Framework #1: MoSCoW Method
The simplest framework for defining MVP scope. Force every feature into one of four categories:
Must Have
Non-negotiable. Without this, the product cannot launch. The product is useless without it.
Should Have
Important but not vital. Painful to leave out, but the product works without it.
Could Have
Nice to have. Desirable if time permits, but easily cut without impact.
Won't Have
Explicitly out of scope. Saying "no" clearly prevents scope creep.
MoSCoW Exercise
Apply MoSCoW to a simple app (e.g., a task manager):
| Feature | Category | Rationale |
|---|---|---|
| Create a task | Must | Core value proposition |
| User login | Must | Data persistence requires identity |
| Due dates | Should | Important, but MVP works without it |
| Password reset | Should | Can handle manually at first |
| Dark mode | Could | Nice, but doesn't affect core value |
| Team collaboration | Won't | Explicitly V2 scope |
Framework #2: The Kano Model
MoSCoW tells you what's required. Kano tells you what creates delight. Essential for building an MLP (Minimum Lovable Product).
Basic (Threshold)
Expected features. Their absence causes dissatisfaction, but their presence doesn't increase satisfaction.
Example: A car has brakes. You don't delight in brakes—but you're furious if they're missing.
Performance
Linear satisfaction. More is better. Less is worse. Customers consciously evaluate these.
Example: Battery life, speed, storage. Customers compare these across products.
Delighters (Excitement)
Unexpected joy. Their absence isn't noticed, but their presence creates love and advocacy.
Example: The first time you swiped to unlock an iPhone. Unexpected magic.
The MLP Formula
An MLP = All Basic features + At least one Delighter. MVPs often ignore Delighters, which is why they fail to generate word-of-mouth. Find your one magical moment.
Framework #3: RICE Scoring
When you have data and need quantitative rigor, use RICE. It removes the "loudest voice in the room" problem.
The RICE Formula
RICE Score = (Reach × Impact × Confidence) / Effort
| Factor | Definition | Scale |
|---|---|---|
| Reach | How many users will this impact per quarter? | Actual number (100, 1000, 10000) |
| Impact | How much will it affect each user? | 3 = Massive, 2 = High, 1 = Medium, 0.5 = Low, 0.25 = Minimal |
| Confidence | How sure are we about the estimates? | 100% = Data, 80% = Research, 50% = Gut |
| Effort | How long will it take to build? | Person-months (0.5, 1, 2, 3, etc.) |
RICE Example
| Feature | Reach | Impact | Confidence | Effort | Score |
|---|---|---|---|---|---|
| Push notifications | 1000 | 2 | 80% | 1 | 1600 |
| Advanced filters | 500 | 1 | 50% | 2 | 125 |
| Export to PDF | 200 | 0.5 | 80% | 0.5 | 160 |
Push notifications wins: high reach, meaningful impact, and relatively low effort.
Bug #2: Building Commodities From Scratch
"Not Invented Here" syndrome kills startups. Founders waste months building authentication, payment processing, or email systems—commodities that provide zero differentiation.
The Bug
"We need to build our own auth system for security."
Every week spent on commodities is a week NOT spent on your core differentiator. You're not competing on auth. You're competing on your unique value.
The Fix
Apply the Build vs. Buy Matrix.
Build ONLY what differentiates you. Buy everything else. Use Stripe for payments, Auth0 for login, Intercom for chat. Focus your engineering on your moat.
The Build vs. Buy Decision Matrix
Simple Decision Framework
| Core Differentiator (Why customers buy you) |
Parity Feature (Everyone has it) |
|
|---|---|---|
| High strategic value | BUILD This is your IP. Invest deeply. |
BUY/PARTNER Get best-in-class via API. |
| Low strategic value | BUY Don't waste time here. |
DEFINITELY BUY This is commodity. Use SaaS. |
Buy, Don't Build
Payments: Stripe, PayPal
Auth: Auth0, Clerk, Firebase Auth
Email: SendGrid, Resend, Postmark
Chat: Intercom, Crisp, Zendesk
Analytics: Mixpanel, Amplitude, PostHog
Hosting: Vercel, Railway, Render
The No-Code/Low-Code Revolution
The Build vs. Buy binary has been disrupted. Now there's a third path: Compose. Assemble your MVP from existing tools without writing traditional code.
No-Code
Examples: Bubble, Webflow, Airtable, Notion
Best for: B2C concepts, marketplaces, internal tools
Extremely fast, cheap, easy to iterate
Platform lock-in, scalability limits
Low-Code
Examples: Retool, OutSystems, Appsmith
Best for: B2B apps, complex workflows, internal tools
Faster than custom, allows code injection
Can be expensive, requires dev skill
Custom Code
Examples: React, Django, Rails, Node.js
Best for: High-performance, unique algorithms, deep tech
Full control, no platform limits
Slow, expensive, high maintenance
The Strangler Fig Pattern
Start with No-Code. As specific modules break due to scale, replace only that module with custom code while keeping the rest on No-Code. Don't optimize for scale you don't have. 99% of startups never hit No-Code limits.
Your Solution Design Checklist
Before Starting Development
| MoSCoW applied: Every feature categorized, "Won't Have" explicitly defined | |
| Delighter identified: You have at least one "magical moment" in your MVP | |
| Build vs. Buy decided: Only building your core differentiator | |
| Tech stack chosen: Matched complexity to validation stage (not over-engineering) | |
| Timeline realistic: Can launch MVP in 4-8 weeks, not 4-8 months |
Key Takeaways
Remember These Truths
- Saying no is more important than saying yes. Use frameworks to make ruthless cuts.
- MoSCoW defines scope. "Won't Have" is as important as "Must Have."
- Kano creates love. Include one Delighter to generate word-of-mouth.
- Build only what differentiates you. Buy everything else.
- Start with No-Code. Don't optimize for scale you don't have.
Now that you know what to build and how, let's explore the metrics that tell you whether it's working.
Prioritize Your Features with AI
Use our MVP Feature Prioritization tool to apply MoSCoW, Kano, and RICE frameworks to your backlog and get AI-powered recommendations.
Ready to Build Your MVP?
LeanPivot.ai provides 50+ AI-powered tools to help you design, build, and launch your minimum viable product.
Start Free TodayWorks Cited & Recommended Reading
RAT vs MVP Philosophy
- 1. Ries, E. (2011). The Lean Startup. Crown Business.
- 2. "Why RAT (Riskiest Assumption Test) beats MVP every time." LinkedIn
- 3. "Pretotyping: The Art of Innovation." Pretotyping.org
- 6. "Continuous Discovery: Product Trio." Product Talk
- 7. "MVP Fidelity Spectrum Guide." SVPG
Minimum Lovable Product
- 8. Olsen, D. (2015). The Lean Product Playbook. Wiley.
- 9. "From MVP to MLP: Why 'Viable' Is No Longer Enough." First Round Review
- 10. "Minimum Lovable Product framework." Amplitude Blog
Hypothesis-Driven Development
- 11. Gothelf, J. & Seiden, J. (2021). Lean UX. O'Reilly Media.
- 12. "Hypothesis-Driven Development in Practice." ThoughtWorks Insights
- 13. "Experiment Tracking Best Practices." Optimizely
- 14. "Build-Measure-Learn: The Scientific Method for Startups." Harvard Business Review
Assumption Mapping
- 15. Bland, D. & Osterwalder, A. (2019). Testing Business Ideas. Wiley.
- 16. "Risk vs. Knowledge Matrix." Miro Templates
- 17. "Identifying Riskiest Assumptions." Intercom Blog
User Story & Impact Mapping
- 20. Patton, J. (2014). User Story Mapping. O'Reilly Media.
- 21. Adzic, G. (2012). Impact Mapping. Provoking Thoughts.
- 22. "Jobs-to-Be-Done Story Framework." JTBD.info
- 23. "The INVEST Criteria for User Stories." Agile Alliance
- 24. "North Star Metric Framework." Amplitude
- 25. "Opportunity Solution Trees." Product Talk
- 26. Torres, T. (2021). Continuous Discovery Habits. Product Talk LLC.
Pretotyping Techniques
- 27. Savoia, A. (2019). The Right It. HarperOne.
- 28. "Fake Door Testing Guide." UserTesting
- 29. "Wizard of Oz Testing Method." Nielsen Norman Group
- 30. "Concierge MVP Explained." Grasshopper
Prioritization Frameworks
- 31. "ICE Scoring Model." ProductPlan
- 32. "RICE Prioritization Framework." Intercom
- 33. "Kano Model for Feature Analysis." Folding Burritos
- 34. "MoSCoW Method Guide." ProductPlan
Build vs Buy & No-Code
- 35. "No-Code MVP Tools Landscape." Makerpad
- 37. "Technical Debt in Early Startups." a16z
- 38. "Prototype Fidelity Selection." Interaction Design Foundation
- 39. "API-First Development Strategy." Swagger
- 40. "Rapid Prototyping with Bubble & Webflow." Bubble Blog
Metrics & Analytics
- 41. Croll, A. & Yoskovitz, B. (2013). Lean Analytics. O'Reilly.
- 42. "One Metric That Matters (OMTM)." Lean Analytics
- 43. McClure, D. "Pirate Metrics (AARRR)." 500 Startups
- 44. "Vanity Metrics vs. Actionable Metrics." Mixpanel
- 45. "Cohort Analysis Deep Dive." Amplitude
- 46. "A/B Testing Statistical Significance." Optimizely
- 47. "Product Analytics Instrumentation." Segment Academy
- 48. "Activation Metrics Framework." Reforge
- 49. "Leading vs Lagging Indicators." Productboard
- 50. "Retention Curve Analysis." Sequoia Capital
- 51. "Feature Adoption Tracking." Pendo
- 52. "Experimentation Velocity Metrics." ExP Platform
Launch Operations & Analysis
- 53. "Soft Launch Strategy." Mind the Product
- 54. "Feature Flag Best Practices." LaunchDarkly
- 55. "Beta Testing Program Design." BetaList
- 56. "Customer Feedback Loop Systems." Canny
- 57. "Rollback Strategy Planning." Atlassian
- 58. "Why Startups Fail: Post-Mortems." CB Insights
- 59. "Pivot vs Persevere Decisions." Steve Blank
- 60. "Learning from Failed Experiments." HBR Innovation
This playbook synthesizes methodologies from Lean Startup, Design Thinking, Jobs-to-Be-Done, Pretotyping, and modern product management practices. References are provided for deeper exploration of each topic.