A Magical Meeting Story from Staircase Strategy co-founder & facilitator Eric Morrow
Welcome to Magical Meetings Stories, a series where I chat with professional facilitators, meeting practitioners, leaders, and CEOs across industries about their meeting culture. We dive deep into a specific Magical Meeting they’ve run, including their approach to facilitation design, and their tips and tricks for running meetings people thrive in.
Today’s story is with Eric Morrow, a well established facilitator, instructor, and author. He has worked with several Fortune 100 companies such as Capital One, Walmart, and Google, and taught with General Assembly, the University of Oklahoma and CU Boulder. At IBM he led design thinking projects that aligned executive teams and engaged essential customers. He also started Staircase Strategy to partner with fellow leaders eager to use Design Thinking to solve complex problems.
I spoke with Eric about his User Story Mapping meetings, what prompted him to implement them, what they help accomplish, and his advice for those looking to leverage user story mapping in their organizations.
“For me, you know a good workshop or a good meeting is hitting the mark when resistance to having that meeting disappears…where all the sudden people are asking for it, versus saying “Why do I have to do another meeting?” -Eric Morrow
Removing Obstacles
Eric first implemented User Story Mapping meetings while doing design thinking workshops at IBM. The idea of user story mapping, from Jeff Patton’s book of the same name, is to “talk about the user’s journey through your product by building a simple model that tells your user’s story as you do.” Eric explained there would be a point in the workshops that everyone felt comfortable about the outcome, but fast forward a few months, and the engineering team hadn’t built what was discussed. “There seemed to be trouble with the transition between what the design and product folks were thinking, and then what the engineering team was actually building,” he says. Eric identified a need to make the design thinking workshops useful for the entire team, not just the design and product managers. After doing research on how to bridge that gap more effectively, User Story Mapping was the solution he decided on as a way to bring engineers and agile teams more closely into a design thinking and research-based process.
The main purpose of the meeting is to bring the design, product, and engineering teams closer together and to be more in sync with each other: “Rather than this ‘throw it over the wall’ type of experience, it allowed the design leads, engineering leads, product leads to come together and really agree on what needs to be developed and designed and built, in a way that will really meet the end user’s needs,” he explains.
When I asked if he received any pushback when he first came up with these meetings, he said it was actually the opposite and the pushback came before the meeting was implemented. Engineering teams didn’t want to waste their time doing design thinking activities, they told him, because it didn’t actually help them, and didn’t give them anything tangible to work on (which is what they really need, as they’re often evaluated based on how much code they push): “So I think the pushback was on design thinking workshops before I started using User Story Mapping. And then after that, design teams were really excited to come because they knew that what they were going to be working on was going to be relevant for the engineers. The product managers were happy to come, because by understanding what the engineers would be working on, they could validate those ideas with their end users/customers, and give them a better sense of what would become available. And then engineers liked it – if engineers build something that’s not ultimately used, they have to go back and redo it. That’s a big waste of time. And so the engineers were really happy to say ‘well, this has already been validated, this is good to go, that means we only will have to write that code once. We’re not going to have to write it then throw it away then write it then throw it away.’ For me, you know a good workshop or a good meeting is hitting the mark when resistance to having that meeting disappears…where all the sudden people are asking for it, versus saying ‘Why do I have to do another meeting?’”
Let’s take a closer look at Eric’s process to learn what makes his User Story Mapping meetings magical.
The Meeting
Pre-Meeting Prep
Eric recommends going into the meeting with two things (which is usually the design team’s responsibility to prepare): the personas and “as is” scenarios. The persona is who it is you’re building a feature for – it could be the end user or key stakeholders. Especially in B2B solutions, the person buying software may be very different from the person using the software, for example, so having personas for different people is important. The “as is” scenarios are understandings of how those people get their work done or go about their life today, as is.
Exercise
These User Story Mapping meetings, which Eric recommends holding quarterly depending on the pace of the team, should include design leads, product leads, and engineering or technical leads. This meeting can be done with various sizes, but doing it with 6-8 people will likely take 2-3 hours in a remote setting (slightly faster if not remote). The main question the teams are trying to answer should be some form of a big idea: “What are we building? What ideas do we want to implement? What could we do to improve someone’s experience or help solve some of their problems?” Since each team will likely want a different version of an answer from that question, the purpose of the meeting is to get everyone on the same page and understand needs from the other disciplines.
Mission Statement:
Eric explains the next step is to merge those three key pieces (the persona, “as is” scenario, and big idea) together into a mission statement, or as IBM calls it, Hills. “It should be some version of: A user wants to accomplish this goal, for whatever the reason is. For example, if we’re talking about a taxi hailing app, it would be: An airport traveler wants to press a button on their phone to summon a taxi to see where the taxi is and how much it’s going to cost to get them home after a trip.”
The “to be” experience and user stories:
From there, the goal is to map out the “to be” experience for your persona, or what their life will be like after the solution or feature is available,(compared to the “as is” experience, which is what their life is like currently. The “to be” experience is full of steps, and the teams should break down each step or feature into user stories. Working closely with the technical team here is key, Eric says, to outline each individual piece that will enable the experience at a very granular level. The individual pieces are everything it would take to implement the experience. Going back to the taxi hail app, examples would include needing to get a user’s GPS location, ability to show where all the different taxis are located, ability to quickly determine a price based on a database, etc.
Revisit the big picture:
After getting granular, the next step is to zoom back out to the bigger picture and determine if the overarching “to be” experience still makes sense once all the details have been outlined. And usually, what happens when everyone looks at the granular details of the user stories, he says, is the team will want to change features around or revise the mission statement, and go up and down this chain quite a bit. “So after you’ve refined your mission statement, maybe you go back and revise your ‘to be’ experience and you revise your user stories. But this is really the magic – rather than spending too much energy at any one stage, I recommend teams move quickly through the back and forth of all these steps.”
The tools:
After the “to be” experience and all the user stories are mapped out, it’s time to put them into an agile backlog in order to plan and prioritize them. Common tools for this include JIRA, Asana, or Github to keep track of all the tickets.
The golden thread:
The final step, according to Eric, is to make sure incremental value is being driven for the end-users. Using a golden thread approach, identify the key or essential experience, and build that first. “Generally speaking, folks are going to start building from left to right, and you don’t want to do that, you want to say: What’s the experience that will provide value to the end-user? So you can put it in front of them, get feedback, and then keep building with feedback from your end-user. That’s about 2-3 hours for all that work, for one very specific feature.”
Roles and Responsibilities
Typically in a User Story Mapping meeting, Eric recommends having at least engineering, product, and design leads. Other teams could also benefit, such as sales and marketing or legal, even just as observers to see what’s coming down the pike.
“The way I think about it, the most amount of work ahead of time is done by Design at the beginning. Preparing the personas, the ‘as is’ scenarios, and then during the meeting, everyone participates in the big idea creation, the ‘to be’ scenarios. And then the engineers are much more involved when you get to writing the user stories. And then once again, the product person is going to be tasked with setting up the backlog, to ensure the engineers are working on the things most important to the customer, at the top. One nuance is if you have a lot of folks, you may want to split up or work individually for some of these story mapping bits, so that the team can make a lot of progress in concert, rather than working on everything one thing at one time. Especially if you’re time sensitive, you want to hammer everything out as quickly as possible. But other than that, usually it’s a whole group activity.”
The Deliverables
The primary deliverable is developing the user stories and curating a backlog for the engineering team, so they can immediately start work on any software development processes, Eric explains. A secondary deliverable is helping with the entire validation cycle, or according to Eric, the best part of design thinking.
Potential Pitfalls
I asked Eric about any potential pitfalls to this meeting. He says the biggest potential pitfall is if teams try to do too much, too fast at once: “I think a facilitator who wants to run this sort of meeting needs to understand how all the different organizations work, especially if they’re working mostly independently with a ‘throw over the fence’ type mentality. Often folks aren’t used to working together in this really productive way, so starting out small with one feature, not trying to bite off everything at once. So do a couple features at the beginning, to get folks used to working in this way. So that’s probably the biggest pitfall, biting off more than you can chew if the team is not prepared to work this way and then ramping them up as you go along.”
Advice
Eric and I also discussed advice and recommendations he has for those looking to implement User Story Mapping meetings and workshops but maybe haven’t done them before. His recommendation is to keep it simple at first – start with just three people: the design lead, product lead, and engineering lead. Then, choose one small thing that’s important, but fairly far in the future. If possible, keep it to a one hour rapid fire session. “To do that, you really have to narrow down the scope so choose one feature that needs to get released. That’s what I recommend,” he says.
Other Resources
There are a few resources Eric recommends reviewing for those that want to learn more about user story mapping:
Looking Ahead
I asked Eric what he wants to do next, and how he might take User Story Mapping to the next level. He said he’d like to connect the specific, granular details back to the strategic aim: “Usually, your senior leadership leaves those technical details alone. But if you can show them – here’s how you take an idea, a strategic initiative, and here’s how we map it out so it aligns with all the initiatives of your entire product team, from the product owners to the product designers to the engineers. And moves all in concert. Through having sufficient upfront design research where you’re vetting all the features with your customers or with your users before shipping and building, we’re going to really improve the velocity of your engineering team and your ability to go to market. So I think if you’re really bold, you can use user story mapping to help show senior leadership how to achieve strategic initiatives faster and more effectively.”
