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.
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 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?
VP of Engineering at Mindless | Innovating to Improve Mental Health | Tackling Anxiety & Depression Head-On
7 年The Author seems to not understand that Users rarely fully understand what they want in the beginning. This is why agile development yields more success projects than waterfall. The standard skateboard to convertible image is assumed to have a user story about getting from point A to B in the beginning and eventually a convertible over the iterations of feedback. The key is to notice that the waterfall methodology they ended up with an enclosed car and are happy but in the agile process they had the convertible and were super happy.
Manager, IT Architecture
7 年I think you are interpreting the image too literally, and also that you've started from not the best image. First off, no one builds a skateboard to get to a car, but they do build a newsletter signup form to get to a community website. MVP in that instance is valid and reusable. Second, the image above shows the same outcome in both approaches. Look at the image below and you'll see the agile approach yields a convertible, not an enclosed car, presumably because during an earlier iteration, users found they liked the feel of the wind in their hair. Development informs discovery in the agile process. https://herdingcats.typepad.com/.a/6a00d8341ca4d953ef01a511e114a3970c-pi Finally, the agile process does not start with a product description like "a motorized closed vehicle with room for 4 and minimal cargo". That's the waterfall process. You're defining the product from the outset rather than describing what success looks like. Agile start more often with user stories, e.g. "As a parent, I want a way to quickly transport myself and my family distances between 20 and 200 kilometers so that we can visit friends and go to soccer tournaments." There is no mention of a motor or a vehicle. Including them constrains the set of possible solutions and locks you into a path towards a predetermined outcome. I should add in your picture the stakeholders look happy throughout the agile process. They should not. MVP is not full-featured. You can't get four people to soccer on a skateboard, but you can get to school pretty well on one. MVP is a compromise, and any good compromise leaves everyone involved equally dissatisfied. Stakeholders at the MVP stage should be described with frowny face, not smiley face. If your stakeholders are smiling when you launch your MVP then you've missed a few deploy windows.
Coach, consultant, speaker, trainer, and board advisor helping organisations be better with intentional strategy, culture, org-design, processes, and products.
8 年A challenge of agile development is how to build a product incrementally. The benefit of creating an MVP incrementally is in getting feedback during the journey. You can use this feedback to confirm your MVP assumptions are correct and have the ability to change direction if not. In a similar incremental delivery diagram of skateboard to vehicle (https://www.edbatista.com/images/2014/Spotify-slide.jpg), the final product is a convertible. During the customer feedback of the early iterations, the team discovered that the customer really enjoyed the wind blowing in their hair so changed the requirements of the MVP to be a convertible from a hard roof. The MVP was always a car, but through emergent design and incremental delivery, we were able to adjust the product feature set and release something closer to what the customer really wanted. Agile is not optimized for efficiency. It's optimized for the ability to change direction. If effciency in your project is important then go with waterfall. But if you suspect requirements might change or you want to test your assumptions as you go, then incremental delivery and emergent design may be a better approach. Both approaches have their strengths. You just need to decide what is more important for your product/project.
The problem with the simplified image and your updated one, is we're assuming we know what the customer wants. An MVP isn't about 'delivering a minimal set of features' or 'delivering to the product requirements', it's about solving a customer problem. Suppose the customer is a single dad with 2 kids. Suppose it's a 10 year old who needs to go 3 KM down the road to a friends house. The "right" way to get to MVP is to understand what problem you're trying to solve, and who you're solving it for before over simplifying it with these diagrams.
Senior Product Owner | AI-Driven Agile Transformation Expert | Bridging Technology and Business Excellence
8 年Michael J Geiser has created a better version of the MVP “Like This” and a great story to go with it. The above or traditional version of MVP “Like This” is a bit confusing, Michael helps clarify it with his version.