MVP, MMF, PSI, WTF? Part One: Understanding the MVP
When I’m working with new Product Owners, I frequently find that we get caught up in a sea of TLA’s (Three Letter Acronyms) when it comes time to actually start turning their Backlog of ideas into releasable increments of value.
The idea of breaking work down – breaking down our Large, Planned Out product releases into smaller increments of value is where many new Product Owners struggle. How do we take this Product Roadmap and turn it into something my Scrum teams can actually deliver on a short, regular cadence? How can I turn this huge list of Very Important Features (VIFs) into an iterative set of opportunities to learn, to deliver value, and to actually put something in the hands of our customers? In other words….
“What’s our MVP?”
“Is that our MMF?”
“Can we release this PSI as an MVP, or do we need more stories done before we have an MMF?”
Also….what???
What do these TLA’s mean? How are they different from each other? How are they related? Why should I care?
Starting with MVP (Minimum Viable Product), this three-part series will help beginner agilists understand what these TLA’s mean. How are they different from each other? How are they related? Why should I care? It will also help remind those who have been working Agile for a while why these concepts are the linchpins of agility.
For people just starting to learn about Scrum, they can turn to the Scrum Guide… and learn quickly that the Scrum Guide is silent on the how of turning a product into a collection of small, releasable increments of value.
The lack of info around this important subject can be really frustrating to new Product Owners. Hopefully, the rest of this article will clarify MVP’s, and there’s always Certified Scrum Product Owner classes to check out for more information. For now, let’s dive into the Minimum Viable Product.
The MVP
You’ve done your research, you’ve walked customer focus groups through a few rounds of Buy a Feature, and you’ve made some decisions around what your next release might look like. In fact, you’ve engaged your marketing team and you’re iterating through ideas about how to make a big splash – ads in trade magazines, promoted Tweets, Facebook posts…
But, there are still some nagging questions you have around some of the features you’re working on. You’ve thought about them, you’ve analyzed them, but there’s this voice in your head that keeps asking, “But how do you KNOW?”
That’s where the MVP comes into play—not Steph Curry, but the (perhaps wrongly named) Minimum Viable Product.
The Lean Startup Conundrum
In his book “The Lean Startup”, Eric Reis confusingly re-defines the term “Minimum Viable Product”, which he explains in an interview in 2015. In short:
“Some caveats right off the bat. MVP, despite the name, is not about creating minimal products. […] Second, the definition’s use of the words maximum and minimum means it is decidedly not formulaic.”
So, if the world of Product Ownership and the Agile community has redefined Minimum Viable Product to be neither about creating the minimum or products, then what is it?
All About the Learning
That nagging voice in the back of your head, wondering if there’s a way out of the Analysis Paralysis trap you’re in, trying to figure out a way to actually know the answers to some of your questions, instead of analyzing yourself into a deeper sense of false security? That’s where the Minimum Viable Product comes into play.
Where a PSI (Potentially Shippable Increment) is about creating the opportunity to potentially ship something of value, and the MMF (Minimum Marketable Feature) is about combining those pieces of value into a collection of features that solve customer problems, the MVP is about doing the minimum amount of work your team can in order to close a validated learning loop.
In the Lean Startup methodology of product discovery, one of the most important habits to get into is the habit of validating hypotheses and creating experiments. In more traditionally risk-averse organizations, the belief that risk must be analyzed out of your product before launch leads to long lead times and, frustratingly, data-based assumptions about customer desires and wants. If we’re really good at statistical analysis, and if we have really good data about a statistically significant portion of our customers, we can do a pretty good job of formulating an educated guess about what our customers want.
But, at the end of the day, that’s still a guess.
When we’re creating MVPs, we’re intentionally building just enough functionality to ask the right questions of our customers – would you buy this product? Do these icons make sense? Does this workflow frustrate you, or does it help you find your next favorite restaurant?
At this point, we’re looking at paper prototypes, website wireframes, UI mock-ups; we’re walking across the street to the mall to show our designs to the closest people we can, just to validate quickly that we’re on the right track.
The magic in creating a good MVP isn’t in the tools or techniques, though; it’s in the discipline, when you want to analyze data from a website heat-map to figure out which color scheme works best, to instead grab some markers and paper, sketch a couple of low-fidelity solutions, and ask someone, “Which of these do you like better?”
Next, we tackle The PSI (Potentially Shippable Increment).
Great article defining the MVP. Question – how does this concept apply to hardware? What if you make airplanes or mainframes, which can never fail? What’s the MVP for something like that?
Regarding airplanes, they’re really complex systems built from modules and sub-systems, so you can apply MVP to a lot of the underlying work that goes into building an “airplane”. Just the engine alone is made up of thousands of parts, modules, and other systems including software and controls. Each release doesn’t need to be to an external customer (i.e the receiver of the engine, mainframe, etc) so your MVP might have more to do with how your piece of the puzzle interacts with someone else’s.