“We must learn what customers really want, not what they say or what they think they should want. -Eric Ries, The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Business
The term “Minimum Viable Product or MVP” has been popular in the startup community for some time but what does it mean. There are different understanding depending on who you talk to. It also has different implications based on the context. For instance, Eric Ries in his book, The Lean Startup says, “The big question of our time is not Can it be built? but Should it be built?.”
So how do we know if something should be built or not. Concepts like the MVP from the Lean Startup offer a scientific approach to address this question. According to Eric, “The Minimum Viable Product (MVP) is that version of new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”
Eric popularized the MVP term (with Steve Blank) and views it as a way to quickly validate our learning. I also like the definition of Ash Maurya that states, “A Minimum Viable Product is the smallest thing you can build that delivers customer value (and as a bonus captures some of that value back)”.
The word “minimum” is relative which I believe is by design. What’s minimum in one context might not be in another so how do we determine what it means. Roman Pichler, explains that, “The MVP is called minimum, as you should spend as little time and effort to create it. But this does not mean that it has to be quick and dirty. How long it takes to create an MVP and how feature-rich it should be, depends on your product and market. But try to keep the feature set as small as possible to accelerate learning, and to avoid wasting time and money — your idea may turn out to be wrong!”
Frank Robinson who originally coined the term MVP says that: “MVP is a mindset of the management and development-team. It says, think big for the long term but small for the short term. Think big enough that the first product is a sound launching pad for it and its next generation and the roadmap that follows, but not so small that you leave room for a competitor to get the jump on you.” He also says that, “Too large or too small a product are big problems. The MVP is the difficult-to-determine sweet spot between them. Teams flounder tactically in trying to determine the MVP.”
As you are building your MVP, beware of the Product Death Cycle as David J Bland calls it in the diagram below.
MVP in the context of building a new product makes sense but what about enhancing existing products. How does it apply? Well, the idea of MVP is still relevant as you don’t know what new features or enhancements your customers want and you are trying to run small experiments to test your hypothesis. With that in mind, we need to ask, “How quickly can we validate our learning (really hypothesis) that we are building the right feature set or something that is valuable to the customer and they are willing to pay for it?
One of the most critical aspects is to work with the customer directly if possible. If that’s not feasible, there needs to be a representative of the customer usually from the Product Management Team to help in the discovery process. The steps below (adopted from Jeff Patton) could help your team identify the MVP. Ideally, you would have a team of technology and business or customer representatives.
Step 1: Understand the User Needs
Usually users have a problem they are trying to solve, a need they are trying to fulfill or a job to be done as Clayton Christensen puts it. When building a new product (or new features), sometimes we make assumption about the user problem (or perceived problem) but through structured interviews and discover we can work with the users to validate our assumptions. It is critical to know who we are building the product for (our target audience).
One way I like to use for identifying users is developing personas for our customers. Jeff Patton defines a persona as an example of a specific user to help those making choices about the software evaluate decisions about the features to build. It’s not based on one user, but a synthesis of information about many users with possibly different demographics and goals.
Step 2: Tell the Stories
With the users’ goals in mind, the team starts looking at the features and epics that will help the users reach those goals. EPICs are then broken down into user stories. Mike Cohn defines user stories as short descriptions of a feature told from the user’s perspective. Understanding the user activities can help in finding areas to streamline or enhance the user experience.
Step 3: Build the Story Map
To develop the product, the team need to slice it in increments so using the story map, the team organizes the flow of the stories that will deliver the maximum value to the user. This is a collaborative effort among the team and it helps in identifying any gaps before the initial release. Think of a story map as a multidimensional product backlog where you have a holistic view of the product.
Step 4: Create an Incremental Release Roadmap
Now that the team has the story map, they will start setting a roadmap for what they will deliver over time. They might choose the first release as their MVP.
The key to creating an MVP really happens in the collaboration among the team but remember the real goal is to learn whether the product should be built.
