Minimum Viable Product (MVP) – “Like This / Not Like This” Redux (MVP) – “Like This / Not...

5
Minimum Viable Product (MVP) – “Like This / Not Like This” Redux Michael J Geiser

Transcript of Minimum Viable Product (MVP) – “Like This / Not Like This” Redux (MVP) – “Like This / Not...

Page 1: Minimum Viable Product (MVP) – “Like This / Not Like This” Redux (MVP) – “Like This / Not Like This” Redux

Minimum Viable Product (MVP) – “Like This / Not Like This”

Redux

Michael J Geiser

Page 2: Minimum Viable Product (MVP) – “Like This / Not Like This” Redux (MVP) – “Like This / Not Like This” Redux

Minimum Viable Product (MVP) – “Like This / Not Like This” Redux

If you are online on LinkedIn, or almost any other site that discusses Agile SDLCs in the last month, you have likely seen this diagram (or a variation of it) posted once or a hundred times:

I get the concept behind the diagram; it is frequently better to have a working product that is in development with targeted iterative releases that over time evolves the product to reach the full set of features required but the interim releases meet a Minimum Viable Product definition.

This diagram however completely misses the point of what an MVP is and is over simplified to such a dramatic extent that it really flips the “Not Like This” and “Like This” categories in this pictograph.

Let’s start with a definition of a Minimum Viable Product. Most people will agree that an MVP is the product which has only the set of features that will allow the users to successfully perform the function the product was intended to deliver; no more, no less and maybe sacrificing some polish and finish. The MVP is not a final destination but a stepping stone for stakeholder and early adopter feedback to improve the process as the final full-feature product development is completed.

If my product requirements are for "a motorized closed vehicle with room for 4 and minimal cargo" (like the last image in the “Like This” section), the skateboard, scooter, bike and motorcycle absolutely do even come close to meeting my requirements for an MVP; they are not even workable interim steps to an MVP. If the auto isn’t the final product requirement, why are we not stopping with a skateboard? An auto in this case would be a gold plating of the requirements.

There are other fundamental issues with this representation. It implies the time to complete each of the four or five steps is equal; they’re essentially Sprints.

Page 3: Minimum Viable Product (MVP) – “Like This / Not Like This” Redux (MVP) – “Like This / Not Like This” Redux

In the “Like This” path, the successive Sprints do not evolve from or build upon prior Sprints. Every Sprint, you are literally throwing away all work done to date and starting on a completely different product. I think the skills and frameworks developed to build a skateboard might help you build a scooter but they lend little help to building a bicycle, motorcycle or auto.

In “Like This”, it appears to take an equal amount of time to build a skateboard, scooter, bike, motorcycle and auto. Clearly this is not reality; Agile is about accepting reality. In the “Not Like This” section, we’ve established that it takes 4 Sprints to build a car. I also would estimate given the complexity of a skateboard and scooter being 1 story point, a bicycle would have to be at least two, a motorcycle would likely be at least a 3 and an auto would be a 5 or 8 (let’s go with 5 for the auto to stick closer to the original 4).

Here is my “MVP - Like This / Not Like this”:

If my MVP is "a motorized closed vehicle with room for 4 and minimal cargo"; producing the skateboard, scooter, bike and motorcycle are wasted effort and unnecessary expenses that cause me to take 2.5x longer to get to my final product version with no corresponding benefit for the delay and additional cost.

In my version of MVP “Like This”; each Sprint produces a testable deliverable with functionality that builds on prior Sprint work. After Sprint 1, I can validate the axles are working according to functional requirements. After Sprint 2 I can roll it around the development area and perform more tests. After Sprint 3, I have something like a dune buggy and may even be able to drive it under its own power and get some Stakeholder feedback. After Sprint 4 I’d be able to test most of the features of the auto. Sprint 5 delivers a finished product.

The path to a working auto that meanders through producing the skateboard, scooter, bike and motorcycle first will likely take 12 Sprints not 5 Sprints. My version of the MVP “Not Like This” diagram more realistically charts this path. You cannot jump from scooter to bicycle in one

Page 4: Minimum Viable Product (MVP) – “Like This / Not Like This” Redux (MVP) – “Like This / Not Like This” Redux

sprint. You cannot jump from bicycle to motorcycle in one Sprint. You certainly cannot jump from motorcycle to auto in one Sprint.

So, given the additional time to market, wasted effort and expenses of the skateboard, scooter, bike, motorcycle and auto route why would this be the desirable "Like This" option?