Why minimum viable product?
After giving a speech on the minimum viable product (MVP) at a recent Agile conference, a developer approached me and said, "I wish I had known this a year ago!" He had been contracted by a company to build a complex new system, and to do it all at once. The company gave him a comprehensive list of requirements that clearly explained what the customer wanted and requested a deliverable within six months. He explained to me that by the time he was done building the system as specified in the requirement document, the company had gone bankrupt. He never got paid. "If I had known how to build an MVP, I would have suggested that to my customer, and I would have built only a small piece of the whole system," he said.
Ever since Eric Ries popularized the concept of the MVP, companies, start-up founders, and consultants have all strived to build an MVP first. MVP
is a buzzword these days, yet the reality is that often the true meaning of an MVP is misunderstood. Many consider an MVP a "beta release," or the minimum set of capabilities they can get away with. They trim down the list of features of their product so that they can build it quickly.
But customers are not looking for features; they want to solve their problems, and they care about the overall experience. Even a great product won’t survive long in the market if it provides a terrible experience. What some people forget to consider is that an MVP is not intended for launching a product quickly but rather to learn as much as possible from customers. The goal of an MVP is to identify the minimum set of capabilities needed to validate a core set of hypotheses about your business, and test for market-solution fit. If the hypotheses don’t hold true, you basically have no business — you need to pivot. The sooner you validate your business idea, the sooner you learn whether your business is viable or you need to change direction.
Using Product Journey Maps
Product Journey Maps are a great tool to identify the list of capabilities customers care about, prioritize them over multiple releases, and clearly visualize what the MVP should look like. It’s a tool that can be used by product managers, start-up founders, and anyone interested in planning a new product or service.
To build a Product Journey Map, follow these steps:
- Start with a Mind Map. This helps you (and everyone on your team) download the initial ideas, assumptions, and beliefs on a piece of paper.
- Understand your customers by creating user personas. These are usually the result of ethnographic research, empathy interviews, and observations with your (existing or potential) customers. You may learn about their inner needs, aspirations, and beliefs. Use this information to design a better solution for them.
- Draw a Customer Journey Map. There is no right or wrong way to do this, and the format depends on the particular project and the activities your customers undertake. You need to map out all the steps of a customer’s journey with your solution, identify the key activities and touch points, and jot down the customer’s emotional status while they go through the steps.
- You and your team can brainstorm a list of features you’d like to build for each of the steps. Go for quantity at this point, and defer judgment until a later stage.
- Define what your MVP will look like. What’s the goal of your MVP? What are the key hypotheses you need to validate for market-solution fit? What key elements on the technology, business, and human side should you include in your MVP to deliver a full customer experience that validates your hypotheses? You may choose to have more than one MVP, if you need to validate a large or incompatible set of hypotheses. Search on Google for "MVP development form," or download a sample from 5D Vision.
- Prioritize your work so that only the features that are really necessary to deliver the core experience of your MVP are at the top of your list. All others should move down to a later stage.
- Draw a physical line using blue tape on the wall to separate the MVP features from everything else. Making this line visible means it’s harder to change the feature list — for you or your stakeholders. It’s just a mental barrier but it forces everyone to consider the consequences of changing the priorities.
- You may draw an additional line to identify Version 1.1 and so on. However, in an Agile world, planning more than one or two releases ahead may not prove a good use of your time, as things may change before you get there.
I have found Product Journey Maps a useful tool to provide visibility to everyone — including the CEO and executives — about the road map and what to expect from the MVP. They are also a useful tool to maintain focus on the MVP and avoid adding features as you go, or risking scope creep.