The MVPs that die don't usually die in development. They die in scoping, weeks earlier, when a “minimum” product quietly becomes a small version of the five-year vision. After shipping MVPs for startups and internal ventures for years, we've compressed our scoping process into three questions.
1. What is the one behavior you need to observe?
An MVP is an instrument for observing a behavior: will restaurant owners upload their menu? Will finance teams connect their bank? Name the single behavior that validates the business, and be ruthless about it. Every screen that doesn't serve that observation is scope to cut.
2. What can be manual behind the curtain?
Users need the experience to feel complete — they don't need it to be automated. Onboarding emails can be sent by a person. The “algorithm” can be a spreadsheet for the first hundred users. Every process you keep manual is engineering weeks returned to the core flow, and you'll automate with far better information later.
3. What breaks at 100 users — and do we care?
Scaling questions are seductive and almost always premature. We ask what breaks at one hundred users, fix only that, and write down the rest. A visible backlog of known limitations is not technical debt — it's evidence you spent the budget on learning instead of infrastructure nobody needed yet.
Scoped this way, twelve weeks is a comfortable window to go from zero to a production MVP — which is exactly how we structure our MVP program.
Have a product in mind?
Tell us what you're building — we'll tell you how we'd ship it.