Comment (1)

In our series around product management, the first blog about creating product backlogs addresses our persona discussion, where we established the handful of people we wish to impact along product development with their associated goals for use of the product. Now, we can take those people and goals and visualize the experience we wish for them to have. There are many ways to do this, but more times than not, we fall back to story mapping, which is another great practice from our friends in the UX community.

Visualizing the Product Story

In the image below, you see that we have started by selecting a persona and a goal for our product development. From there, we ask, "What are the high-level activities that person will need to complete to accomplish the goal?" Once we have sketched out the activities from left to right, we can then ask for each activity, "What are the steps the user will have perform in order to complete that activity?"

Sometimes there is more than one way to do the same thing. We just love to do that in software, so sometimes there are variations of the steps that might be formed. When that is the case, we’ll stack the varying steps on top of each other with the most common variation on top and the least common variation on the bottom.

As the mapping discussion progresses, we move from activity to activity, goal to goal, and persona to persona until enough of the product story has been visualized. In the end, we’ll have laid out the experience we wish for our users to have from left to right and variations of that experience up and down.

Product Story Mapping

Story maps are also a tool for retelling the product story to leaders, stakeholders, and even new team members. It’s a quick way for everyone to gain a common understanding of what we are trying to accomplish.

Identifying Journeys Through the Product Story

Sweet, we’ve totally got this awesome product story now, but wow, there is a lot of work there. We again need to select a place to start and order our work in a manner that will allow to incrementally build and validate what we build.

Back in the epic-thinking space, the problem was simple to solve from here. We’d take each one of those big activities and call them an epic. Then, we would build all the stories in that epic before moving on to the next one.

Imagine the activities in the image below are login, search, and buy. We simply will start with login, then build search, and then build buy, right?

Product Development

No, no, no, please don’t do this. We have seen some of the most robust login features ever because that was the place the team chose to start. We want to start at a place that will help us learn. Login is a very understood paradigm and will not help us learn about our users, our systems, or our technology.

More importantly, thinking in epics (or columns in the picture above), entails that we don’t have a whole path through this experience until we are completely done. We want to select our place to start by identifying journeys or paths through this experience that represent a whole increment of value.

Okay, so what does this look like? Let’s select some paths across this experience.

Product Development

The green, blue, and purple journeys aren’t the only ones in this picture, but once we have the three of them done, the user has a way to accomplish the first goal. We’ll identify other paths as well, and then ask ourselves, "What do we want to learn first?"

Let’s say in this scenario that search is complex. Maybe we are doing that on new tech or in a new way. We want to make sure we can get it working and test with users before we get too far down the road, so we’ll do that one first. Then, that buying piece is always super important, and let’s do login last since we have implemented login before. Now, we can write out the order of our journeys to be something like this.

Product Backlog

• Blue journey
• Purple journey
• Green journey

We can even begin to size those journeys. Don’t deep dive into points or days estimates here; we don’t know enough yet, but we can give them a relative size like a t-shirt size.

Product Backlog

• Blue journey – M
• Purple journey – M
• Green journey – S

Voila! Now we have an ordered and sized product backlog of journeys. You can call them epics or features if that makes you feel good. The key isn’t the name. The key is that you are selecting by taking a path through an experience versus selecting a vertical slice of the experience.

Authoring Stories and Tests

Now, that we have an ordered and sized list of journeys (aka a product backlog), we can begin iteratively authoring stories and tests for product development. We’ll tackle that discussion in our next post "The Story of Stories: Managing the Product Backlog."

Comment (1)