Story Mapping for New Products
A way to visualize your product roadmap and align your team
Over the course of my career, I have had the pleasure of building multiple products from scratch, and learnt strategies that help the process of building a new product and also lead to a highly productive and streamlined experience for all stakeholders involved. Story mapping is one of those.
For me, Story mapping has become by far the most impactful exercise to align the entire team and have a point of reference that can inform not just engineering and product management, but also marketing, operations, user research, design, and business stakeholders; specially when starting out a new product or a clear initiative within a running product.
So what is story mapping?
In a nutshell, Story mapping helps you define the early versions of your product, and can be used to elicit use case requirements, edge cases, and the overall scope of go to market efforts, by consolidating major themes of work and their interconnectedness. You can get a detailed understanding of the process on this seminal post by Jeff Patton.
A Story map, is in essence an actionable version of the User Journey map. You can take the major activities that a user performs as themes for the Story map and fill in the details in the stories below.
In order to build a credible Story map, you would need to identify the big themes, and then add User Stories to each one, giving you a sense of the work to be done. You can then go ahead and plan your work in Kanban, Scrum, or any other execution framework of your choice.
To make it a bit clearer, let’s look a real world use case of building an e-scooter service, and the themes and stories involved.
This example shows a very detailed Story map, with the core use case of “users can ride the scooters”, and secondary use cases such as analytics, and notifications, which are used to provide a better service to the user.
Bonus: The green lines below some stories show the cut off for the MVP i.e. stories below the green lines were considered out of scope for the MVP.
Use the Story map to derive the MVP requirements
The product Story map starts to pay off right off the bat, when you create it. By involving design, engineering, product management, and any other relevant stakeholders, you can easily tease out the main requirements for the product AND gain instant alignment, that will continue to streamline your work throughout the product build phase.
The best way to create such a Story map is to do a workshop with all the parties involved, and move around sticky notes as needed. Fast forward a couple of hours, and you have essentially consolidated the major expectations of the product, and can even go further to break down the stories into items that can go straight into the backlog.
Use the Story map to communicate progress
If your Story map was created on a portable medium e.g. sticky notes on a big piece of cardboard, it makes it incredibly easy to simply bring it to your sprint reviews, so that the Sprint work can be directly put into perspective, and all stakeholders can see the overall progress in a coherent visual. In the above example, you can see the green stickies representing stories that have been completed, yellow for work in progress, and red for stories that are yet to be started.
The tools of the trade
In an ideal world, a big wall, and some coloured sticky notes would be the best tools for creating a Story map. You can use bigger sticky notes to denote themes, and medium size sticky notes to denote the stories. But in case, you’re working with a remote team, or need a digital representation, Figma, Miro, Mural, or plain old Spreadsheets would do the trick.
Bear in mind
While the initial Story map will get you started, it is vitally important to update your Story map when your product requirements change, so that the reference point is always up to date and can be used not just for your core team, but also to communicate to all relevant stakeholders. Make sure to involve all parties in the beginning i.e. design, marketing, business, operations, etc; and also to take in their feedback and update the Story map on a regular cadence.
Once your Story map is created and agreed upon, go ahead and map it into your day to day execution framework e.g. Scrum, Kanban, or any other collaboration tools you use for the purpose.
Have you used Story mapping to define your product and align your team? What was your experience with it? Let me know in the comments below!
