Stories, Maps and Products

Product opportunities come in many forms, and there's just as many ways to define an opportunity and translate it into something tangible.

To create a great product, Product Managers, Developers, and Designers (among others) need to both understand the larger context, and develop an intimate knowledge of every detail.

Recently we’ve been using a pattern called ‘Story Mapping’ (coined by Jeff Patton) to help us do both. Originally developed to bridge the apparently irreconcilable practices of user centered design and agile development, the benefits of Story Mapping apply even when the organization is not using an Agile methodology.

The (my) case for story mapping

Story mapping gives us a tool to decide what's in scope and what's not. Ideas are easy, and making a great product is as much about making tough calls on which features don't make the cut as it is about interaction design. Story Mapping can help you balance what your user needs and what you can deliver on time.

This is a low cost, fast and transparent process. It's great for exposing and managing complexity that otherwise may have only been found when the developer or designer are actually building the product.

The act of writing a 'story' requires us to empathize with our user. A product that anticipates the desires, fears and aspirations of a user will almost certainly exceed expectations.

Getting Started

The Story Mapping process needs inputs, something to frame the activity. We need to know where this story starts, where it goes, and where it ends.

These goals are usually found in business requirement documents. As the name implies though, story mapping, like a good story works best with actors and motives. In the user experience world we create Personas to consolidate user research into a set of archetypes representing the spectrum of your audience.

Before getting started we choose one of our Personas to be our headline actor. With our feet firmly in our persona’s shoes we start telling stories of how Jane (no longer just a ‘user’) would get this job done, and very importantly: why Jane does this.

We’ve been trying to keep this process simple, light weight and maybe even fun. This way the team can see the benefits of the process as they’re working on it.

Get started with lots of post-it notes, lots of wall space, and a cross discipline team. Keep your team small, I’d suggest 3 at most. People who’ve been involved in your research, listening to potential users, are your best bet for informed contributions.

Product managers, subject matter experts, client support staff and designers are also likely candidates for your team, and don’t hesitate to work with developers, even potential users themselves. You can always bring other people to your completed map later to review and test the stories.

Telling stories with your team

See Jane's user experience


Begin with high level chunks, describe Jane's work flow from end-to-end. Use a post-it for each step. Keep the steps broad enough that reading through the steps end to end will be about the length of a sentence. This is often called the 'Epics' level.

An over simplified example:

Reading through your 'Epics' should describe the tool in the length of a sentence.

Jane wants to read, manage and respond to incoming email and also create and send new emails.

Think of these as buckets of functionality to cover the user’s needs, and, of course, to address all your business requirements.

Keep reviewing and adjusting these as you build the map.


For each of those high level steps do the same again, but now with a bit more detail.

Note what the user’s goal is, what they want, and why.

“Jane wants to prioritize emails from multiple accounts to balance two jobs and feel in control.”

We call this level of story ‘activities’.

Jeff Patton describes Activities as groups of related tasks that can be achieved in one sitting.


Think more granular as you write the next level of stories: what are the individual decisions or actions that Jane wants to make?

These ‘Tasks’ get us into the details of each Activity, and expose all the complexity of activities that previously we wrote off as simple, or not a big deal.

Position them horizontally in sequence so you can read from one to the next: Jane ‘browses’, [and then] ‘selects’ [and then] ‘marks email as high priority’.

Read ‘or’ between tasks down the column, ‘and then’ between columns.

Of course in any workflow there maybe several options at any one point.  To accommodate this we stack stories vertically  – so we can read down a column of stories with ‘or’ in between: Jane ‘browses all emails’ [or] ‘searches by keyword’.

It’s important to give this step it’s due. Tasks are the building blocks of your map. The key benefits of story mapping are gained by validating the Activities and Epics above with cohesive, comprehensive and highly detailed tasks.You may find the need to revise the Activities and Epics as you expose the details.

Feature Prioritization Triage for user satisfaction

Take all those vertically stacked ‘or’ tasks and prioritize them. Reposition the tasks that are most crucial to Jane and move them to the top of each column. These are the tasks that are necessary for Jane to complete her goals. In my very simple example above, it’s critical to be able to select an email, selecting multiple emails is not.The items at the top must allow the Jane to move horizontally through the stories and achieve the most important goals – this is your minimum viable product.

Scoping This step makes Story Mapping ‘agile’ and time-line friendly

Your team can now slice through the map horizontally to select which tasks will be addressed per release. Here you can evaluate effort estimates, demand or necessity of a feature and of course your time line. If your organization is using agile you can fill your backlog and sprints in this step.

‘Search can wait, but we’re able to do multiple select now…’


I think this is a great tool to shine a light into all the corners of your product. A wall covered with post-it notes makes product plans tangible and physical, everyone can see literally how big it is.Stand back to see the big picture, step forward to understand every little piece.

Be prepared for your map to get HUGE, and for folks to baulk at putting the effort into something made of post-it notes. If that happens, I’d point out the alternative: some individual has to sit down and type out a document that details every little bit of the product. Then many people have to sit down read, and respond to that document. Revise and repeat. Personally, I’d prefer to hash it all out in a team with pens and paper.

You can rally your team around the story map, where everyone can discuss, understand and contribute to the entire undertaking, and celebrate each milestone reached.

P.S.Obviously story mapping is best in-person, but reality means we work remotely sometimes. I’m still struggling to find a good online tool to do this process with remote teams. There’s a growing list of tools, from simple and literal post-it note apps like Listhings, through to agile project solutions like Silver Stories, and ScrumDesk, none of which I endorse due to either being under powered or overly complex.