Outcome-Based Story Mapping

Introduction

A project's documentation shouldn't be a super-detailed list of how the software should behave. It needs to work more like the photos from that trip you took last year. They don't tell the whole story but help people remember what happened and have conversations about it.

A product backlog is not about writing or documenting stories. Instead, we need to create a conversation between the teams and the client.

The fallacy of the traditional backlog is that it is a prioritized list of what should be delivered. It's not. A great story well told has multiple characters and timelines, and your product is no different.

When your product is created linearly, many aspects of the business are left out, and the result is a less effective solution.

Most managers forget that we don't have the answers until our users use the system. Until that happens, what we have are only hypotheses.

To invest time and money in something uncertain is necessary to focus on the result we want, with the lowest cost and in the shortest time. The plan is to create the least amount of learning necessary to validate the way forward.

I always hear managers saying that they can't implement everything the business people want. They don't and never will. Creating ideas is very easy. Validate and test if they are reasonable; not so much.

The flow of ideas is always more significant than the flow of implementation. Selecting the right thing to do is what makes all the difference. Choosing small to have the opportunity to make mistakes is what makes success happen.

"The only way to win is to learn faster than anyone else." 

Eric Ries

Reducing lead time is not just about doing it faster. It's about learning more quickly than spending the least on it. When the error is cheap, innovation happens.

Having too many certainties is sure death to innovation.

We are walking in a terrain where we cannot see what is in front of us, only what has passed. The chance of falling into a hole just ahead is very high, so learning is essential for robustness.

Doing the least doesn't mean doing the wrong thing. It means focusing on as little as possible and understanding how to validate and generate learning. And do that until you have something viable to launch. It's no use saying that your lousy product is just an MVP.

Try to think like an artist creates a picture. Imagine that you were commissioned to paint a picture of a person with a landscape in the background. A manager today would probably do something like this:

Surely an artist wouldn't do that. It is almost impossible to imagine a small part without having at least a panorama.

Creating the map

Stories have been the glue that unites us as humans since the invention of language.

They help our brain to understand better given their multimedia factor. Stories have sight, sound, smell, and touch. Many memorization courses teach us to create stories to remember things better. I remember when I was a kid and took a class like that. I used it for my biology test. I still remember this lesson because I created an absurd story in my head, but it made sense. I saw the characters, I listened to and sympathized with them. And so I learned the lesson.

Stories allow people to act as one. Given the historical role of mythology to humanity, why not use it to communicate our product as well?

Story maps have been used to tell stories for centuries. Aristotle already used a story mapping model, and authors like the Breaking Bad creative team used something very similar to make sense of the script.

Making the story a little more complex and exploring more characters and paths helps give much-needed richness to innovation. We can tell the story of our user, our protagonist, and communicate what we want to solve more easily.

Given that reference, Story Mapping is very reminiscent of the way a movie is created. There's the main narrative, the backbone, and for the movie to exist, many things must happen. In addition to being filmed, it has the set, costumes, makeup, lighting, and sound.

Here too, for every app we use, there is experience and UI design, front-end and back-end development, and QA. That's why focusing on narrative and script is so powerful - it manages to unite all the parts needed to make a product into a straightforward narrative.

Stories

The story idea came from Kent Beck's insight into how a user passionately told him about a new system where you put in the zip code, and the system filled in the forms automatically. Something like that was undoubtedly a sensational experience in the 90s.

Stories are just that: people telling you how they use or would use your product. A user story is an anecdote to the requirement because it is a reminder for a conversation to take place.

In 2008 Jeff Patton saw that Kent Beck's stories needed to be better organized. Many people were already doing this, taking the linearity out of the backlogs. Story maps are more of a story creation pattern than a method. Jeff Patton's approach has become a big sensation, and it's terrific. But the author says we must go further, create our maps and constantly evolve.

The main objective is to tell the same story to everyone involved, including providing quality information so everyone can make better decisions.

