Let’s discuss why story mapping is needed to create a shared understanding of how your team can focus on the right user stories.

If I told you I was going to trek off into the Texas Hill country in search of an undiscovered cold spring (a rarity, these days!), in the middle of the summer heat, with no digital or paper map, you would rightfully tell me that I was a mad man with a death wish.

And yet this is how many digital product teams work today — building features and products with no real map of where they are going, or how they will get there. Too much focus on “getting things shipped” and too little focus on the “who, what, why and how” of the thing you are looking to ship.

The “Map” that so many product teams are missing, is collaboratively wrought user stories, but before we can get to the solution we need to take a harder look at the problem.

The “Map” that so many product teams are missing, is collaboratively wrought user stories

Let me know in the comments if this sounds vaguely familiar: Someone higher up than you in the company comes to you and says that for the next quarter they need X delivered, and they need it delivered by Y date.

You start to sweat. You think about all you have to get done in that time — design, development, testing, budgeting…but you dutifully nod your head, and get to work. Maybe you spend a few days thinking about the requirements, but ultimately due to the pressure you feel (and possibly a lack of support from the organization), you jump into action with design and development, putting together a rough concept of what you need done, and as quickly as humanely possible, jump into JIRA to start putting tickets on the board so that you can get estimates and start “managing” the project.

Your designers and developers make some pretty big guesses at what you/the business/user needs, but that’s just part of the culture at the company — no one has time to do anything more, so everyone gives it their best shot, and hopes for the best when it comes time to release.

Maybe you can identify with some or all of that, and while it might sound ridiculous to some of you, the reality is this is how many product teams function! It was certainly how I worked for a long time, even before formally donning the title of product manager.

There are two big problems that this type of behavior produces:

1. As a product manager you are not giving yourself the required time to think through who your users are, what they want, and how these wants thread into a narrative journey through your product. And because of this, you have no way to create any kind of up-front iterative release strategy, because you don’t have a holistic picture of their journey.
2. You never took the time to create a shared understanding amongst the larger team (which includes anyone involved with the creation of the product as well as internal stakeholders). Many of us think that detailed documentation in JIRA or Confluence, or a 10 page product requirements document is what is required to create shared understanding, but it isn’t. Documentation is never a proper stand-in for conversation.

Documentation is never a proper stand-in for conversation.

The result of these problems is a Frankenstein product made up of a mixture of your wants, the business’s needs, and what your designers and developers thought you, the business, and your users wanted.

Here’s the worst part. It’s almost never what your users actually want or need, and because of how it was created it will be even harder to iteratively change into what your DO users want over time. Many companies scrap these products after a few months or years and start over from scratch.

So how do we keep from falling into this trap? The answer is deceptively, embarrassingly simple. Talk to each other! That’s really it. Have cross-functional conversations about (and with) your users, who they are, how they work today, what their pains are and what tasks they want to accomplish.

Talk about what this could mean to your business — what kind of revenue stream solving these problems could create or what kinds of new markets it would open up. Guide and document these conversations using something called a Story Map.

Jeff Patton’s book, User Story Mapping, describes the concept/process of creating user story maps much better than I can, and this book really is a must read for any agile product manager. Seriously.

Just stop reading this article for a few seconds while you click on that Amazon link and buy the book. (I have no affiliation with Jeff, nor do I get any money if you buy the book…I just believe that every agile product team should have a commanding knowledge of the content in the book.)

So how do we keep from falling into this trap? The answer is deceptively, embarrassingly simple. Talk to each other!

User story mapping is simply the process of getting in front of a physical or digital whiteboard (I use mural.com), with some key stakeholders and discussing the users narrative journey through your product/feature.

You discuss who your users are (you’d be surprised…there are usually more users of your product than you originally thought), what tasks (in narrative order) they want to accomplish within your product or feature, and then slice out an iterative release strategy by grounding each release in a goal that release is designed to accomplished. This leads to creating a release strategy that solves user and business goals up front, and follows a clear path as you release more functionality over time.

Most importantly, a few amazing things come from this process:

Your designers and engineers will love you.

For the first time, maybe ever, your designers and engineers will have a map of the user’s journey that directly ties into specific, granular tasks that they want to accomplish.

On top of this, you are not creating detailed design/engineering tickets dictating to them exactly how they need to go about designing/building the solution, but instead give them the freedom to find the best solution to the user’s need, within a controlled map.

And on top of this, they will have a shared understanding of the user’s journey with the entire cross-functional product development team, which no amount of documentation can accomplish.

Your customers will love you.

You are now delivering meaningful, delightful and user oriented features that your customer’s can actually use to solve their problems! Of course agile development always has some risk baked in, but now you are significantly de-risking the equation.

You boss will love you.

And because your users love you, your boss will too. Not only can she now see a clear line between her ask and what your users will actually be receiving as a phased plan, she can also (hopefully) see much more meaningful financial results from your launches, as your users are more engaged and delighted than ever.

As good as this sounds (and trust me, it IS good), you don’t get this for free. I don’t know your organization specifically, but there are a few things that will likely need to change before you can make this reality, YOUR reality.

You need to define a product development process that includes story mapping.

Without a clearly defined product development process, your leadership will have a hard time understanding why you’re asking for more time to produce a plan/roadmap.

So spend a few minutes and outline all the key milestones that need to be accomplished to get a feature to market for your business, and make sure story mapping (and any related steps) are included.

You need more time.

Once you have shared out the product development process, make it clear to your leadership that the extra time you are asking for is not a nice to have, but a must have in order for you to do your job.

Don’t sandbag, either — leaders will see through this, and remember, you are still an agile PM and this means setbacks and failure aren’t the end of the world; they are inevitabilities and the only way you will learn to build something truly revolutionary.

You need the time of other people.

Listen, this process isn’t complex (again…read the book!), but it does mean you will likely need to talk with more people for longer periods of time than you are currently. At first they won’t understand. “Why is this product manager inviting me to a three hour meeting?”

It’s your job to educate your organization on the value of these conversations, and the more you empower them to get involved in the products you are building, the more accepting they will be. Oh, and once they see the results of the time they gave you in the form of a released, successful product, any other questions or frustrations will likely go out the window.

Here is a challenge: Pick a feature you are getting ready to start ideating on, and set up a story mapping session with some key members of your team. It’s not only okay, but recommended to lead a session when you’re completely new to the practice yourself, as this is the best way to grow and learn.

Read one of the articles I’ve linked below, set up a Mural board, and just have a conversation with some team members. And send me any question you have — I’m learning right along with you, but if I don’t have the answer, I will help you find it.