Making Sense of MVP

There’s a popular drawing used every time I see a presentation on Agile development and the idea of releasing a Minimal Viable Product (MVP). It shows two ways to develop a product, starting with the requirement, “I need to get from point A to point B more quickly.”

Making sense of MVP

Henrik Kniberg created this drawing, and he shared his thoughts on the image earlier this year. I think it makes a great read, and has a couple examples of the MVP process in action.

I always thought this drawing did a poor job of selling MVP. It doesn’t show any upfront requirements-gathering process. Any requirements-gathering would reveal whether the customer needed motorized transportation; if the product needed to carry any cargo, products 1, 2, 3, and 4 from the bottom row would all be unusable!

[In product 4 in the top row,] A lot of time has passed without any actual user testing, so the product is most likely riddled with design flaws based on incorrect assumptions about what people need.

The drawing ignores paper prototypes and doesn’t give the user ability to change design thinking in the top example of the process. As each product in the top row is presented to the user, there’s really a dotted-outline of all the parts that are missing from the product. The user should be able to see the end result, and give feedback as development continues.

[In the bottom row,] we’re not trying to make the customer happy at this point. We might make a few early adopters happy… but our main goal at this point is just to learn.

But my main complaint with the drawing is that it doesn’t show a proper time scale for each release of the product. Following a real (in my mind) Agile MVP process, the skateboard in the bottom row would be released sometime before the wheel in the top row, during the time the whole top row is being designed. This is great! User testing and feedback is gathered early!

But as the product release cycles continue, each release in the bottom row will take longer and longer. There should be a large gap of empty space between 4 and 5, as large as the entire top row. No hardware or design part of step 4 is reusable in step 5, every piece is new.

I do agree with the message of the drawing. The goal of the MVP process is to reveal that,

The bicycle may turn out to be a much better product than the car originally envisioned. In fact, while testing out this product we may learn that the paths are too narrow for a car anyway.

I just think that a hardware metaphor falls apart when you look at the time scales involved in the design and implementation of these large software products.