Strategy and planning
MVPs and scoping
Building the smallest thing that tests the riskiest assumption, and iterating.
MVP means minimum viable product. Used well, it is a learning vehicle: the smallest experiment that tests your riskiest assumption with real users. Used badly, it is a shrug for a half-broken v1.
If you already know users want the thing, you are in scoping land — how much of the idea is this cycle worth? If you do not know whether the job is painful enough to pay for, a polished platform is premature.
Before any "MVP" project, write four lines: the assumption under test, the smallest experience that can falsify it, the evidence you will accept, and the appetite in weeks. If you cannot write those, you are starting a build.
A weak "MVP" is six months of engine, SSO and audit logs, then silence. A stronger one is a landing page, Calendly, and the first ten customers fulfilled in spreadsheets — charged from day one. If nobody pays, you learned without the engine. Shape the next slice to a fixed appetite (how much time the idea is worth), cut personas and polish before you cut the aha, and pre-declare what would make you pivot, persevere or kill.
Concepts in this section
Read them in order.
| Step | Concept | What it answers |
|---|---|---|
| 1 | Riskiest assumption | What, if false, kills the idea — and is this even an MVP? |
| 2 | Types of MVP | Concierge, Wizard of Oz, wedge, or glued tools? |
| 3 | Appetite and shaping | How much time is this idea worth? |
| 4 | Cutting scope | What can you drop without losing the aha? |
| 5 | Pivot, persevere, or kill | What evidence means continue, change, or stop? |
Engineers: propose concierge and Wizard-of-Oz paths in design reviews. Ask which assumption a six-week build is testing. Offer a one-week spike when the risk is technical, not product. Push back on "MVP" labeling when the plan is clearly a large v1 with no falsifiable hypothesis — rename it honestly and prioritize it against other large bets.
Common mistakes
- MVP as a permanent excuse for bad UX, missing trust, or no instrumentation.
- Estimating a fantasy complete product instead of shaping to an appetite.
- Automating first. Manual onboarding for the first cohort is the product job, not a failure of ambition.
- No kill criteria. Zombies stay on the roadmap for nine months.
Key takeaways
- An MVP tests a riskiest assumption; it is not a permanent excuse for a bad product.
- Choose the cheapest honest method; do unscalable work until you know what to automate.
- Shape Up-style appetite fixes time and varies scope; cut what does not serve the core value.
- Preserve the aha, trust basics and instrumentation. Predefine pivot / persevere / kill.
Further learning
Shape Up — BasecampShape Up will help you break free of “best practices” that aren’t really working, think deeper about the right problems, and start shipping meaningful projects your team can celebrate.basecamp.com
Do Things that Don't Scale — Paul GrahamDo Things that Don't Scalepaulgraham.com
SVPG articlesA partnership dedicated to teaching best practices to product teams and product leadersSilicon Valley Product Group
Minimum Viable Product: a guide — Eric RiesOne of the most important lean startup techniques is called the minimum viable product . Its power is matched only by the amount of confusi...startuplessonslearned.com
Eric Ries at Talks at Google on Lean Startup, validated learning and MVPs:
Related
Continuous discovery and assumption testing
Weekly customer contact, opportunity solution trees and cheap tests before building.
Estimation and planning
Breaking work into small tasks, estimating with ranges, de-risking early, and communicating slips before they become surprises.
Product-market fit
What fit feels like, how to measure it, the false positives that fool teams, and what changes after you find it.