Many people ask me about the relationship between the various Lean/Agile requirement containers.
The first step is to understand that for a new product, there is a unique value proposition hypothesis. This is the area where your product/service will be different.
The next step is creating a Minimum Viable Product (MVP) to test your hypothesis. This is focused on your unique value proposition, but often also provides a few “Tablestakes” features to ensure it is a “Viable” experiment.
Note: I’ve been fighting against overblown MVPs for many years now. MVP is just one option for validating your assumptions. It’s actually not the cheapest or most effective technique you’ll find on the truth curve. The abuse of MVP is so prevalent I tend to agree with Jeff Gothelf that we need to stop using the MVP term… In the Lean Product Discovery/Management workshops, we talk about much smaller and faster experiments.
Your MVP is also a hypothesis. It might be good enough to find Product Market Fit or not. The case where each potential customer you engage tells you, “This is great, but for me to use it, I need X,” and X differs for each customer/user is shown below. This shows you are not in Product-Market Fit yet.
If on the other hand you are seeing more and more answers pointing to the SAME X then it makes sense to revise your Customer/Problem/Solution Hypothesis.
You essentially are executing a Pivot. You are building MVP2, focused on the new hypothesis derived from recent Customer Development learning from the previous MVP.
Let’s say MVP2 is successful and you are seeing real traction from early adopters. You want to increase growth and deepen penetration among your early adopters, as well as bring on new clients, some of whom are beyond the early adopters crowd. Based on the feedback you’ve been collecting and your product management research, you have a couple of areas that could drive this growth. Some of them, by the way, extend your unique value proposition, and some of them make your current product more robust.
In the case of areas with strong indication of value you might go straight for Minimally Marketable Features (MMF). Finding the minimum piece that can start bringing in growth. The MMF aims to bring in value. It assumes high confidence that there is value in this area and that we know what the product needs to be to deliver it. The main reasons to break a big feature into smaller MMFs are time-to-market and the ability to provide value across many areas, while always keeping the option to move to another location and provide value there rather than focusing for too long on a single direction. An indication that you are working on MMFs is that when one is being shipped, you feel comfortable working on the next MMF in that area. If, on the other hand, you want to wait and see if your first MMF sticks…
…then you are back in hypothesis land. But now your hypothesis is centered on a feature rather than your product. You have an area with high potential but also high uncertainty. The way to deal with it is to build a “pioneering” feature – the Minimum Viable Feature. The minimum feature that can still be viable for real use and learning from real customers.
If you learn that the MVF has hit gold, you can develop more MMFs in that area to take advantage (if that makes sense). If not, you can pivot to another approach towards that feature area, or at some point, look for an alternative growth path. Essentially, the MVF is a mini-MVP.
There you have it – the whole model. Essentially, my point is that you grow a product in uncertain markets by attempting various MVPs. Then, once you achieve Product Market Fit, you mix MMFs and MVFs depending on the level of Business/Requirements uncertainty in the areas you are focusing on.
PS Some people call the whole model a dinosaur. Others are reminded of the snake that ate an elephant from “The Little Prince”. (I’m sure there is a good connection to elephant carpaccio somewhere in here …)
While MVPs/MMFs/MVPs are atomic from a business perspective (you cannot deploy and learn from something smaller) they might be quite big from an implementation perspective.
The dinosaur carpaccio now comes in as slicing each of those pieces here to smaller slices aimed at reducing execution/technology risk. (typically these are called User Stories) Those smaller slices might have tangible business value but on the other hand some might not. It is more important for them to provide early implementation decision feedback along the way.
Feel free to use this model. Let me know what you think about it and how I can improve it!