There is the company's history, vision, mission, and OKRs. How does the user, or customer, fit into this story? The user is the hero in this journey, and that puts us in the position of a guide or advisor -  someone with experience and knowledge capable of helping the hero achieve his goals. If your product is the hero, that makes your customer the helpless person who needs saving, and that's not the kind of character that usually matters. That gives us the connection. How do we put these stories together and maintain coherence?

While thinking about this problem after reading Josh Seiden's excellent “Outputs over Outcomes”, we saw a direct connection with story maps, but this is not explicit in the book.

Josh invites us to think of a middle way between the economic impact we want to achieve with the product and its delivery. Measuring product delivery is a model that does not consider the complexity of digital. The external environment is unstable, and we cannot risk following a plan that does not adapt continuously.

We want business goals, of course. But measuring the business impact of a software feature can be useless. So how to know if a feature, or even a project, really had an impact? In this, they bring a revamp to the notion of Outcomes. Of course, an outcome would be nothing more than an expected result, but Josh brings meaning to digital products that are more measurable. An outcome is the desired change in user behavior that will predict a shift in business impact.

If a business impact is to increase sales, the desired outcome might be to increase the number of quote requests through the website. More quote requests predict an increase in sales to some extent. However, this needs testing.

Changes in behavior are much easier to measure than indicators, such as an increase in sales.

Creating the map

With the outcomes defined, thinking about the change in user behavior, it is now possible to tell a story to make sense of how this will happen.

How are we going to make this user request a quote? What are outputs needed to make the user arrive at this result?

One important thing to remember about a Story map is that it is about a big story. User stories are small stories about something particular the user does in the system. The process of story mapping comes to joining all these small stories into a big story and creating a shared vision.

It all starts with a happy path idea. Here it is worth mentioning that Story Mapping must be dynamic, and remember that it is a hypothesis to achieve one or more outcomes.

This backbone of the system is where everything happens. A simple narrative flow of how users interact with the system is the foundation that unites all teams. It is essential to constantly think about it from the perspective of who will use the system. We will see why this is so important.

For this, it is crucial to think about the tasks this user has to perform to reflect the desired behavior change. What are the steps the user must take to reach the result we expect?

Perhaps this narrative already exists in your company. It could be a User Journey Map, prototype, or even a pitch deck. 

Here at the workshop, we are using Event Storming by Alberto Brandolini to be able to arrive more accurately at this step-by-step from an event perspective.

Depending on the size of your product, this spine can get quite large. So you have to look from afar and start classifying the narrative with what makes sense. I don't have any big tips here other than common sense.

Again, ES can help a lot in this work, but the idea is to look at the narrative and group them by activities that make sense. If our history says that the user

These tasks can be part of a "Make the purchase" activity. The narrative flow of exercises will give a more straightforward and summarized overview of what the system does.

Search the product > Make the purchase > Track the order.

With your backbone and activities defined, it's time to get down to the nitty-gritty.

Now is the time to explore the problem and try to think of creative solutions. For example, what will make the user click on the call to action? What other options might he have to get the same result? What paths can take him off the route we want to take?

Slice the release strategy

With the backbone, we started to get into the details. The backbone is the plot of your story. Here we have to look at what elements we need to explore for the tasks to be carried out.

**Clicked on an AD**

One of the essential parts of Story Mapping is release slicing. It's one of the most critical things on the roadmap, as it's a more visual and holistic way of creating a product roadmap.

Each release, project, or milestone, whatever you want to call it, has to support a user's journey minimally. Limiting a user's journey makes it possible to do less and learn faster. What is the minimum to validate my hypothesis? Will this output make more users request a quote? Will more quote requests translate into more sales?

We do this by creating horizontal lines that separate the journey. What do you think of our initial journey, the outline of our map, so you can see if it makes sense? How would it be with more features? How will it be when finished?

We want to be agile, right? So these releases can and will change over time, but we use planning to align the changes, not blindly follow the plan. So the important thing here is always to think: How do I do less and achieve this journey?

Conclusion

Stories shape us and are the best way to convey information we know. Using all this power to tell the product's story both for those who are building it and for users is a challenge that is gaining more supporters every day.

When thinking about construction or improvement, tell stories, and talk to people. Understanding comes more from chatting and confirming than writing requirements on a card on the board.