User story mapping is a visual exercise designed to help product teams better plan, prioritize, and categorize tasks. Crucially, story mapping helps a team see its backlog in a more customer-centric light or from the end-user’s point of view.
Before we dive in, it’s worthwhile defining a user story as well.
User stories are brief, distilled descriptions of a feature or product functionality, usually written from a user’s point of view: As a [description of user], I want [functionality] so that [benefit to user].
For example, one user story for the music streaming app might be: "As a dance teacher, I want to make a playlist of high BPM music so that I can keep the energy high in my dance classes".
So where does this user story sit in the overall user journey of the music streaming app? Likely, quite early on in the process, but the user would still be required to set-up an account, add card details to subscribe, search for songs, etc. before they can create a playlist as in the user story above.
Similarly, underneath this "create a playlist of high BPM" story, you will need to list the features and functions that are required to make that action possible. For one, you need a search feature — but how will this dance teacher come across songs with high BPM?
When story mapping, you need to take a step back and put yourself in the user’s shoes. It’s not quite as simple as "search for high BPM". Sure, that’s one way to do it but that task is likely to be long and arduous and not all that great for the user experience.
So instead, you list all the possible ways that action could be made possible. One is by typing in "high BPM music" into a search field, another could be going through artists/albums the user already knows and likes, another could be by browsing already made playlists to find collections of high BPM songs, and so on.
These various features and functions can then be listed — in order of necessity — from top to bottom underneath the user story. For example, building a search feature into the app is absolutely essential for this user’s action to be performed, so it should sit at the top of the vertical axis.
By listing these different means of achieving the same end goal, a story map quickly helps you identify your minimum viable product — i.e. the top of the vertical list — and subsequent releases and feature updates.
In this way, story mapping is a very powerful tool for strategic prioritization, and the detail explored within a story map should be exported directly into a product roadmap.
60+ pages full of information about roadmapping and especially product roadmap: what is it, how to create a product roadmap, types of roadmaps, prioritization and tips on how to communicate with stakeholders effectively using roadmaps.
In order to develop a meaningful story map, you need to really understand the experience of using your product from a user’s point of view.
Often, especially when you are very close to the product, it can be a challenge to take off your product manager or ‘developer’ hat and see through a user’s eyes.
Thing is, failing to be empathetic and understanding of the genuine user experience may result in your story mapping exercise being a waste of energy.
Inaccurate story mapping doesn’t help prioritization, and can actually lead to biases being reinforced. This could come in the shape of a non-valuable feature that the product team loves because it’s sleek and sexy. Or a misunderstanding of how tech-literate the end-user really is — if the product team understands how to use this feature, why wouldn’t they?
That’s why it can be helpful to involve an element of user research or feedback in the story mapping process, to validate that your map mirrors the actual user experience.
At the least, try to bring someone from a different department into sense-check your story map — are there any gaps in what you’ve laid out? Would they understand how to progress from one action to the next? Where has your product team bias slipped in slightly?
Getting user feedback on your story map is particularly important if you are mapping out an entirely new product for development.
Another key challenge in story mapping is time.
Story mapping isn’t a quick exercise. And it requires plenty of physical space, too.
You may need to work hard to convince stakeholders that this activity is worth the time and resources.
Where possible, try to create your story map in a place where it lives on display for the organization to see. This way, not only will the team be synergized and have a clear view of what they need to build for each release and why, but it helps encourage the understanding that a story map is a living, breathing piece of documentation.
Story maps are works in progress. They are never "done". As builds are completed, new features will get prioritized, and — as always — user feedback and changes in the marketplace will glean new insight into where your map is taking you.
We can thank Jeff Patton for the concept of story mapping.
For Patton, the story mapping exercise was invaluable in ensuring a product actually meets the needs of the end-user — both by prioritizing the most important features, but also by bringing the team together in one shared vision.
Story mapping was first introduced as a concept in 2005 but wasn’t named until 2008. Since then, organizations the world over have used story mapping to deliver high-quality products to market.
The process of story mapping requires teams to sketch out a representative user's interactions with the product in chronological order: what do users need to be able to do for your product to solve their problem? Individual ‘user stories’ are then listed under each particular task/itme or job to be done, before being prioritized based on importance for the end-user.
Story mapping is an excellent alternative to backlog roadmaps or backlog lists, especially if the team has been struggling to prioritize using these frameworks in the past.
The primary advantage of story mapping would be that it assists teams in planning, prioritizing, and grouping their work into iterations, allowing teams to take on the highest value tasks first. This results in faster delivery, faster feedback, and better insights into the product features that benefit users most.
In essence, the benefits of story mapping are:
Story mapping produces a detailed user journey visualization.
Story mapping gives a user-centric bird's-eye view of the features and releases of products.
Story mapping encourages smaller, shorter release cycles.
Story mapping leads to lean thinking and agile development.
Story mapping aids product discovery.
Story mapping supports the prioritization of development work.
Story mapping helps a team to put the users’ needs first to release a truly user-centric and successful end product to market.
Story maps can be used either at the start of the product development process or as a ‘stop and think’ exercise to ensure that the features that have been planned in a roadmap are really user-centric or not.
When all the pressures and needs of other stakeholders become apparent, product teams can find themselves struggling to keep everyone happy. But, at the end of the day, the most important thing is to build a product that users need and love — and story mapping helps achieve that.
A story map can be created to outline the experience for a new product following early discovery work, for an existing product following usability testing, or when launching an MVP. Either way, once built, teams will keep and refer to their story map over time, adding to it, modifying it to reflect the current state of the product, and using it to determine what to work on and release in upcoming sprints.
By now, it should be clear how beneficial story mapping can be when it comes to prioritization. In case you need any further assurance, we’ve outlined some of the ways that story mapping can be used to prioritize roadmap initiatives below:
Defining outcomes - With a holistic, bird’s eye view of what tasks users need to be able to do and when, you can define roadmap outcomes and set strategic milestones. What, in essence, should this release do to improve the user experience and what can be left until later?
Resource and budget planning - Once you have your outcomes clear, it should be easier to plan your resources too. Who from the team is needed to get involved and for how long?
A crystal clear approach to iterative development - Story mapping encourages teams to categorize features and builds in a way that suits the end-users’ needs. This insight makes designing sprints or iterations so much easier, as your roadmap can be structured around delivering the most valuable features first.
A comprehensive look into all the core topics of the product manager role: what they do, what their characteristics are, how their day looks like, how to prepare for an interview in product management and so, so much more.