Moving past MVP
“MVP” suffers from over exposure. It has lost its original meaning. Like “beta” before it, MVP is often (usually?) used to allow corner cutting with empty promises of fixing it next time. We should be using clear language that is descriptive and has meaning built in.
Beta and MVP did mean something. Unpicking the differences is instructive.
- A beta product (compared to an MVP) is unfinished and will be iterated towards “finished”.
- An MVP (compared to a beta product) is a product with fewer features than the hypothetical full version of itself.
(I’m exaggerating and simplifying to find useful differences. Don’t be a methodology pedant yet, roll with it.)
Continuing to exaggerate and simplify gives two axes:
These axes gives four quadrants:
MVP-style releases sit approximately in the Design complete/Feature incomplete quadrant. And Beta style releases roughly in the Design incomplete/Feature complete quadrant.
The other quadrants are Incomplete/Incomplete and Complete/Complete. If your product is in Incomplete/Incomplete — everything is lean and sketchy — you’ll want to be moving fast to another quadrant. If your product is in the Complete/Complete quadrant, job done; go to the pub.
Journeys can be mapped through the quadrants. But there’s only one destination.
MVP and Beta releases become check points on a journey. We need to move past them. We can go on a design-first journey.
Or a feature-first journey.
The destination is always the next release. But for structuring our work it’s the design approach that matters. So use language that focuses on that.
—
Originally published on blog.edeverett.co.uk.
Follow me on Twitter at edeverett
