A new products idea can come from different directions. It comes from observing people doing things wrongly, from dealing with a tough problem, from brainstorming solutions, from thinking outside the box, from failure, from applying different ideation methods, and so on. Some new product ideas, regardless of where they come from, make it to the next stage, validation. At this stage, the objective is to find out whether the product idea has enough customer value, business value, and feasibility to become a real product. Product validation often requires getting hands dirty with prototyping and mock ups. Indeed, product ideas at this stage are so generic that stakeholders can describe them in a few sentences or slides. However, once the product idea is validated, it is time to go to the next level planning. This is when stakeholders invest budgets and allocate product management teams. This is also when user story mapping helps with defining a product strategy. This post describes what user story mapping is, with an example from healthcare.
Three challenges with defining a product strategy
Usually stakeholders have a clear idea about what the product will do and by when. But, if you ask them, each will give a different story. The more complex a product is, the more variations of product features there can be. On the other hand, having a clear product vision from the start is key to plan development. Although product specifications can easily change once customers give their feedback, communication and planning are key. Business partners, engineers, designers, customer representatives and other stakeholders will want to get a picture of what the product will do and at what time.
At this initial stage, the product team may face three questions.
- Customer Focus. What features should we build so that the product can support and engage customers with their jobs and needs?
- Priorities. What features should be developed before anything else, so that resources get used in the most efficient way?
- Communication: How to communicate product features effectively within the team and with stakeholders?
These questions are typical of products that are at embryonal stage. The team is motivated, the product vision is there and early customer feedback is gathered. However, the team does not know what to develop. I like to call this as “the initiation problem”. We all know that product specifications, especially in agile, are set in stone yet. However a product strategy is crucial to have a focused team.
Story mapping to solve the strategy problem
Product managers usually try to overcome this problem in three ways. They should revisit the product vision, create a roadmap and finally write a product requirement document (PRD). Revisiting the product vision and creating a roadmap may take reasonable amount of effort. However, writing a PRD takes more time just to get to a first draft, and its content may be full of uncertainty.
PRDs are lengthy documents specifying all the product requirements, the relations and their link to the product itself. By their definition, they require certain level of detail. The assumption is that business partners, engineers, designers and everyone in the product team will read PRDs. PRDs do support formal review and acceptance processes. In some cases, due to their high level of detail, stakeholders require them in order to bestow product development budget. However, to follow agile principles, product teams may need a better way to deal with creativity and collaboration.
User story mapping can provide with the solution. It is a technique that Jeff Patton, an experience product designer and developer, popularized with his milestone book “User Story Mapping”. Story mapping is often used as a lean UX mapping method. But product managers often use it as an alternative to product roadmaps and, together with user stories, to PRDs as well. With story mapping, product managers can communicate product complexity and priorities early and in a format that facilitates not only solo thinking but also conversations and brainstorming within product teams.
User story mapping example
The best way to understand user story mapping is with an example.
Story mapping can be used for digital products, including technology-heavy products using Internet of Things, Virtual Reality, Digital Twins, Robotics and Machine Learning. However, for the sake of our example, let’s stick to a cloud product, which does not involve too much tech jargon.
The example product is a doctor appointment app, since this kind of consumer apps are getting more traction. The click-and-collect model and on-demand delivery are examples of this trend that simplifies customer experience and reduces cost of service. Many of these products, including doctor appointment apps, use the “multi-sided platform” business model, where multiple economic parties benefit from each other’s presence on the platform. In the example, the parties are two: patients and doctors. Of course there are many doctor appointment apps. The app described in this post is fictional. It may look similar to many other apps, but it is just an example.
Before getting into the details of defining the story map, let’s make the assumption that we have identified our customer segments, validated the product’s core value proposition and defined the product vision. Now it is time to write down what the product should do. So, this is the time to get into story mapping.
Main users, the journeys
The first step in our user story mapping example is to identify main product users. A main user is a general type of user that experiences a specific type of journey with the product. Usually there are 1 or 2 main users for a product. For the doctor appointment app, we can think of 2 main users: patients and doctors. Of course, there might be different segments of patients and doctors with different specializations. However, in terms of product use, all patients will likely go through the same “consumer-like” journey and all doctors will go through a “business-like” journey. The number of main user will define the number of story maps for the product. In other words, having one story map for each main user is a good.
User activities, the backbone
After identifying main users, the next step is to build the backbone of the story map. In other words, we want to identify the activities that main users will perform by using the product. This means that we are not thinking in product terms yet, but rather in terms of customer needs. We are still at a high level, so we privilege breadth over depth. The question to ask is:
What jobs the user wants to get done with our product, and in what sequence?
In our doctor appointment app, for example, we would have two backbones, one for each main user. For the sake of the example, let us focus on the patient user. The activities composing the backbone are: “Register“, “Find Doctor”, “Schedule Appointment”, “Review Consultation”, “Share Experience”.
These are the sequential activities that the patient would perform to get value out of the product. You may notice that “Share the Experience” is an activity that does not really reflect the need of the users, but rather the needs of business stakeholders. Indeed, sharing their experience with the doctor is an activity that not everyone would like to do. Nevertheless, we include this activity for two reasons. First, research shows that sharing experience creates personal gratification, so some users may want to share their experience with others. Second, having users sharing their experience can help acquiring new users through network effects.
User tasks, the epics
Sorting out user activities and aligning everyone on the product team on them is a great step forward in building the story map. The next step consists of identifying tasks that the user would execute in order to perform each of the activities.
There is no strict rule to define tasks. What matters is to maintain the perspective of the user. In other words, the question to ask is:
What sequence of tasks does the user execute to complete this job?
User tasks, in the world of agile delivery, are synonyms for epics. An epic is a big chunk of work that share a common user objective.
In the doctor appointment app example, let’s look at the “Find Doctor” activity. To search for a doctor, the patient may perform three tasks, possibly in sequence: “Login”, “Search Doctor”, “Check Doctor’s Profile”. In order to “Schedule Appointment”, the user would perform two main tasks: “Review Availability”, “Plan Appointment”. So, if we consider only these two activities, we would have five epics, as shown in the picture below.
The picture does not show tasks for the other three activities, but it is straightforward to come up with them by answering the question above. Of course, anyone can come up with a different set of tasks, as there is no single way to satisfy customer needs. Creativity, customer knowledge and a good sense of what is feasible and what is not (a task like “Search Doctor on Mars” may provide value to some customers but would be less technically feasible) are the only boundaries here.
Task details, the user stories
With the horizontal span of the map completed, the next step in the user story mapping example is to go through the vertical direction. It is time to look at the details of how users will actually experience the product. Practically, this comes down to defining the details that compose each task. The question to answer is:
How does the user use our product to complete each task?
Differently from activities and tasks, where we think in terms of customer needs, task details are all about product functionalities, UI and UX. This is where the translation of customer needs to actual product specification really happens. In fact, in the agile world details are synonyms for user stories. A user story is the specification of a product functionality described from the perspective of the user.
For the doctor appointment app example, let us take the five tasks previously identified and split them into functionalities that can help patients complete their activities. For the “Check Doctor Profile”, we can come up with the following user stories: “Open the doctor details page”, “Review the doctor public profile“, “Scroll through list of services”, “Expand ratings section”, “Scroll through comments from other patients”. Clearly, stories are more concrete actions than epics. They correspond to actual functionalities on the doctor profile page.
First release, or MVP
By the team you reach this point, your map has become quite big. In fact, you may need an entire wall or floor rather than just a piece of paper. If size is a problem, digital tools may come to rescue. Even more, while the team proceeds with product development and new customers feedback becomes available, the map grows with new ideas and discoveries.
Sooner than later, the product manager will need to prioritize user stories according to value for the customer and the business. Practically, this consists of shuffling user stories so that the high priority ones are on top. Moreover, prioritization requires to look at the full customer journey, the horizontal direction, so that value spans the full customer experience. This is why prioritizing on a story map is better than doing on a backlog. Indeed, a story map allows to prioritize not only vertically (across user stories), but also horizontally (across epics).
Once prioritization is done, the whole product team needs to literally “draw a line” between functionalities that will be delivered in the first release and functionalities that will go to future releases. The first release of a product, sometimes called Minimum Viable Product (MVP), should focus on the core features of the app, so that the product team can go to market relatively quickly and get early feedback from users on those stories that matter most for them. Story mapping can be applied to scoping minimum viable features (MVF), the equivalent of MVPs for single product features.
Here is how the MVP looks like on the story map of our example.
Following releases
The product manager should update the story map continuously. While the product evolves with more functionalities, the team can add more stories and releases on the vertical axis. Sometimes, when new needs are discovered, even new epics can populate the horizontal axis while some other get removed.
It is a good idea to start defining next releases. In this way the story map can act as a sort of product roadmap (just rotated by ninety degrees). The further in the future releases are, the less less user stories there are on the map.
Versioning to manage product change
Although most of the value of using a story map comes from using it during product planning. Using it as a tool to manage product change can be very effective
The reason for it is that a story map gives a visual snapshot of where is the product at different times of product delivery. Each story can have a different development status, indicated on the map with a color, so that the team, just by glancing at the map, knows where development stands. Moreover, comparing two map snapshots from two different times can be a powerful way to visualize change without much verbosity.
So, the best way to keep track of product changes is by versioning story maps, so that it is easy to refer to previous versions of the story map when needed.
The benefits of User Story Mapping
Hopefully the example has shed some light on the merits of user story mapping. Let’s go back to our initial strategy problem and see how story mapping helps with it.
Customer Focus
Story mapping helps separating what is product from what is customer needs. In requirement analysis, tracing back product specification to business and functional requirements is critical to keep the product focused on the requirements. In the same way, by offering both the customer point of view (with activities and epics) and the product view (with user stories), a story map maintains the relationship between customer needs and product specifications. You may argue that this relationship is broad and generic. In fact, a story map is not a one-to-one substitute for a requirement traceability matrix, which is essential in some specific cases. Nevertheless, a story map is a good trade-off to offer great visual way to achieve similar benefits at a fraction of the cost. Spotting if a product is missing a customer need is visually possible by spotting areas of the customer journey that are poorly covered.
Prioritization
Product teams require some direction on what needs to be done by when. Often, especially in the agile world, the answer is to maintain a prioritized backlog of use stories. However, a backlog is a list, and seeing the big picture of how these stories convey customer value may be difficult. Story mapping, on the other hand, is like having multiple backlogs, one for each epic. By recognizing epics and their sequence, seeing the big picture is much easier. As a result, prioritization also becomes easier.
Communication
Due to the visual power of a story map, communicating and discussing product updates within the team is quicker. In fact, rather than spending time contextualizing a discussion, the team can immediately refer to the exact stage of the customer journey within the current product release. With respect to stakeholders, showing progress and upcoming expected releases is more practical than by using a roadmap, because it is possible to move from high-level activities to detailed tasks, and even stories. Finally, a story map offers a simple visual representation to distinguish those product features that are already developed from those that are still in progress or that are coming in future releases.
Alternatives to Story Mapping
Despite of its benefits, user story mapping is not always the preferred solution for planning and communicating new product development initiatives.
For very simple product features or incremental product development a story map might not be needed. A prioritized list of stories may be enough for the development team to proceed and for stakeholders to understand the product.
On the other end, for mission-critical products within highly regulated industries, such as medical equipment, aviation, public transportation, telecommunications and so on, a story map cannot substitute more detailed and accurate artifacts. Depending on how the product stands within some of these industries, formal requirement specification documents and requirement traceability matrices can be mandatory. In these cases, maintaining a story map and keeping it in sync with requirement specification documents may generate too much overhead that would probably outweigh the benefits.
Another consideration to make regards product maturity. Story mapping is a technique used in product discovery in order to rapidly find product-market fit for products that are at relatively early stages. Products that have already passed the product discovery phase and are scaling up may not need story mapping.
Conclusion
Although story mapping is not applicable to any product at any product development stage. But for digital products in product discovery phase, the example shows how user story mapping can go a long way in helping product teams communicate faster, (re)prioritize better and stay flexible with respect to customer needs.
Finally, there are different ways to create and share story maps. The best way to create a story map is probably the “low-tech” one. Using a large wall with sticky notes is an approach that many teams use. Nevertheless, for portability and maintainability, digital tools come to rescue.
If you are interested to know more about the tools or would like to know more about the user story mapping example, please comment below, so that I can write a future post on it. For any other query, please get in touch.