Our first experience with story mapping

One of the hardest aspects of building a product is making sure we solve real problems for our users. Although everyone in a product team loves spending time polishing a new feature, writing good software, and ultimately building something they can be proud of, it’s important we focus on delivering real value to our users fast. “Think frugal” is one of our company values, and time is an expensive resource, hence why we try to keep our development processes lean and iterate fast on what we build.

A few months ago we started working on a crucial part of our user journey, the booking flow. Touching such a big piece of our product quickly turned into an overwhelming task for a few reasons. After a number of meetings, we realised the different aspects of the booking journey were simply too many and too sparse to keep in mind or write down in a document.

Story mapping is a backlog visualisation technique invented by Jeff Patton, who also described the method thoroughly in the book “User Story Mapping”.

Story mapping proved to be a great tool to gather requirements in a collaborative way and come up with a realistic release plan for this massive feature.

Layout the user journey

First, we focused on a high-level overview of the user flow. At this stage, it’s crucial to “think mile wide, inch deep”. While it’s tempting to dive into the details of particular steps that excite us most, don’t spend too much time finding an answer right now. Make sure to write down relevant questions and ideas and keep them available for later.

After sticking all our post-its on the wall, we found out our layout of the user journey had a few holes in it. After shuffling the steps around and filling the gaps, the journey finally made sense to everyone, and we all had a clear idea and a shared understanding of how users would reach their goal of booking a space on our platform.

Write the details of the users’ activities

Now it was time to dive deep into the details of how the users would carry out the activities we laid out before. At this point, we wanted to be as thorough as possible.

During this phase, it’s important though to keep talking in terms of what our users can do through our product, not how they do it. It’s a subtle but crucial point that will save time and will keep the story mapping flexible.

An easy mistake here is to start talking in terms of interface: “press a button”, “select an option” is how engineers and designer tend to explain user interactions. Saying that a user “can select a range of dates” is much more flexible than saying that a user “can open a date-picker and click on a day”. These kinds of details will be worked out further down the line by designers and engineers. This approach helped us keep the feature description decoupled from the actual implementation, and make the communication easier between the stakeholders.

As before, we want to take note of everything we think is relevant and we don’t want to forget about. We found out a lot of these things would then be left out of the feature, and this turned out to be a recurring aspect of the process. Whenever we came up with any doubt or thought again about something we discarded, we could easily remember the conversation we had about it and the reasons why it was discarded. Answering recurring questions from different stakeholders became much easier as we were building a shared understanding of the product.

Slice out the releases

After going through all the details and describing the activities of our users, we now had a full map of the feature we had in mind. At this point, there was no doubt about what each step would consist of and the flow had no substantial gaps.

The goal was now to identify the core functionalities of our product, essentially leaving all the rest for later. The output of this phase would be a set of features we were going to include in the first release or MVP, and another set of features we were going to add later on, in one or more releases.

This step was equally painful and fun. We ran through each individual story mapped out on the wall and told if it was absolutely necessary for the product to help the users reach their goal or not.

One thing to keep in mind, especially for engineers, is that the focus should be on building the simplest solution that lets us ship the functionality, and ultimately deliver value to our users. Big architectures and over-engineered features rarely find a place in a first release, and it’s important to keep a flexible mindset. Also, try and resist the urge to automate everything right away. Some manual steps carried out by an engineer once a week can be a lot cheaper and flexible solution than an automated task deployed in the cloud or any other sophisticated system that needs to be tested and monitored.

From here, we moved on to planning the development of the feature itself, based on the stories we wrote during the story mapping. Planning can be a tedious task as it requires focus to write down the specs of what the product team is going to build.

What we’ve learned

Kicking off the project with the story mapping helped us build a first release of the feature in two months, and deliver value to our users.

Our main goal was to make the experience of booking a space delightful and easy, and story mapping helped us focus on the functionalities that would make the experience exponentially better.

A few key points we learned during these months:

• Story mapping is useful to tackle big features in a more approachable way
• Story mapping helps build a shared understanding of a feature or product
• Story mapping helps us find holes in our thinking
• Involving all the stakeholders as soon as possible is crucial to get a feature or a product right
• Building a product is an iterative process: story mapping leaves room for adjustments based on learnings
• Story mapping helps us focus on the “why” and the “how” instead of the “what”.