How user story mapping changed our MVP: lessons learned

“Suppose you were Da Vinci, and you wanted to create a painting and you were working the way a naive software developer does. You might start with what you believe is a clear vision of the painting in your mind. Then you break up the painting into its parts. Let’s say you had five days to paint this painting. Every day you’d paint more parts. At the end of day five, huzzah! — you’re done! What could be simpler?”

-Jeff Patton (User Story Mapping)

We imagine that great artists know exactly what they want their finished product to be — but they don’t. Source

Patton goes on to describe that artists do not work this way. The way that artists (and product development teams) should work is to first create a sketch of the entire end product. The sketch is far from perfect, and it will change, but the important thing is that it’s all there. Next, the work is about filling in the sketch with details — colours, lines, etc. That way, if something structural about the picture needs to change, it can be done fairly easily. Doing this means that the end result will be cohesive.

A sketch is a complete picture, but it is not the final picture. It allows us to make changes until we land on something that works the best. Source

Building Mona Lisa

As crazy as it is, reading two pages of Patton’s book undid almost 9 months of work. I had been the designer on a small team creating a hiring and scheduling platform called Pear Square. We were running into a lot of problems, because we were trying to create the first Mona Lisa. We would build one part of the platform at a time. We’d have grand visions for what that part should do and look like, and spent a lot of time perfecting the designs. Often, we would keep adding complexity until we couldn’t keep track of what features were in or out. Each time we moved on to the next part, we’d think of new things to change, and suddenly what we had already built needed to be rebuilt. We were moving in circles.

Turning Point

After working this way for months (with frustration mounting), my boss, the founder of the startup, became exposed to the technique of User Story Mapping. She realized that what we were missing was a plan of the big picture. The reason we couldn’t move forward was because we didn’t have a clear enough idea of where we were going.

User Story Mapping is a way of visualizing a complete system. It involves writing out (on stickies, index cards, etc) all the general actions that take place in the system, in chronological order. Underneath, you write out all of the tasks involved in each action. In his book, Patton uses the example of getting ready in the morning.

It’s easy to imagine what we do when we get ready in the morning, and to break down those actions into individual tasks.

We mapped out the system that we were building in full, and we were shocked when we saw how complicated it would have been. We had user maps nestled within other user maps, to explain in more detail what certain portions of the site would have required. Seeing the whole thing laid out was a turning point for our development.

A portion of our original user story map shows the primary actions for 1 user (there were 3 in total). Lines connect to even more user story maps.

We quickly switched gears and focused on how we could simplify things, so that the user would still get from point A to B and accomplish what they wanted, with the least amount of steps possible. The great thing about User Story Mapping is that its so easy to walk up and scratch something out, move stickies around, and group things together. We actually ended up scrapping the system we had been working on and decided to build a much simpler system, one that would be very quick to produce an MVP of and begin collecting feedback. We believe that taking a week to map out the system we were building was the reality check we needed to realize we were moving too fast in the wrong direction.

Key takeaways from using User Story Mapping to manage scope

• Seeing our whole product plan laid out encouraged us to figure out how to reduce complexity. We thought about the problem we were trying to help users solve, and looking at the map was a quick way to see if there was a simpler way to solve it.
• When the product doesn’t exist yet, it’s really hard to think of all the tiny details it will need. User mapping was a great way for us to discuss details, and we were able to catch a lot of mistakes before sending designs off to the dev team.
• The most valuable thing about user mapping was that doing it together got us on the same page. We discussed each action and task, and came to a decision together. Down the line, this meant we were more aligned, and we could use the map as a reference if we forgot anything.

Conclusions

I have learned a lot working on this project. It’s hard to swallow your pride and recognize when something isn’t working, especially when you’re building something new, and you want to skip to the part when it’s great and everyone loves it. However, before getting caught up in small details, it’s important to have a general picture of how the entire system will work. User Story Mapping was super helpful for centering our team when we felt like we had lost our sense of the big picture, and it helped us realize that there would be a much easier and more effective way to build our MVP.