Strategy and planning
Riskiest assumption
An MVP tests the belief that, if false, kills the idea — written so it can fail.
MVP means minimum viable product, and it is one of the most abused phrases in software. Teams ship a half-broken v1, shrug "it's an MVP," and train customers to expect mediocrity. That is not an MVP. An MVP is a learning vehicle: the smallest experiment that tests your riskiest assumption with real users.
If you already know users want the thing and the only question is implementation quality, you are not in MVP land — you are in scoping land. If you do not know whether the job is painful enough to pay for, building a polished platform is premature.
Concept
A riskiest assumption is the belief that, if false, kills the idea. Common ones: users have the problem; they will switch from the status quo; they will pay; we can acquire them at viable cost; the tech can hit required latency or accuracy. Rank assumptions; test the deadly ones first. See continuous discovery and product–market fit.
What an MVP is and isn't
| MVP is | MVP is not |
|---|---|
| A test of a specific assumption | An excuse for bad UX forever |
| Designed so results can falsify the idea | "First slice of the full vision, just later" |
| Often manual, fake-automated, or narrow | Necessarily a multi-tenant SaaS |
| Something users can respond to with behavior | A slide deck (that's a prototype pitch) |
Eric Ries (Lean Startup) framed MVP around validated learning: build–measure–learn as fast as possible. The "viable" part means the experience must be good enough that user behavior is informative. A signup page with no product behind it can test demand. A buggy editor that corrupts files tests nothing useful about willingness to pay for writing tools.
Teams also confuse MVP with MLP (minimum lovable product) or with "launch quality." Those are different bars. Lovable matters once you already know people want the core job. Launch quality (trust, security, basic polish) matters whenever real customers put real data in — even in an MVP. The learning bar and the trust bar are both required; the completeness bar is not.
Walking through a vendor-risk idea
Assumption: "Mid-market ops teams will pay $200/mo for automated vendor risk questionnaires."
Weak "MVP": six months building a full questionnaire engine, SSO, audit logs, then launch to silence.
Stronger MVP: landing page + Calendly; manually fulfill the first 10 customers in spreadsheets ("concierge"); charge from day one. If nobody books or pays, you learned without the engine. If they pay and complain about turnaround time, you learned what to automate first.
Write assumptions as falsifiable statements: "At least 40% of interviewed triage owners will complete a shared view setup in under five minutes without help." Vague assumptions ("users want collaboration") cannot fail, so they cannot teach.
Common mistakes
- Labeling a large v1 an MVP. If nothing can falsify it, it is a build, not a test.
- Cutting trust. Corrupted files and unpaid security are not "minimum."
- Unfalsifiable assumptions. "Users want X" never fails, so it never teaches.
Check yourself
You know users want the job; the only question is polish. Is this an MVP? No. That is scoping. An MVP tests an assumption that could still kill the idea.
"Users want collaboration" — good assumption? No. Write a number, a person, and a behavior that can fail. Vague cannot teach.
Key takeaways
- An MVP tests a riskiest assumption; it is not a permanent excuse for a bad product.
- Viable means behavior is informative. Trust still counts. Completeness does not.
- Write the assumption so it can fail, then pick the cheapest honest test.
Further learning
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
Next: pick a method in types of MVP.
Related
MVPs and scoping
Building the smallest thing that tests the riskiest assumption, and iterating.
Continuous discovery and assumption testing
Weekly customer contact, opportunity solution trees and cheap tests before building.
Product-market fit
What fit feels like, how to measure it, the false positives that fool teams, and what changes after you find it.