Foster product, design, and engineering collaboration with User Story Mapping

If you are a product-maker, one of your most important allies when sitting down at the collaborative discovery table should be User Story Mapping.  

It helps teams to visualize the whole user journey as meaningful increments and have really good discussions, with the aim of building a mutual understanding of the challenges they face along the way.

To paraphrase product management guru Marty Cagan, you need to bring together engineering, design and product to breathe life into a product. You need these different perspectives and expertise to make the right product decisions. 

Sounds good, right? Sadly, it does not always play out so smoothly. 

In fact, throughout my career as a product manager, I’ve seen that things can get very messy, when engineering, design, and product come together. However, each is paramount when it comes to making the right product decisions. 

So how can you streamline this collaboration and launch great products together?

There’s no silver bullet solution, but if I had to choose a single tool in the innovation arsenal, I’d opt for User Story Mapping, which has been a true game-changer for me. It has helped my teams foster collaboration, avoid misunderstandings and ultimately get the right products to market faster. 

For those on the fence about User Story Mapping, let me share how this valuable technique works here at Productboard. 

When story mapping comes to play

My cross-functional team relies on User Story Mapping to ease the transition between the discovery and delivery stages of complex initiatives. It is by no means the only time when we come together, but I find it the most intense and rewarding part of the product life cycle. 

We only use it after we are done with the problem discovery, an early prototype and an informal feasibility review. We don’t do any architecture reviews at this point, but the engineer has seen the early prototype and read the product discovery document, so that they can think about the architecture of the system prior to doing story mapping. 

In terms of timing, we usually do this between two and four weeks before coding starts, because it’s a relatively involved exercise. However, you should not always use story mapping, because it may be overkill for some of the smaller initiatives that your team may be working on.

How does my team story map?

At the center lies a user story mapping workshop. However, you cannot do successful story mapping unless you prepare and follow up on it.

Preparation

In the preparation phase, we figure out who is going to be our facilitator. Usually, I run things from the product manager seat, but a designer can also easily fill this role. As the facilitator, I then decide on who the participants are. I prefer to run this exercise with four people, but maximum six to keep the discussion engaging for all involved.

Once the group is set up, I send an invite at least a week ahead of the workshop. At the same time, I share the underlying discovery inputs, which include the product discovery brief (see our template in the image below), the low-fidelity prototype from the designer, and any engineering feasibility notes.

I also like to prepare the activities backbone prior to the workshop, because it makes it easier to moderate a discussion and to give everyone the same framing. I usually put this together myself, while some people like to collaborate between product and design to really align on this first. Either way, you can always tweak the backbone in the workshop itself. This is an example of what the draft backbone could look like:

The workshop

Oooh, we’re finally getting together! But before we jump into fun discussions, I always like to spend the first part of the workshop explaining the user story mapping process and goals of the exercise and recapitulating key discovery inputs (i.e. the product brief, prototype and any feasibility highlights). This shouldn’t take you more than 30 minutes, even if you’re doing it for the first time. 

Now we’re ready to dive right into story mapping. As the facilitator, I introduce the backbone, and then each participant lists individual tasks on stickies within each activity in the backbone. In my experience, 20 minutes is enough here. 

Once everyone is ready, we go over each of the tasks for all of the different activities together, deduplicating them as we go along. Here we expand on what the desired user experiences should be. Often, we already start moving them up and down in terms of what is more or less important. 

Sometimes, if it’s a medium-size initiative, we are able to break the tasks down into releases during the workshop. But more often, we actually go away after the initial discussion and reconvene later. 

Before our next discussion I clean things up and propose how to break down the tasks into increments we can release. In case your facilitator is not the product manager, make sure to involve the product manager, as scope and priority should be up to them.

As the facilitator, I also make sure to moderate the discussion so that any rabbit holes are identified and assigned as follow-ups if we are not able to resolve them synchronously in a timely manner. We don’t get all the answers the first time around, and that’s completely fine. We’re not finalizing what a user story map looks like. Instead, we’re figuring out who needs to do what next.

And then what?

After the workshop, we leverage our story map as the foundation for subsequent delivery and further discovery. 

It is up to the product manager to document the scope and release strategy. Effectively, this means taking our stickies and bringing them to Productboard. I use components for activities and features and sub-features for tasks, which I then assign to individual releases.

My assignment is still subject to change and requires a close collaboration with engineers, who are responsible for delivery. Engineers split more detailed acceptance criteria into deliverable stories, figure out what the dependencies are, and can provide initial high-level estimates. Based on these estimates, we may move things about some more. 

With all this ready, we plan out our sprints and estimate dates of each release. And yes, the plan always changes, but at least we have something to start with and manage expectations against. 

On the discovery track, the designer would take some more time to visualize any missing flows that need more fidelity, working based on the delivery sequence provided by product and engineering (see the design task column in the image below). The designer also collaborates with the product manager to figure out answers to open questions as to how things should behave and why.

Why my team likes story mapping

Story mapping forces us to come together as engineers, designers and product managers to really understand the customer’s needs, how they want to interact with something. It also allows us to get a bigger picture of the functionality.

There is much less misunderstanding about our goals or how we are going to deliver the product. This allows us to move much faster, because we are able to agree on how something is going to happen quicker and blend out our increments much further out into the future. It really helps with our team’s predictability and can pinpoint when something is slipping. We can also better manage the expectations of key stakeholders.  

Although we don’t have every single detail of how things are going to behave, we have a very high-level map that we’re all aligned on, we have a list of open questions.  

 

What does Use Story Mapping look like at your company? Have you seen it make a difference in your team collaboration? Feel free to connect with me and let me know via LinkedIn.