Visualizing the Product StoryIn 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 MappingStory 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 StorySweet, 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 DevelopmentNo, 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 DevelopmentThe 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.
- Blue journey
- Purple journey
- Green journey
- 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.