The acronym is “Minimum Viable Product” — not “Minimum Lousy Product.” Both words matter equally. The MVP myth is the assumption that you can sacrifice viability on the altar of minimum, ship something embarrassing, and iterate your way to a working product. We’ve watched dozens of teams try this and almost none of them survived it.
A good MVP is a thin slice through a deep stack — fewer features, but the ones that ship are full-quality, end-to-end, and feel like a product you’d pay for.
The cake metaphor
Henrik Kniberg’s drawing changed how a lot of teams think about MVPs. The bad version: build the wheels, then the chassis, then the body, then the engine. The good version: build a skateboard first; it’s less than a car but it ROLLS. Then bicycle. Then motorcycle. Then car. At every stage, the user has something usable.
The mistake teams make: they think the skateboard means a half-built car. It doesn’t. It means a fully-built skateboard. Different vehicle. Smaller scope. Equal craft.
What “viable” actually means
A viable product:
- Solves a real problem for a definable user, end-to-end
- Works without instructions or a video call to set up
- Doesn’t crash on the third action a user takes
- Looks like something a competent team built (even if simple)
- Has a path to revenue, even if revenue hasn’t started yet
Notice what’s NOT on the list: every feature you imagined. Integrations you thought you needed. Polish on every screen. Roadmap items that “might be important later.” All of those can wait. Viability is the floor; minimum is what gets you there with the smallest investment.
Three archetypes of bad MVPs
1. The half-built product
Tries to do 12 things badly instead of 3 things well. Users churn before they get to anything that works. Founders interpret churn as “we need to add the next feature.” They never recover.
2. The overbuilt MVP
9-12 months in stealth, every feature planned for V2 shipped in V1, launched to crickets. The team learns nothing during the build, then learns everything was wrong at launch. The cost of being wrong scales with the time you took being wrong.
3. The platform without a product
Beautiful architecture, hot-swappable everything, scales to a million users — zero users actually use it because no one finished the actual product surface. The platform was built for an audience that doesn’t exist yet.
How to scope a cake MVP
- Pick ONE user persona. Not three. One.
- Pick ONE job-to-be-done for that user. The single thing they’d hire your product to do.
- Map the smallest end-to-end flow that delivers that job. Sign-up. The core action. The output that makes them want to come back.
- Cut everything not on that flow. Settings page? Cut. Profile editing? Cut. Email notifications? Hand-send them for the first month.
- Build what’s left at full quality. Real auth. Real DB. Real polish on the three screens that matter.
The 8-week version
Cake MVPs typically ship in 6-10 weeks if you’re disciplined about scope. Most of what makes that timeline work isn’t engineering speed — it’s saying no, repeatedly, to scope creep that won’t change whether the product gets traction.
How we approach this
Our MVP Design & Launch engagement is built around the cake principle: 8 weeks, 3 screens, one job, full quality. We’d rather ship one polished slice than three half-built ones. The post-launch backlog can have everything — launch day cannot.
Takeaways
- The M and the V both matter. A bad MVP fails the V.
- Cake MVP = thin slice, end-to-end, full quality.
- Scope: 1 user, 1 job, the smallest flow that delivers it.
- 8-10 weeks. Most of the discipline is saying no.
