MVP culture started as a healthy idea: learn with less waste. Somewhere along the way it became permission to ship something half-true, broken edges, no ops story, and a silent hope that users will forgive the gaps.
I am less interested in that bargain. I would rather release a smaller product that works end to end than a wide surface that collapses the first time a real customer leans on it.
Working product, narrow scope
A working product has a defined job, clear empty states, honest errors, and a path for the operator when something fails. It does not need every feature. It needs integrity. Users feel the difference between “prototype energy” and “someone thought about Tuesday afternoon.”
- Cut scope before you cut reliability.
- Instrument the release, if you cannot see it, you did not ship it.
- Write the support path: who gets paged, what gets rolled back.
- Prefer one complete flow over five incomplete ones.
Learning still matters. You can learn from a focused release. What you cannot learn from is a public apology tour because the MVP was never operable. Build to be used, then expand.
Key takeaways
What to remember
- Cut scope before you cut reliability.
- One complete flow beats five unfinished ones.
- Instrument the release or you did not ship.
