5 steps to building Minimum Viable Product with Story Mapping.

In the previous post we have described different concepts of Minimum Viable Products. Among various definitions, we can describe MVP as a product built from the smallest set of features that delivers customer value. But what does “the smallest set of features” mean, and how can we define this? In todays post we would like to share with you a technique which we have learned and which helps us to define and manage the scope of MVP.

60 percent of the features we build is waste

In the movie “Chef” Carl Castor (portrayed by Jon Favreau) complains that whenever he decides to cook something extraordinary, people don’t buy his dish, but at the same time, when he prepares something popular he is bashed by critics.

Sadly, the same principle applies to product development when you need to select a limited number of features for your product. We cannot give customers everything. As entrepreneurs we try to please customers as best we can, but very often we fail. The research shows that more than 60% of features in software products are rarely or never used. 

In our work, to overcome this issue we use a technique which helps us to visualize our Minimum Viable Product and define a minimal but valuable set of features. The method which we describe below is heavily inspired by Story Mapping - a planning technique described by Jeff Patton which is one of the brightest agile practitioners in the software development world.

Your feature list is a map

The main idea of Story Mapping is to replace the traditional one dimensional list of features ordered according to business value with a two dimensional map which focuses on user activities and the overall vision of the product. The next few paragraphs describe how we use Story Mapping to easily define the scope of our own MVPs.

Step 1: Capture the primary goal of your product

Imagine that you are developing a product which helps people to assemble their own customised shoes. Your product allows users to choose colors, fabrics, decorations and shapes of different parts of shoes. As a result, each customer gets a customised product which suits his individual preferences.

In the first step, we need to understand what our product does, or more importantly what kind of problems it solves. Here we need to define the main goal, which must be fulfilled to satisfy the customer. A good primary goal would be: “Allowing users to receive an individual, customised pair of shoes”.

Step 2: Define the main process in the product

In the next step we define what the main user flow in our product looks like. Then, we need to define what the particular stages of this flow are. Actually, very often it is quite easy - we imagine that we need to explain to someone what steps are needed to accomplish the goal which we have defined above.

The rule here is: to think less about particular features and to think more about tasks such as: “Customise a shoe”, “Buy a shoe”, “Manage my orders”, “Get shoes delivered to my home”. All these tasks, when combined, define a process in which the majority of users will (probably!) use our product. They will (probably!) want to customize the shoe, then order one, be able to see their order and later on have the shoes delivered to their home.

Then, we place the names of the process stages on the map as presented below.

Step 3: Create a list of features for each stage

Now, we look at each stage of the process and we define the list of features which should be part of this stage. In this step we try to boost our own creativity and define as many features as we can but at the same time avoid prioritization. What we need now is an unprioritized bucket of ideas which can be developed to help the customer solve her/his problem.

The list of features may look much like this:

Step: Customize a shoe 
Features: choose a color, choose basic shape, choose a heel type, choose a fabric, generate a 3D preview of the customized shoe, save your customized shoe for later, share your shoe project with a friend…

Step: Buy a shoe
Features: pay with Credit Card, pay with PayPal, pay with Google Wallet, use coupon code, make use of seasonal sales… and so on.

As a result, we place features on the map, just below the stage names.

4. Prioritize the features inside lists

Then, we prioritize each feature in each stage according to a few factors:

• Question 1: How important is this feature for finishing the process?
• Question 2: How often will the feature be used?
• Question 3: How many users will use this feature?
• Question 4: How much value will the feature bring to the customer?
• Question 5: How risky is this feature?

Based on these questions we rearrange the features on our map by moving the ones with the high value/priority to the top, and the ones with lower value/priority to the bottom.

5. Define the MVP

Now, we have our features prioritized. The first row on the map defines something which Alistair Cockburn refers to as the Walking Skeleton, which, in this case, is the smallest possible representation of a working product. This is the thing we should build first.

Sometimes the Walking Skeleton is precisely an MVP, but very often this is not the case. In some cases, our minimal product is slightly more sophisticated than our skeletal product, so we want to somehow seperate the features which are a “must-have” to our users and the features that are more a “nice-to-have” or even a “won’t have”.

Then, we draw a horizontal line on the map which divides it into two parts. Features which are essential are placed above the line and other features are placed below the line. The top-placed features represent our Minimum Viable Product and the rest is a long-term vision of our product - something we can use as a foundation to make the product better later.

Build, measure, learn

That is how we define the scope of our MVP. The map shows us the big picture of our product and allows us to modify our mindset. We are focused now on the overall vision and purpose behind the product and not solely on particular features we need to deliver. Then it is easier for us to answer the question: “why are we building it?“, which is probably the most important question one can ask while creating products.

Story Mapping also helps us to plan our work more consciously. When we do it, we always try to go right on the map and not down, and address the most basic needs of our users first. This is how we are able to build the basic MVP quicker, deliver it to our customers and learn more from them. As we wrote before: being able to learn quicker enables us to build better products.

You can learn more about Story Mapping here:

• The new user story backlog is a map
• How you slice it
• User Story Mapping