Explaining MVPs, MVFs, MMFs via the Lean/Agile Requirements Dinosaur

In the last few weeks I’ve been using a new visualization that people find useful for understanding the relationship between the various Lean/Agile requirement containers. Some people call the full model a dinosaur. Others are reminded of the snake who ate an elephant from “The Little Prince”. (I’m sure there is a good connection to elephant carpaccio somewhere in here …)

 

IMG_0449

 

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 unique.
IMG_0450

The next step is creating a Minimum Viable Product (MVP) to test your hypothesis. This is focused on your unique value proposition but typically also provides a little bit of “Tablestakes” features just to make sure it is “Viable” as a product.

 

IMG_0451

Your MVP is also an 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 in order for me to use it I need X” and X is different for each customer/user is shown below. This shows you are not in a Product Market Fit yet.

 
IMG_0452

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.

IMG_0453

 

You essentially are executing a Pivot. You are building MVP2 focused on the new hypothesis based on recent Customer Development learning generated by the previous MVP.

IMG_0454

 

Let’s say MVP2 is successful and you are seeing real traction of early adopters. You want to increase growth and are looking for deeper penetration of your early adopters as well as bringing on new clients some of them beyond the early adopters crowd. Based on feedback you’ve been collecting and your product management research you have a couple of areas that can potentially bring this growth. Some of them by the way extend your unique value proposition and some of them make your current product more robust.

IMG_0455In 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 aim of the MMF is to bring in value. It assumes high certainty that there is value in this area and that we know what the product needs to be to provide this value. The reason to break a big feature into smaller MMFs is mainly time to market and the ability to bring in value in many areas, always keeping your option to move to another area and provide value in it 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…

IMG_0456…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.

IMG_0457If 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 alternative growth path. Essentially the MVF is a mini-me version of the MVP.

IMG_0458There you have it. The full 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.

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!

 

 

 

 

Impressions from Lean Systems and Software Conference 2012 Boston

As I prepare to check out from the Boston Seaport Hotel which was the venue of this year’s LSSC conference (and did a magnificent job hosting us!), here are my highlights/impressions of the conference.

The buzzword of the conference seems to have been “Lean Startup”. It permeated into many talks (including mine) in two main aspects – One was the classic product/customer-focused Lean Startup as an alternative narrative to Lean/Agile. The other was taking the ideas of fast cycles of Validated Learning and adopting them as a narrative for the approach to change. This came up in Jeff Anderson’s ambitious and thought-provoking or even provocative talk about the transition participation engine as well as in my attempt to “fix” continuous improvement.

Where is the “Customer Development” aspect of the Lean Startup for Change approach?

I recently wrote about finding the Minimum Viable Change and have been thinking about it some more, especially while working on my presentation for upcoming Scrum Gathering Atlanta and Lean Systems and Software Conference in Boston.

While trying to think what I’m going to say about Minimum Viable Change (MVC) I began to think about how to map the MVC to Minimum Viable Product, finding Product Market Fit and the Customer Development Process.

In my mind so far, as well as in how I understand the work of Jeff Anderson and his team on this subject, the MVC is aimed at learning what approach works best in your context and doing experiments to adapt the approach. This is similar to using MVP to find Product Market Fit with your core Product capabilities as the base you pivot around. For MVC the core capability you pivot around seems to be the Hypothesis that the direction/vision you have for the organization is indeed a good fit for what the organization needs.

As I understand it, Customer Development in the Product context is about finding a customer segment for which your MVP is a good fit. In the Change context Customer Development can be about finding the customer segment for which your MVC is a good fit, but this is more similar to classic Lean Startup. When we are talking MVC we are talking about searching for the right kinds of change WITHIN a change initiative you are already running. So what is the Customer Development process? Is it searching for groups within the organization for which the MVC is good enough so they can use it to change and you can learn about the change approach together with them? Is it something that tries to verify that indeed the organization WILL benefit from this change program, rather than taking it for granted?

There is lots of value in seeking the right change approach using tactical MVCs. I think there might be at least as much value if not more in seeking fast learning on whether the change is the right one using strategic MVCs.

Come to think of it, in one of my current clients we’re using two strategic MVCs:

  • Hunch1:  Small Batches are a good idea to deal with planning waste and effectiveness as well as bang for the buck product value for investment. We are testing that hunch using an experiment involving work on Product Backlogs / MMFs / Stories in 2 product streams.
  • Hunch2: Cross-Functional work is a good idea to deal with synchronization overheads and waste involving half-developed features sitting on the shelf. We are testing that hunch using an experiment involving what we call “Discovery Kanban”. This is minimum because it is not a real Feature Team. But it provides enough learning to validate the value of Cross-Functional work. It doesn’t validate any hunches about Self-Organized teams though…
(Note we are not yet using Lean Startup disciplined Change Measure Learn loops, at least not explicitly. I look forward to doing something similar to what Jeff and his team are talking about…)

Any feedback welcome, and if you want to discuss in person, find me in Atlanta or Boston during the conferences, or check out a Kanban/Scrumban training we are opening in Atlanta just after the Scrum Gathering.

Kanban Method – Finding the Minimally Viable Change

A perfect storm is brewing:

  • Jeff Anderson has been talking about the connection between Kanban and LeanStartup
  • A discussion about Kanban Training Materials with Mike Burrows has nudged me to give more emphasis to the foundational principles and core practices.
  • I’ve been pitching a lot of Lean Startup stuff myself to Product Owners and clients in general
  • I’ve been thinking about how to use Lean Startup Change Measure Learn cycles in our approach to change at AgileSparks (and started to do small experiments at my own clients)
  • I’m working on my Lean Systems and Software Conference 2012 talk/paper about Continuous Stagnation (Which will also be featured in similar form at Scrum Gathering Atlanta btw…)

The culmination of all this is that I created a Story Map to reflect the Kanban Method approach to evolutionary change. This maps the foundational principles and core practice areas to actual core and optional practices and can help me explain Kanban in our 2-day Accredited Kanban Training (next date is 20-21 march in Israel btw) . I’m also thinking of creating exercises using this map to explain story mapping itself as well as the concept of “Minimally Viable Change/Product”.

 

If you’re interested to check out how I use this in the context of my training – see an excerpt from the materials:

Sorry but no elaborate description this time. Consider this a Minimally Viable Blog Post. If there’s interest I will write more about this…
And it seems like Jeff, Jabe myself and probably Mike and others will share experiences at LSSC12. See you there!
PS: Reminding everyone that my Brickell Key Award Nominee “refbrick200” discount code is available for 5 more days (until 14/March)…
Oh, and if you want to create such a story map for yourself, here is a CSV file with the cards. You can import it into LeanKitKanban easily and probably use it elsewhere as well. I would love to see what others do with this…