Using Product Journey Maps to plan your product MVP

A few months ago I was giving a speech on MVPs at an Agile conference and a developer approached me saying: “I wish I had known this a year ago!”

He later explained that about a year before he had been contracted by a company to build a new complex system, and 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 sighed, then added that 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 added.

Ever since Eric Ries popularized the concept of the MVP (Minimum Viable Product), companies, startup founders, and consultants all strive to build an MVP first. The MVP is a hot buzz word these days, yet the reality is that often the real meaning of an MVP is misunderstood. Many consider an MVP as 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. There are certainly advantages at trimming down the first release and get to market quickly, but the features in an MVP should be chosen carefully based on a set of hypotheses that the team needs to validate.

It’s always said that customers are not looking for features, but they want to solve their problems and they care about the overall experience. Even a great product that provides a terrible experience won’t survive long in the market. What these 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 their 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 these 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 if your business is viable or if you need to change direction.

A Product Journey Map for a large system with 3 types of users, 7 journeys, and 18 stages

Product Journey Maps are a great tool to identify the list of capabilities customers care about, prioritize them in multiple releases, and clearly visualize what the MVP should look like. It’s a tool that can be used by product managers, startup founders, and anyone interested in planning a new product or service. To build a Product Journey Map you follow these steps:

1 – Start with a Mind Map. This helps you (and everyone on your team) to download the initial ideas, assumptions, and beliefs on a piece of paper.

2 – Understand your customers by creating User Personas. This is 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. And use this information to design a better solution for them.

3 – Draw a Customer Journey Map. There is no right or wrong way to do this, and the format depends on the particular project and activities your customers do. You need to map out all the steps of a customer’s journey with your solution, identify the key activities and touchpoints, and jot down the customer’s emotional status while they go through the steps.

4 – Once you have all the steps identified, 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 at a later stage.

5 – It is time to define how 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. Google “MVP development form.”

6 – Once you have a better understanding of what your MVP should look like, you need to prioritize your work so that only the features that are really necessary to deliver the core experience of your MVP should be at the top of your list. All others should move down to a later stage.

7 – Draw a physical line using a blue tape on the wall to separate the MVP features from everything else. Having this line visible makes it harder to change the feature list – for you or your stakeholders. It’s just a mental barrier and forces everyone to consider the consequences of changing the priorities.

8 – You may draw an additional line to identify Version 1.1, and so on. However, in an Agile world, planning more than 1 or 2 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 roadmap 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 risk scope creep.

You can learn more on Product Journey Maps by following us on Twitter, or by attending one of the seminars we run at conferences around the world and for private customers. Contact us if you’d like to schedule one for your team.

Written by: Valerio Zanini

Product Journey Mapping workshop