3 uses for story maps to build a better product

17 Feb 2017 / Alex Bolboaca / No Comments

One of the first techniques I learned as a beginner Product Owner was user story mapping. I immediately found it was easy to understand and apply. What took a while longer was appreciating its true power – identifying all the situations where it can be applied.

In the eventriX team, we use it to keep the product roadmap, plan development iterations, detail potential features, and even plan meetings. Read on for 3 detailed examples – how story maps help us get the job done better & more efficient.

Quick intro to story mapping

A story map is a way of visually telling a story, to support conversations. The main purpose is to build shared understanding for the members of the team.

When building a story map, a best-practice is to involve all the relevant people in the team. In the case of a product team, gather people like product owner, tester, technical lead, architect, UX/UI designer etc. Because of their various backgrounds and interests, they all bring in useful perspectives. Plus, in the end, everyone has a clear & common understanding of what they start working on.

Tip: As a PO, I sometimes quickly create a story map for a problem / feature I’m dueling with. I randomly leave it around the office. It always ends up attracting attention from someone else in the team. In this way, I have useful conversations, getting valuable input and, bonus, not distracting anyone from their immediate work.

How to build a story map

Let’s take a simple real-life example and follow the steps together: build the story map of prepping & getting to work in the morning.

The Storymap of Andrew's Morning — The Storymap of Andrew’s Morning

Start with the goal. What is the story map about? What are you trying to accomplish? Top-left corner, clear and visible – why?
Make visible who does the actions in the story map. Who is the actor in the scene we are describing? Who is the persona for the product features you are to detail?
On the first row, left to right, insert the main steps of the story map – main activities that need to happen.
Move on and detail each main activity – column by column, left to right.

Optional: in the case of product features, you can move further to a sketching approach – create planned product iterations. What are the main details we need to implement right away and what can be delayed? Select and draw a line between each iteration.

Tip: Build at the level of detail that serves your purpose. For example, the “Make coffee” single activity above, could be detailed into its own story map. Depending on the persona of the story map, it will look very differently – ex. someone making an espresso will have a totally different “Make coffee” story map than someone using a french press.

When exploring product features, you might choose to build story maps for multiple options that solve the underlying problem. Do this confidently – it will allow you to best analyze ups & downs for each option and make the best choice. Thus everyone in the team will contribute and understand the final decision.

Use-case 1: product roadmap

This was the story map for eventriX first product MVP. The main goal is on the big green post-it in the top-left. Continue on that row and you find the legend of the story map.

Because we have two personas interacting with the product, the main activities are noted on different colored post-its:

light green for Organizers
light blue for Speakers.

We then chose to also differentiate between:

user stories (light yellow)

and other types of development needed:

automatic emails to be sent (dark blue)
tasks like implementing a SSL certificate or integrating Google Analytics (dark yellow)
cross-functional requirements (dark green)
feature ideas (pink) – you notice there are no such post-its in the picture. We used this to capture ideas when we had them, but by the time I took the photo they had either turned into user stories, or went into the opportunity backlog for later review.

The horizontal line delimits the first iteration we implemented from stories we chose to postpone for a further iteration. We chose to implement the backbone for the main features and come back later to add details and fine-tunings.

Tip: The above legend is what worked for our team, at the given time. It’s changed even for us as we moved forward and it will most probably be different for the needs of your team. Work with what fits best for your team and don’t be afraid to change.

Use-case 2: feature definition

This was done prior to the above product roadmap. Here, we were starting from the user’s normal workflow – without an app – and figuring out how to translate it into our product experience. We exchanged ideas and iterated on this story map. Further, we moved on to creating screen prototypes for the app and test them. Only after, did the above product roadmap with the actual development plan arise.

You notice the goal on the rotated post-it. The personas on the orange post-its. The main activities on the first row, divided into two bigger activities – top two post-its. Then, each column details each activity.

Once again, we used different other types of post-its to write down stuff to do, ideas to remember.

Use-case 3: user interview flow

At the very beginning of our work on eventriX, I was conducting customer development interviews with conference organizers. I made a plan on how I would conduct the discussion. I found it was very useful to keep this plan in the form of a story map too. It helped me easily remember my questions and avoid reading them from a piece of paper. This lead to a more natural discussion and helped the person I was interviewing feel more relaxed to share their experience.

Using story maps as a simple mean of communication is very useful for our team. The common visual language allows everyone involved (business, UX/product, development) to easily share ideas and keep on the same track. If you haven’t tried it yet, I encourage you to give it a go.