Scenario-Focused Engineering (2014)
Part III: The day after
Chapter 12. Lessons learned
The ideas in this book are easy enough to grasp, yet they are deceptively difficult to put into practice. In the last chapter, we talked about changing how you work, shifting from old ways of doing things to new ways. But beyond those mechanical and procedural differences, we’ve also been highlighting deep cultural shifts and mindset adjustments in the Mindshift callouts throughout this book—everything from understanding that your first idea is probably wrong, to truly believing that you are not the customer, to becoming comfortable with showing half-baked work to gather early feedback. These ideas challenge long-held beliefs about how we build software and the habits and practices that we have developed over the decades. Even if everyone involved truly believes in the power of Scenario-Focused Engineering and the Fast Feedback Cycle, adopting these practices in a team’s daily work and getting them to stick is no small feat.
We have definitely seen teams encounter some speed bumps in adopting an SFE-inspired approach. We have also learned the hard way that some of our assumptions about what teams need and how best to make change happen turned out not to be true. Indeed, we made some mistakes in presenting these concepts to a few teams as we got started on this journey. For a couple of teams, critical errors in the team’s rollout made the entire proposition so frustrating that people came to think of SFE as a four-letter word. We’d like to help others not make the same mistakes. This chapter focuses on the biggest lessons we’ve learned over the past six years and the mistakes we’ve seen teams and individuals make.
Getting started
These are some of the first lessons we learned while teaching SFE and while observing teams during their first months of adopting some of the practices.
Getting to aha isn’t enough
We started the Scenario-Focused Engineering initiative with the conviction that if we just brought these powerful ideas to engineering teams in a way that they could understand and appreciate, the rest would take care of itself. We knew that Microsoft was full of brilliant, motivated, passionate people, and we figured that once people got the basic ideas, they would take them to heart and find the best means of incorporating them into their teams’ work. Furthermore, we believed—and still do—that no single recipe would work for every team and that teams generally wanted to invent and create their own processes. So, we were reluctant to be prescriptive about what specific practices, processes, and schedules teams should use, since every team is different in its size, composition, scope, goals, constraints, and so on.
We focused our efforts on kick-starting teams to see the value in these ideas, bringing people to what we called the aha moment. To do this, we created an experiential workshop, designed for intact teams. The workshop was structured so that it would gradually rise to a climax by midafternoon, when most students realized that their first prototyped ideas didn’t make sense to the person sitting next to them, never mind a customer. Students would realize that a bit more science and rigor than they thought was involved in figuring out what customers really want. A light bulb would go on in some new room in their head, and it was fun and exhilarating to be part of that experience for thousands of people.
Fascinatingly, after teaching hundreds of these classes, all of our instructors agreed that when this collective aha moment happened, the shift in the room was palpable. Most of the people who entered the workshop as skeptics agreed by the time they left that these ideas had merit. The whole class would spend the last hours of the workshop in deep conversation about how significant a change this was from their old ways of doing things and discuss plans for how they would overcome those challenges.
Looking back, it is remarkable how much ground we were able to cover in a single day. The feedback we received was very positive, and word of mouth traveled quickly. It sure seemed like it was working. We firmly believed that once we got leaders and their teams to that aha moment, the rest would be easy, and that with time, patience, and some iteration, these practices would naturally become part of a team’s work.
We couldn’t have been more wrong. After teaching more than 22,000 people, we can say with conviction that taking a team through a one-day workshop is a great way to start a team’s transition to new practices, but on its own, it’s not nearly enough. Despite the best intentions, old habits are strong, cultures and values are tough to change, schedules are tight, and institutionalized processes and tools deeply impact the way people think and work, often at a subconscious level. Until you address both the complexities and subtleties that are embedded throughout your formal and informal engineering systems, team culture, and organization, don’t expect much to happen. We saw team after team start with enormous passion and motivation, but without strong, visible leadership support and a well-staffed effort to wrestle with how to operationalize these changes and make them real (or a supermotivated champion with the energy to move mountains), that momentum fizzled. Those teams still got some benefits, but the benefits were small in comparison with those gained by teams that really went the distance and had strong leadership support.
Many of the lessons we describe in this chapter detail specific aspects of the complexities and subtleties that we’ve learned over the years, which are vitally important for teams to pay attention to if they are to make this shift successfully.
This isn’t paint by numbers
We’ve tried. We’ve tried really hard. But somehow, this message never quite comes through. Neither this book nor any other book can give you step-by-step, prescriptive guidance about how to put customers at the forefront of your thinking or how to create the next killer app that rocks your customers’ world. If that were easy, wouldn’t everybody be doing it?
To this day, teams say to us, “Just tell us what to do!” But, you see, we can’t. Every situation is different. Every step of the way, critical variables involve the characteristics of the product, the type of target customer, the maturity and skills of the team, and the business opportunity you are going after. The same techniques and informal process that work terrifically for a 10-person team building a new game app for consumers clearly aren’t the right ones for a thousand-person team building the next version of Office. The Fast Feedback Cycle has an underlying rhythm and includes many broadly useful techniques, but no single, complete formula works in every situation.
In our original workshop, we showed an image of the Mona Lisa made up to look like a paint-by-numbers page in a children’s coloring book. The point we were trying to make is that you can’t just blindly follow someone else’s scheme and fill in the colors. You won’t get your own masterpiece that way.
We then showed an image of an artist’s palette and a set of brushes and tools. That’s what we’re trying to provide in this book—a palette of paints, plus tools, techniques, ideas, and mindsets that you can use to create your own masterpiece, as well as some guidance on which tools tend to be most helpful for different situations or phases of a project or different types of teams. The Fast Feedback Cycle is a toolbox, and you have to pick which tools make the most sense for your situation to help you reach your goals within the constraints you have to work with.
You may well find that the techniques you used on your last project don’t work as well on your next project, perhaps because of differences in the team’s skill set or in the type of problem you’re trying to solve. Over time, as you gain more experience, you will develop your own favorite go-to techniques. But you also need to pick the right tools for the job at hand. Storyboarding, for example, is not likely to help much when you’re designing a new API. In some cases, the choice of technique is fairly arbitrary, but the important point is getting the larger team aligned on the same approach—for example, whether you will frame the problem by writing scenarios or by sketching user journeys—so that you aren’t comparing apples with oranges when it comes time to prioritize work. The bottom line is that you need a design process that makes sense for your team, your situation, and your goals and to be thoughtful about which techniques you use.
You don’t have to do everything
We’ve seen a few eager teams try to make too many changes all at once—for example, large teams that try to implement the entire Fast Feedback Cycle on their first try, change the way they schedule, move to a cloud-based services technology stack, and adopt Agile techniques all at the same time. They bite off more than they can chew, and midway through they realize that they just can’t keep up with it all. In the end, some of the changes they try to institute fade away without enough consistent success to build on.
We’ve learned that people consistently leave our workshops feeling like they have to do it all. Showing them the complete system made them feel as though there was really no hope unless they could do it all at once—and that, of course, was truly overwhelming. Teams need to understand the importance of choosing and adjusting the activities that work best in their current situation. We’ve seen plenty of teams make a ton of progress by implementing surgical changes or even just by adding a single new technique to their repertoire.
Over the years, we’ve been lucky enough to work with a few teams that had very strong leadership support from the beginning. These teams reaped huge value from the SFE workshop and were able to initiate a sustainable culture and shift to processes that capitalized on iteration and deep customer empathy. These leaders set clear expectations for change; established new tools, rhythms, and processes; and maintained that commitment to customer empathy over the long term.
But for the majority of the teams we’ve worked with, a holistic reset of their business, culture, processes, and tools was just not going to happen. For many teams, the complete set of changes we present in the workshop was simply too much work (and risk) to take on all at once. Every team has to do the hard work to find where and how it will incrementally shift its work toward the customer. All the changes we recommend are along a continuum and can be approached one bit at a time. For example, some teams first take on the task of learning to use scenarios, sketches, and storyboards to help align the team and partners and avoid being sucked into the rat hole of arguing over a myriad of implementation details and requirements. Other teams initially gain value from SFE by developing a handful of personas to serve as target customers for the team. Other teams find that they are already closely tracking to established business metrics and begin to develop and track experience metrics as well. It is essential to adapt the Fast Feedback Cycle to your specific situation.
You don’t have to start at the beginning of the Fast Feedback Cycle diagram and do everything in order, perfectly. A better approach is to take a holistic look and decide which techniques and aspects will best align and energize your team toward understanding and solving your customers’ needs. If you are already using an Agile project-management approach or have experimented with some of the Lean Startup concepts, you are probably already doing some of the things we’ve talked about. If so, there’s no need to reinvent the wheel. If you already have elements of an iterative culture and a process to support that, start with that base and add from there.
The good news is that the concepts and techniques we present in this book are not monolithic and all of them are valuable on their own even outside the Fast Feedback Cycle. You can decide which techniques, and to some extent which mindsets, are most valuable to you and then focus on those. Does it help you most to change the team culture to understand that “you are not the customer” and build empathy for your customer based on research and data? Perfect—focus the team on doing that well, and it will serve as a good foundation to build on the next time. Is the team struggling with too many priorities and lacking focus? Then start by doing the work necessary to decide what the top customer and business problems are and come up with a well-crafted frame to get the team aligned. It may not be perfect, and it may not be the full Fast Feedback Cycle, but it’s a step in the right direction. You get the idea.
As a matter of fact, you should feel free to adapt any of the individual techniques to your situation as well. If storyboarding with a software tool works better for you than paper and markers, go for it. If you come up with a new approach for rapid prototyping or for getting quick customer feedback, great. Our goal is to show the bigger patterns and goals of each technique and how they fit into the Fast Feedback Cycle. This way, you have the background you need to safely riff on these ideas without losing the magic so that you can successfully adapt them to fit your specific situation.
Take a few of the ideas in this book and try them out in your work. Pick the activities that are best suited for your team today. Make some progress, adjust as appropriate, and do it again. And remember, you don’t have to do it all. Just get started.
Don’t overindex on scenarios
We’ve seen lots and lots of teams get started by focusing almost exclusively on customer research and writing scenarios (it probably doesn’t help that we named our workshop “Scenario-Focused Engineering”). Many teams focus so much on the goal of writing SPICIER scenarios that they do great research, write tons of scenarios, spend way too much time trying to prioritize them, and completely forget about the rest of the iterative cycle. Once they achieve the goal of writing scenarios, they think they’re finished with SFE and can go back to their old, linear approaches to building products. Often, they spend so much time working on scenarios that they really feel the crunch to start coding.
Until you start getting customer feedback on your ideas, you won’t know whether you are solving the right problem. The longer you delay that, the more risk you carry and the bigger the waste if you indeed find you are pursuing a bad idea. Remember that the magic of the Fast Feedback Cycle is not in its individual activities and artifacts but in the repetition, iteration, and constant customer feedback. Optimize your approach to go around the cycle as quickly as possible, and constantly seek customer feedback to keep you iterating.
If you find that your team is overindexing on writing perfect SPICIER scenarios, here’s a better way to think about it. A scenario is a useful way to communicate the customer’s problem space. It can also be a useful place to park measurable outcomes. But, in general, think of a scenario as a tool for getting teams of people aligned on a customer goal or outcome and for developing customer empathy. We’ve seen teams achieve this goal a number of different ways, sometimes with SPICIER scenarios, sometimes without. But whichever framing tool you pick, the output does not need to be complex, and the resulting narrative does not need to be a work of art. Get it close enough, and let it fuel an iterative cycle.
Don’t forget about the end-to-end experience
We’ve also seen teams iterate and develop a great end-to-end experience for their customers early on in their process but then lose sight of that experience’s goals during coding and fail to actually ship that experience. Once they are coding, these teams tend to become distracted and forget about the end-to-end experience that they are targeting. They forget to get customer feedback and to measure against their experience goals. And as the team’s codebase becomes more and more complicated and compromises have to be made, it’s inevitable that the team’s work diverges from the goals of the original scenarios, while no one pays enough attention to notice. Teams discover late in the project, usually during an integration phase, that they have built a set of components and features that almost, but don’t quite, come together to form the end-to-end experience that they were intending. At that late date, it’s often nearly impossible to fix. This is a very frustrating way to end a team’s first foray into trying to build better end-to-end experiences.
We’ve seen teams combat this natural tendency in a few productive ways. First, it helps to introduce the Agile concepts of slicing and continual integration. Having regular team demos of the end-to-end experiences as they exist in the code is another forcing function that’s very helpful for fixing integration bugs early and for keeping focus on the ultimate goal. Another crucial habit to develop is to consider the end-to-end experience when you make technology or business decisions or when a component or feature runs into trouble and is at risk. Making decisions to cut features on the basis of the impact they have on the end-to-end experience is essential. Finally, putting formal mechanisms in place to track progress against scenarios or experiences ensures that everyone keeps their eyes on the prize. You can do this through regular scenario checkpoints, project reviews, scenario reports from project-tracking tools, or by maintaining up-to-date scorecards that measure metrics and progress against end-to-end scenarios.
Team dynamics
Some of the biggest lessons we’ve learned have to do with people, teams, and behavior.
Engineers are natural skeptics
We had an inkling about the natural skepticism of engineers when we started teaching our workshops, and our experience working with lots of engineers has definitely reinforced this belief. Maybe it’s in an engineer’s DNA, or maybe people with that type of personality are attracted to engineering in the first place. Engineers like to methodically tease apart difficult problems and find root causes, and in the process they dot the i’s and cross the t’s and see that it all adds up. Most engineers have gone through lengthy and rigorous training to learn these skills, and they’ve been rewarded with grades, jobs, and money for achieving excellence. They are masters at precision questioning, finding holes in an argument, and solving complex problems.
Many of the ideas in our workshop and in this book strike engineers as unfamiliar, unintuitive, and not what they’re used to doing. The first reaction from many engineers is to try to prove us wrong. And when you think about it, that’s okay. That’s a natural reaction. We learned quickly that we needed to be very thoughtful about how best to present these ideas for this target audience.
Over the years we’ve learned a few techniques to help appeal to the most skeptical of engineers and to get them over the hump so that they not only see the value in these ideas but are open to actually making a change:
Make it scientific As you can see throughout this book, we take a logical, scientific approach to explaining these ideas. We take time to explain the reasons why a customer-focused, iterative approach works and what happens when you don’t follow this approach. We describe the creation and iteration process as a system in which all the pieces are meaningfully interconnected. Even if a team uses only a few of the techniques, it helps for engineers to see how they fit into a larger whole that is systematic and thought through.
Make it experiential We found that giving people a hands-on experience in our workshop went a long way toward opening the door to seeing the value in these ideas. By watching video footage of customers or, even better, having a handful of real customers answer their questions, people experienced customers saying surprising, unexpected things. By sketching out some ideas, building a paper prototype, and then finding that it didn’t make sense to their colleague—never mind to an actual customer—people began to realize the need for customer feedback and iteration and that even if an idea made a ton of sense in their own mind, it may not make sense to anyone else. They were forced to generate multiple alternatives (and grumbled that doing so was pointless) and then realized that the best solution truly was a blend of several of the alternatives they had generated, not just their first good idea, which they probably would have stopped with.
Make it visible It’s really helpful for people to run into these ideas continually in their environment, which keeps the ideas visible and offers a growing realization that they are gaining traction. Teams do this by hanging posters on the walls, building museums of customer data, and posting sketches in the hallways. We also handed out bright-green plastic cards to workshop attendees that were printed with key SFE principles and perfectly shaped and sized to fit in a Microsoft badge holder. As people walked around, you would see a flash of green on the reverse side of their badge. This marked them as being part of the SFE “club” and created a sense of shared community. Over time, it created a visible movement across the entire company.
Show momentum We found opportunities to demonstrate momentum across a team, making it evident to everyone on the team that people had bought in and were ready to make a change. At the end of every workshop, we asked everyone to write down, on separate cards, the six most important ideas they got out of the workshop that they thought their team should move forward with. We collected these and used them as the major focus of the debriefing session we held with a team’s managers a week or two later. We worked with the managers to create an affinity diagram using the cards, taped them onto butcher paper, and hung the diagram in the team’s hallway. Without exception, these diagrams showed a strong consensus about the value of these ideas and enthusiasm for adopting them. The handful of skeptical comments were called out separately, and it was obvious that they were outliers. This approach made the remaining skeptics realize that they were in the minority and helped the rest of the team realize that they were more aligned than they knew and were ready to make a change together.
Interestingly, a strong minority of the engineers we’ve worked with are not skeptical in the least. In fact, they longed to work this way and were frustrated with their organizations’ current processes and approaches. Perhaps a quarter of the engineers we’ve encountered across nearly every team fall into this category. Without this largely invisible base of support, it may have been impossible to build consensus across a team. But with it, a small chorus in every group was saying “It’s about time!” and many of them stepped up to become champions and leaders on their teams.
Collaboration isn’t everybody doing everything together
Many teams find that when they work more iteratively and are focused on the customer’s end-to-end experience, they require much deeper and more frequent collaboration across the team and among partners. By collaboration, we mean openly giving and receiving feedback, building trust across professional disciplines and partners, allowing (and expecting) ideas to marinate over time, and operating in a more network-oriented team structure rather than one based on a hierarchy.1
But when the pendulum swings to encourage more collaborative behavior on teams, we’ve seen a few teams swing a bit too far and interpret collaboration to mean that everyone does everything together, all of the time—for example, you can’t have a meeting without every single team member, subgroup, partner, or discipline represented; developers need to put aside writing code in favor of going on lots of site visits; everyone must participate in writing scenarios and agree on the subtleties of each word; or that every member of the team must be part of every decision. Obviously, this sort of ultracollaborative approach simply doesn’t scale, and it doesn’t respect the unique expertise that different roles and disciplines bring to the table.
Design by committee doesn’t work any better in software than it does in other domains. The point of collaboration is not for everyone to put their fingers in every pie, but to be more flexible about who does what and lean toward being more inclusive in day-to-day work. The goal is to operate as a team, with the common goal of delighting customers by solving their end-to-end needs completely. If you’re going to build end-to-end experiences that cross organizational boundaries, clearly you’re going to have to collaborate across those boundaries to get your work done. Collaboration is a means to an end.
The four crucial benefits that collaboration can deliver are the following:
Team alignment Getting buy-in from everyone involved is especially important in early activities, when you are deciding on the customer insights you will pursue, framing them in scenarios, and determining the metrics you will use to measure success. This is doubly important when multiple teams, organizations, or even external partners need to work together to build an end-to-end experience. Everyone on the team doesn’t necessarily need to be involved in the scenario-writing process, but everyone should have a chance to review and understand where the team is headed.
Smoother integration As a project progresses, everyone needs to know how their piece will fit into the end-to-end experience and have direct access to the people they need to work with to smooth out any rough spots as integration progresses. Creating hierarchies or chokepoints is often counterproductive and results in the telephone game, where the true message gets distorted the more people it filters through. Let the people involved talk to each other and work things out directly.
Harvest the power of many brains In many of the activities in the Fast Feedback Cycle, it is beneficial to have different disciplines work together, including developers, testers, program managers, business managers, designers, researchers, and others. There are three reasons for this. First, you are more likely to discover great ideas when a diverse set of people is involved. Second, a diverse working group helps prevent groupthink from occurring. Third, representation from each discipline helps bring more constraints, knowledge, and possibilities to the forefront, enabling better quality decisions.
Personal experience Some activities, like customer visits and usability tests, are highly experiential and provide direct benefits by having people other than researchers participate in them. The chances of discovering an aha moment or gaining deep personal empathy with a customer are substantially greater through personal experience than by reading the CliffsNotes reports from someone else. It’s important that everyone on the team have an opportunity to partake in these experiences and not learn about them only from a report, an email message, or a presentation. This isn’t to say that every team member should go on every site visit or usability test, but the majority of the team should go on at least one. If that is not possible, the next best thing is for reports to include photos, video, and audio and to convey as much of the real-life aspects of the experience as possible.
In the Fast Feedback Cycle, collaboration doesn’t mean that everyone does everything all of the time. But it does mean that customer delight is everyone’s responsibility. Collaboration is about holding the team accountable for working together to delight the customer. It’s not about getting one piece of the system working and throwing it over the wall to someone else.
It’s difficult to predict who will shine or where
During the final exercise in our workshop, we display a list of the major activities that we’ve introduced and practiced throughout the day. The list contains entries such as interviewing customers, writing scenarios, brainstorming, sketching, prototyping, and putting together a project schedule. We ask the class to take a long look at the list and to select the one activity that they enjoyed the most. We then go through each activity and call them out one at a time, asking the students to stand up when we call out their favorite.
Now, you might think that what happens would be quite predictable—that all project managers stand up for writing project schedules and driving decisions, program managers for writing scenarios, the marketing team for talking to customers, and designers for generating ideas. But that isn’t exactly what happens. Instead, choices can be so unpredictable that the room begins to giggle when people stand up for their favorite part of the class. “You liked that? You’re kidding me, you are good at that? Cool, now I know.”
The distribution of who and how many people choose which activity is eye opening for the team. Usually, a strong contingent loves brainstorming (that particular exercise is very high energy), but among the other activities, the spread of preferences is quite unpredictable. Some teams clearly lean toward divergent activities, while other teams lean toward convergent activities. In some cases, certain activities are not chosen by anyone. We finish the workshop by talking through these balances, or imbalances, and then let the team consider how they would affect their work.
The lesson we’ve learned is that it’s a mistake to stereotype people in the same role or discipline as being talented and interested in the same activities in the Fast Feedback Cycle. While one or two job functions might have a preponderance of interest in a specific activity, a number of people from other roles will also be interested—the tail of the bell curve. You just never know who is going to come up with that brilliant idea, or who is going to become the strongest customer advocate, the best identifier of latent needs, or the best person to help the team shift from diverging to converging.
SFE in action: Diversity, conflict, and creative output
Kent Sullivan, Principal UX Researcher, Microsoft, with Tonya Peck, Chief Talent Officer, POSSIBLE; Cofounder, Locomotive Partners
I have been a design researcher at Microsoft since 1989. Over the years, it has become more and more apparent to me that some teams work well together, seemingly through magic, while others do not. I have seen teams collaborate very easily, sharing work and accountability, while others stumble over basic communication and information sharing.
Recently, I’ve had the opportunity to investigate this question in depth. As part of that work, Tonya Peck and I created an experiential workshop with the intention of helping teams identify gaps in their behavior while learning about some approachable tools for discussing those gaps and making changes. We presented a short form of this workshop at the Design Management Institute conference in Seattle in 2011 (http://www.dmi.org/dmi/html/conference/designthinking11/DT11PEC.pdf).
A core element of the workshop uses the Basadur Creative Problem Solving Profile (CPSP; https://basadurprofile.com/). This tool assesses individuals’ preferences for problem solving. Here’s a brief description of the problem-solving styles in the CPSP model:
Generator Gets things started
Conceptualizer Puts ideas together
Optimizer Turns abstract ideas into practical solutions and plans
Implementer Gets things done
After using the CPSP assessment with a number of teams, we discovered something quite fascinating—the vast majority of people on the engineering teams we modeled had primary quadrants of implementer or optimizer, while a smaller portion of the people were identified as dominant generators or conceptualizers. We also found that the bulk of the generators and conceptualizers were user-experience designers, with the bulk of user-experience researchers distributed between conceptualizers and optimizers.
We noticed that the teams that reported having a high degree of difficulty in creating innovative solutions primarily included optimizers and implementers and had very few, if any, conceptualizers or generators. In contrast, the teams that had greater diversity within the CPSP quadrants (in other words, there were enough generators and conceptualizers to provide some balance to the majority of optimizers and implementers) described situations where innovative solutions came to fruition more easily.
On these more creative teams, we also saw an increased level of conflict. To visualize the type of conflict we’re talking about, imagine a discussion between an energetic project manager who wants to account for undone work items and get them on a schedule (the implementer) and a creative designer (a conceptualizer) who comes up with a dozen new ideas every hour.
The teams that got the most benefit from these workshops were the ones that had a relatively balanced mix of styles and were experiencing a lot of spoken and unspoken tension and conflict that were getting in the way. By modeling the team makeup using the CPSP profiles, Tonya and I were able to identify where the greatest tensions most likely existed and were able to bring out those conflicts in a constructive way. No surprise, these tensions existed between the team members who are dominant in opposite quadrants. Specifically, the most conflict occurred between optimizers and generators and between implementers and conceptualizers.
For example, one of the teams we worked with was stuck reaching milestone commitments and deadlines, despite the fact that the team consisted of rock-star employees. We noticed great tension coming from a couple of teammates who crossed the conceptualizer and implementer diagonal axis. The conceptualizer thought that the implementer didn’t respect the creative process and was pushing too hard to converge on a solution too early. The implementer thought the conceptualizer didn’t respect deadlines and the looming milestones that were agreed to at the beginning of the project. Through an open, moderated conversation, each person started to recognize the assumptions and judgments they were making without checking on the accuracy of those assumptions with each other. The end result was that they realized how much they needed each other on the team and how important it was to give space for diverging and exploring possible design directions while also staying aligned with each other on possible schedule impact. The whole team acknowledged a physical change in the energy, and it went on to hit the deadline with a superhot solution.
We found (as the Basadur CPSP model advises) that the greatest conflicts lie between diagonally opposite problem-solving styles. The creative “magic” here is embracing those opposites and leaning in with attunement and respect rather than avoidance or contempt. The overarching goal is not a friction-free team, but one that consistently experiences healthy creative friction. We consistently found that introducing teams to this model and language accelerated the individual and collective creativity and performance.
Semantics matter
Are you a professional designer? Have you ever found that talking to an engineer about your craft was difficult? If so, you are not alone. One thing we learned, very early on, is that with engineers, the words you use matter.
In the very beginning, when we were experimenting with different content, formats, and instructional design patterns, we inherited a workshop titled “User Experience Design for Other Disciplines.” Okay, we confess, it’s a terrible name. As you might expect, the people who were attracted to that name were generally those who were looking to understand the design discipline at Microsoft. Some were considering a career change, and others already knew that they wanted to collaborate better with the designers on their team. But that was a relatively small number of people. And to be honest, the individuals who signed up for that course weren’t the most senior or the most influential people in the company.
Because our desire was to immerse the engineering population at Microsoft into the world of design thinking and user-centered design, we knew we had to somehow reach a different audience. The early feedback we received on the workshop content told us we were heading in the right direction, all we had to do was get the right people interested and motivated to consider change. The content of the workshop wouldn’t matter if we couldn’t get the right people to attend in the first place.
We tested a lot of different names, many of which were some variant of “Design Thinking,” “Design for Engineers,” “User-Centered Design,” and so on. Through those trials we discovered that design means a lot of different things to a lot of different people. We learned that many engineers have an allergic reaction to the word design. Associations such as “artsy, nonproductive, waste of time, and flower-shirted, pot-smoking creatives who are on a different planet and add no value to me” come to mind. Ugh. (And our sincere apologies to anyone reading this who is currently wearing a black turtleneck. Please read on.) What were we to do?
We eventually named the workshop “Scenario-Focused Engineering.” This title proved to be much more acceptable to our audience of leaders and technical engineers. The idea of writing scenarios was enjoying a resurgence at the time, so that made the name naturally interesting. And people’s general reaction to those words tended to be something like “I can guess what a scenario is, and I can see value in using one to drive an engineering project.” The word scenario was something concrete they could immediately understand, with no ambiguity or magical fairy dust. In that way, we found our audience to be open to listening to what we had to say. The SFE title has worked well and has served as a Trojan horse of sorts for the meta-topics of user-centered design and design thinking that we introduce.
The title has also failed us in some ways. Once we put “Scenario-Focused Engineering” on the door, some teams tended to give too much weight to the importance of scenarios in the grand scheme. (We talk about this phenomenon specifically in a previous lesson in this chapter.) We never did find a perfect solution to this particular naming problem.
Another lesson we’ve learned is about the power of aligning a group of people on a shared context and new vocabulary. We learned this fairly early, both on our own team and by watching teams go through the SFE workshop. After the workshop, we would see the new vocabulary begin to emerge in teams. We began to hear words and phrases such as “scenario,” “empathy,” “diverge and converge,” “less is more,” “you are not the customer,” “marinate,” or “let’s iterate one more time” as part of a team’s vernacular. Even teams that did not make dramatic changes to their processes still found tremendous value in the workshop because it normalized terms and created a shared language across their team. The importance of using words to get a team on the same page and communicating more smoothly was evident. The new “language” that teams developed created a sense of tribe among team members and was an important part of establishing a culture around the iterative process that focused on deep customer empathy.
The role of leaders
In our ongoing work with teams, it’s been clear that teams that make the biggest changes are those with strong leadership—with leaders who cared deeply about their customers.
Leaders: What got you here, won’t get you there
Even though the leaders we worked with knew they had to change their behaviors, we witnessed over and over again how hard it was for them to step into a new relationship with their team and nurture a customer-focused, iterative approach. We believe that the root problem is that these leaders have spent many years acting as decision makers. If someone has a question, these leaders are supposed to have the answer. Leaders have probably spent many, many years in the industry. And, in fact, they probably became a leader precisely because they did have some customer empathy, business savvy, and the ability to come up with creative solutions. As we mentioned in the previous chapter, these successful leaders have spent many years living the life of a HiPPO.
And when you live the life of a HiPPO, you get used to people listening to you and doing what you say. The trouble is that if a team truly wants to operate in a customer-focused way, the HiPPO needs to let customer feedback, not his or her personal opinions, drive decisions at many points. The discovery of great solutions is most likely to occur in a trusted group where you encourage crazy ideas, build on the ideas of others, and say the words “Yes, and . . .” a lot. The value of an idea is judged by customer feedback and not by whose idea it is, regardless of whether it comes from the newest hire or the most senior team leader. The customer-focused culture you aspire to gets messed up when a HiPPO is continually asserting his or her opinion, making decisions, and trying to drive the ship in the same way as always.
It’s not that leaders don’t need to make decisions anymore, far from it. A good leader is still responsible for the team’s business strategy and sets crucial guardrails and constraints within which the team must work. Leaders need to focus their team on a small set of target customers and make the bet on which customers and businesses are most lucrative. They may even act as tiebreakers from time to time when several solutions are available that seem equivalent or when a key tradeoff must be made. But for the bulk of the formation of detailed product plans and execution, leaders need to let go and trust in the iterative process. They must trust their team to talk to customers, listen to customer needs, come up with ideas, get feedback on those ideas, and iterate them until customers are delighted. A leader’s role becomes one of coaching the team to ensure that the right steps of due diligence are followed and to hold the team accountable for delivering compelling end-to-end experiences. Leaders need to make the shift from knowing the right answers to knowing which are the right questions.
As former HiPPOs, we can tell you how difficult it is to let go, to think of our personal opinions as being no more and no less valid than anyone else’s on the team, to accept that our instincts in knowing what customers want are not always accurate. Making the transition from being a person who is highly influential in the planning and creation of a product to being a coach, guide, and customer advocate who relentlessly tracks customer feedback and holds the team accountable for delighting the customer is very difficult. The pivotal moment in this change is when a leader realizes that her job is no longer to control the plan but to provide direction and to set the boundaries that enable the team to iterate the plan as quickly and efficiently as possible.
Here are specific areas where leaders have particular trouble or where they make mistakes that hamper their teams:
Allowing early iterations to truly inform product plans proved tricky for many leaders. Some leaders insist that their teams develop complete, final plans before they have really done much iteration. It’s tough for leaders to have the patience to allow a few iterations to happen without having a clear plan. It’s even harder for them to realize that the initial plan might be wrong and might need to change, possibly drastically. While the rational side of your brain knows that it’s better to allow iteration to happen up front—rather than find out much later that you built something no one wants or you have major issues to resolve—it’s tough for leaders to have the patience to last through the ambiguity of the early iterations.
It is also common for leaders to push teams to make decisions too soon, before the customer need and value are clearly articulated and validated with feedback. It’s very difficult for a team to report on the feedback and progress of three solution ideas when the manager is demanding to know exactly what the team is building and becomes frustrated with what seems to be an ambiguous answer.
One of the more unfortunate situations we saw involved leaders who empowered their teams to use a customer-focused, iterative approach but then imposed their own plan when what the team came up with didn’t match what the leaders had expected. This created a huge amount of ill will on the team because it essentially made the customer-focused iteration a sham process that was ultimately ignored or greatly discounted. The lesson learned is “Don’t disempower a team after you empower it.”
Letting go of a completely predictable schedule is one of the hardest cultural shifts that the managers of an Agile team need to make. Managers naturally want to know what you’re going to build, how long it’s going to take, how many people you need to do it, and what the end result is going to look like. We all know that it’s impossible to know all of these things in advance, but still somehow we pretend that we do and make our best guesses, if only to satisfy the boss. The reality, of course, is that there will be plenty of gotchas and mistakes and miscalculations and improvements that need to be dealt with throughout the project. The only question is whether you plan for those up front, allow yourself to be surprised during the course of the project, or feel bad when your first ideas don’t pan out as well as you thought they would. Seasoned managers know this, too: they know full well that the team will never ship what it originally intended to build, and usually leaders are quite happy as long as the biggest, most important investment areas land successfully. The rest is just extra. So stop fooling yourself, and instead of “committing” to a particular plan by a particular day, commit to getting a particular piece of the plan working to a high level of quality before you pick off the next major piece of work. This doesn’t mean that you don’t build a plan. Indeed, a plan is critical so that everyone can coordinate and be rowing in the same direction. But you have to have the humility to believe that your plan is imperfect and to leave space to make adjustments as you iterate.
The lesson learned is that leaders have to change, too, and their shift may be the hardest of all. They need to empower their teams to make decisions and not require teams to run ideas by the boss before they make a decision. They must embrace the iterative process and trust that it will lead to an optimal solution as quickly as humanly possible. You might be able to build a crummy solution faster, but is that really going to get you where you want to go?
You can’t fake a business strategy
We can’t count how many times we’ve talked with a bunch of group managers prior to running a workshop for their teams and found that they can’t clearly articulate who their target customers are or just describe their target customer extremely broadly (“anyone with a computer” or “enterprise customers,” for example). Digging a little deeper, it’s often not entirely clear what their business strategy is either. Or, more likely, they have several reasonable directional ideas but haven’t really done the work to test those ideas with customers or even to take the time to build consensus among the team’s leadership about what direction they should try first. Without a clear strategy, it’s no wonder that they have trouble identifying their target customers and crisply communicating that strategy to their teams.
Later, we’d hear from individuals on these teams that they didn’t know who their target customers were and never got a straight answer when they asked their leaders, so they felt like they couldn’t really use customer-focused approaches. The more industrious team members made up reasonable target customers on their own, thereby creating their own version of a strategic direction in the absence of an official one, which sometimes resulted in several competing customer targets across the team. Members of these teams commonly reported frustration about team politics and disagreement and confusion about what were the most important things to work on and how to make progress. Not having a clear direction certainly does make prioritization very difficult. Decisions become unstable and unwind when someone changes his or her mind or when different people are in the room. These teams eventually build something, but it is painful to watch and not very efficient, and none of the products they ship are particularly outstanding.
How you build a business strategy is outside the scope of this book, and we list several great references in Appendix C that we encourage you to read. But our lesson is that having a clear business strategy isn’t optional; you can’t fake it. A team needs a clear direction to make forward progress in an efficient manner and then either confirm that the direction is viable or to use data to instigate making a change. Leaders need to communicate that direction so that everyone is working toward the same North Star and with a shared mission.
You can’t overcommunicate
Nearly all of the leaders we’ve worked with appreciate the fact that they need to communicate a huge amount of information to their teams as part of the shift to SFE practices. Whether it’s announcing changes to schedules and tools or reinforcing behaviors they wanted to see, there is plenty to talk about. Leaders assured us that they were getting the word out.
However, when we talked to individuals on various teams later, the message we heard was invariably very different. Those folks felt like they still didn’t know what’s going on. They didn’t know who their target customers are, what scenarios had been prioritized, or what they should be working on. In a more severe case, a schedule was created, but substantial portions of the team missed the first deadline because they had no idea there was even a deadline coming up.
When we’ve dug into a few of these situations, leaders were always surprised. They agreed that they could certainly do more to communicate, but they felt as though the major messages had been more than adequately communicated, in some cases multiple times, and didn’t believe that the team felt so uninformed. In fact, leaders worried that they were going to start sounding repetitive, that the team was going to tune them out for saying the same things over and over again. Yet we never heard a single team complain about too much communication, too much repetition, or anything remotely like that. Sometimes, the problem was that the message was delivered only once, maybe in an all-hands meeting or in a long status email. But it often seemed that it was just a matter of not enough repetition, and the simple truth that not everyone reads every single email or attends every meeting.
Leaders who do a better job with communication realize that they need to rally the troops and be cheerleaders, not just relay information. Often they delegate this role to a key lieutenant who is in charge of beating the drum. Some teams create catch phrases or rallying cries. Others clearly articulate the team’s directives or create a short list of principles. The best leaders found regular, predictable ways to get information out, whether through a weekly email, all-hands meetings, or demos at the end of every iteration. These simple, memorable, repetitive messages helped keep people on track and keep the organization’s priorities and key milestones at the top of everyone’s mind.
The lesson we learned is that you can’t overdo communication. Overcommunicate, beat the drum.
The way to convince an executive . . .
How do you convince an executive that design is important? We have tried lots and lots of different approaches. Although some tech companies do have a culture and organizational structure that makes customer-focused design a leadership mantra, many do not. We’ve seen many talented people attempt to push inside their company the notion that design must be at the center and therefore you must place trusted designers at the highest levels of the organization so that they can implement a cultural shift toward design-centricity. That might be a great end goal for some, and may even be a recipe for success, but we have never seen that strategy work unless the top executive has already decided to drive that change.
Brute force and even logic will not work. The bottom line is that the leader who is going to drive change must have a sense of urgency that the long-term business is not as healthy as previously thought or that there is tremendous additional value that can be captured ahead of the competition. In class, we are very careful to frame the changes needed for customer focus as one leg of a stool. The other legs that you need are business and technology. So changing to a customer-focused approach is not about losing any of those existing assets or skills but about expanding your skills in developing team-wide customer empathy and then using that empathy to create compelling end-to-end customer experiences.
If you see advantages for your team in embracing some of the principles in this book, yet your leadership doesn’t see it that way, is resisting, or is unwilling to change, here are a few things you can try. There’s no single recipe for success, at least that we’ve been able to discover, but we have had a lot of success working with executives by using different combinations of these strategies.
Experiential approach
The best way to get someone to appreciate the power and potential of a good design process is to let them experience it firsthand. Among other institutions, the d.school at Stanford University has an excellent executive-education program that teaches professionals the techniques and values of design thinking using an experiential approach.
There are a number of interesting exercises that your team can do with a professional facilitator or just on its own. The “wallet” exercise provides an introduction to design thinking and is used at the Stanford d.school to experience how paper prototyping a new wallet for a colleague can be a productive approach for a difficult task.2 The “marshmallow tower” challenge is another exercise used to help teams quickly experience the process of creativity and innovation.3 In this exercise, teams are given a limited amount of time to build the tallest tower they can using only marshmallows, tape, string, and spaghetti. Invariably, the team that builds the tallest tower is usually the one that brainstorms, collaborates, prototypes, and iterates over many options.
The biggest blocking issue with these experiential approaches is the amount of time they require. From the point of view of an executive (who in this case is your customer, right?), these hands-on experiences are costly in terms of time, requiring anywhere from a half-day to a week. To take this much time out for something that is foreign and unproven (to them) is often a deal breaker. If it’s improbable that you’ll be able to convince an executive to invest this much time, perhaps you can identify a trusted lieutenant who can instead.
Recruit the trusted lieutenant
If you can identify someone who the executive trusts, it’s usually easier to get this person’s time and attention to turn him or her into a champion of design thinking. Often, these lieutenants are on the lookout for new and interesting ways to advance the business and their own careers, and they may be more motivated to take the time to hear what you have to say and perhaps even to attend an experiential workshop. The advice of a trusted lieutenant is a powerful way to build buy-in. It’s even better if you can find several.
Start from the bottom up
One of the reasons the SFE workshop was adopted by so many teams at Microsoft is that we used a grassroots approach. The general pattern we followed was to first hold an open enrollment class, available to anyone. From that class, future champions would emerge. These were passionate people (albeit not particularly senior in the organizational hierarchy) who became enamored with the concepts we presented and who wanted to help their teams make a difference. They asked us if we would be willing to give the workshop to just their team. Our answer was always yes . . . but we told them that they first had to work from inside their team to develop the desire and sense of urgency up through the leadership ranks. We might offer to meet with a few other champions to help build a base of support in that team. Eventually, we would receive an email message several weeks or months later saying that the triad (program management, test, and development leaders) would like to speak to us about the SFE workshop and whether it would be appropriate for their team. During that first leadership meeting, we gave an overview of SFE and the key challenges of adopting it. For large teams, we arranged for team leaders to attend a half-day or full-day experiential workshop. In this way, the leadership team had the opportunity not only to learn about and experience Scenario-Focused Engineering but also to discuss which principles were more or less important for their team and to give us guidance so that we could customize the workshop to fit the team’s specific needs. This leadership workshop was an essential way for leaders to be exposed to the depth of these ideas, get hands-on experience, and create consensus among the group of team leaders for how to move forward.
Data approach
Many executives respond well to data. They want to see proof that there is a favorable cost vs. benefit and ROI for whatever you are proposing. To be brutally honest, we never had great success with this approach. We were never able to put together the killer data set that categorically proved to an analytical person that if you embrace customer focus and iterative techniques, you will be better off. We showed some analyses that correlated companies known for good design with stock prices, revenue, or market share. But correlation isn’t causation, there are always counter examples, and an analytical person can always poke holes in the data or the conclusions.
That said, we never went into a meeting with an executive without an ample supply of backup data. We just wouldn’t necessarily start with the data, nor would we rely on the data to be the convincing factor. It just never worked for us.
Defog the vanity metrics
Data did help, however, when either us (or, more likely, the champion who had been working on the team) presented data about that specific team, its customers, market-place, and competitors. The idea is to defog any and all vanity data that tells everyone how great the team is doing. The revenue, sales, and even survey data might all look quite positive. But show the leaders a multimedia presentation with their own customers displaying frustration, anger, or annoyance with their product, and then contrast that with customers showing love and loyalty for a competitor, and you may get some attention. In Chapter 1, “Why delight matters,” we talked about how in the team workshop we spend a good amount of time having participants list products they love and discuss why that is so. And then, in stark contrast, we have the room discuss “What are people saying about your product?” For many, that discussion creates an aha moment.
Read a book
We’ve seen executives become curious and have a strong thirst for understanding why it is that some companies tend to continually design great stuff for their customers. Many will do their own research and reading. If you have the opportunity, you may be able to recommend one or two books that you find relevant to your team and situation. When Tim Brown’s book Design for Change was first published, we gladly gave it to any leader who showed interest. We encountered some executives who read the recent biography of Steve Jobs to better understand the magic of Apple. A new book that we are recommending lately is Outside In by Harley Manning and Kerry Bodine.
And, of course, there is this book. Obviously, it hadn’t been written when we developed the SFE workshop. But maybe it will be helpful for some. Part I is designed to be approachable as a quick introduction.
Just do it
We’ve discovered that grassroots efforts can go a long way. If you don’t or can’t get top-down support from leadership, do what you can at your own job and level. Pick some of the techniques in this book and use them. Enlist the two or three people you work most closely with. When you are successful, others will notice and want to follow. Of course, you are a bit limited alone. You can’t get an entire engineering team to build prototypes and iterate quickly if they haven’t bought in to everything involved. And you may need to be creative about how you manage your schedule. But it’s certainly possible for you to quickly draw sketches and ask teammates opinions before committing to details. You can certainly raise your hand in a meeting and simply ask, “Why are we building that? Is there a customer in mind or a particular need that is being solved? Oh, really? Would it be okay if we took a few minutes to quickly see whether we can think of any other possible options?” Or you can go into the world to collect some qualitative and quantitative data on your customer. That data is often very interesting for a team, and once it exists, people will be curious. Share and keep referring back to that data to help drive daily decisions around you. Many have found that one of the easiest and most meaningful techniques to start using is to write a scenario describing a crucial customer problem, sketch a few storyboards, and use those as a tool to influence and align partner teams without getting into the weeds of arguing on implementation details.
Vote with your feet
This may not be practical for many people, and it is a last resort. But if you are deeply passionate about focusing on the customer, feel that your team and leadership have a different view, and are failing to lead them to a more customer-centered view, you always have the option to leave for a team with the same values and ideas about business, customers, and product development that you do. After all, business is business. Some succeed and many fail. If you discover that you are not on what you perceive to be a winning team, and you cannot affect the changes to make it a winning team, go find a winning team and join it. Everyone will be happier.
Managing change
Change is hard. We were often humbled by that fact. Here are some things we’ve learned about change.
Teams with sustained focus from leaders make bigger changes
Teams that have passionate, sustained, long-term support from their leaders are the ones that make the biggest changes, with broad adoption and large-scale changes to their culture. We figured out right away, when we started teaching teams, that team leaders needed to deeply understand and accept SFE ideas for a team to get anywhere. We learned over time that an initial burst of passion and buy-in was not really the important part. The teams that made the biggest leaps in their practices did so because their top leaders, often a vice president, director, or general manager, had strong conviction and drive about leading the team through this shift, and they sustained that focus over years, not just weeks or even months. They had long-term plans that counted on this shift and were able to create a sense of urgency on their teams that this shift was essential and must happen now. They proved the old adage that “you get what you measure,” and used metrics, project reviews, and a focus on scenarios to keep their teams focused.
The best leaders reiterated their goals and expectations in nearly every communication—in email, at all-hands meetings, in project reviews, in one-on-one conversations with their direct reports—and they formalized those expectations in the schedule, in team goals, and in personnel review criteria. They kept their focus on the changes they wanted to see, kept it at the top of their mind, and they held the team accountable and gave it feedback when they saw behavior that wasn’t aligned with their expectations. Leaders changed their own behavior in project reviews and other interactions with the team to ensure that they were practicing what they preached. When things got tough or there were bumps in the road, these leaders didn’t abandon their goals. Instead, they helped the team see a setback as valuable learning on the journey and encouraged the team to iterate and keep at it. Most importantly, they were not distracted from their top-line goals by the next shiny object, whether it was a competitive wrinkle, a new technology, or less-than-glowing customer feedback on their latest iteration. Leadership focus on customers and iteration continued alongside whatever else was happening in the landscape. Leaders who did these things rocked it, and the results showed.
On the other hand, a few leaders we worked with treated the workshop day more as a fun “morale event”—after all, the workshop got rave reviews, was highly interactive, and had teams brainstorming and developing ideas based directly on the team’s own target customers. Heck, their team might even come up with a breakthrough product idea right in class! These leaders believed the ideas we taught were all goodness, motherhood, and apple pie and wanted to expose their teams, hoping that some of it would rub off. Some leaders had the impression that their teams already worked this way, which was true some of the time, and saw the class mostly as a refresher. Overall, they thought that maybe their team would pick up and adopt some good changes, and the workshop certainly wouldn’t do any harm. Unsurprisingly, what actually happened in these cases was that a team would see some incremental benefits, but their leader did not have huge expectations, so this was perceived as a successful outcome for many of them.
For only a couple of teams did their leaders truly not understand what customer-focused iteration was about, despite a conversation we held with them ahead of the training day. Those workshop days were painful—for instructors, for leaders, and for their teams—as the depth of the disconnects surfaced and became obvious to everyone over the course of the day’s discussions. In those cases, we probably did more harm than good—stirring up a team to start thinking differently about how it went about building products—because its leadership had no intention to change their approach at all.
For the majority of teams, the top-level leaders had passion and a strong desire for driving a customer-focused change on their teams. They made the time and effort needed to take their management team through a special “leadership edition” of the SFE workshop a priority, and they supported the underlying principles we presented. They supported (and paid for) their entire team to go through the workshop. But problems came up weeks or months later, when those high-level leaders moved on to other urgent issues and stopped visibly following through on the changes they had initiated. In their minds, they had set the direction, delegated the responsibility for team-wide change to their middle-level managers, and assumed all was well. In these situations, it became difficult for the middle-level managers to drive change because the team did not see support for change coming from the top. The top leaders on these teams were the most disappointed: they had assumed big change was underway and were let down when they realized that the actual changes were smaller and slower than they had hoped for. They had underestimated the difficulty of change.
The bottom line is that sustained leadership, clear expectations, constant communication, and changing the way success is measured are major factors for successfully leading a team through this change. It takes a lot longer than you think to overcome old habits, and both managers and individuals need ongoing, clear signals from leadership that the effort and anxiety inherent in changing things is going to be worth it. If the leadership team isn’t fully committed to adopting these ideas, the large-scale, long-term change you may be hoping for is not going to happen.
Middle managers are the hardest to bring onboard
It wasn’t especially hard to convince rank-and-file members of each team to give Scenario-Focused Engineering a try. We quickly became pretty good at taking a room of (sometimes) skeptical engineers to the point where they could see that making changes might help them make better products.
It also wasn’t that difficult to show the value of customer-focused practices to higher-level leaders. They tend to take a longer-term, strategic view of their products and business and saw the inherent value of getting closer to customers and using customer feedback to fuel creativity. Most already understood the customer-focused, iterative approach intuitively.
We noticed, however, that group managers (middle managers) had the most difficult time seeing the value of SFE. To be more precise, they had difficulty seeing the value with enough confidence to outweigh the inherent risk of change. After all, they were being asked to consider changing the processes, tooling, and culture of their team. That’s a lot of change, and that made them weigh the risks very carefully. Change can be difficult and scary.
We realized that middle managers had the most to lose. They are the ones who feel responsible for executing the changes that are explored in the workshop. For them, embracing the iterative patterns of SFE represents a difficult and risky proposition, and if it didn’t work and they still didn’t deliver the right product on time, they were accountable. We found three important factors that helped middle managers get onboard:
Leader support Middle managers need confidence that their own manager believes in these ideas and genuinely wants them to pursue changes to build products that resonate more deeply with customers. They need to know that if they make some dramatic changes in how the team goes about building products, that those changes will be rewarded and not punished, even if results are not obvious right away. Without hearing a strong message from their management, and without support and encouragement from key players on their team, middle managers are incented to keep up the status quo and not make any real changes. It’s essential to ensure visible buy-in and support from higher-level leaders.
Active buy-in It’s not enough for high-level leaders to buy in and dictate that the team should adopt these ideas; team managers need to buy in as well. We began to require a preworkshop session with each team’s set of group managers at which we presented the high-level concepts of the workshop and what would be required of them to make changes successfully. At the end of this session we asked them to make an informed go/no-go decision regarding the rollout of the workshop to their team. These manager meetings became a critical part of the rollout of the team workshop because they gave managers time to think about the concepts and make a conscious, active decision to move forward (or not). In fact, we learned this lesson so strongly that we refused to schedule a workshop for a team until we had a preworkshop meeting, the middle managers had actually shown up, and they agreed to support and participate in the workshop with their teams. Further, we made it a practice during the workshop to have one of these managers stand up about 45 minutes into the workshop and explain to the team why they have asked everyone to spend their valuable time with us on that day. (Why not have the managers kick-off the workshop? Because as many as 20 percent of attendees arrive a few minutes late, and it is much more important that everyone hear from their manager than from us.)
Support them with champions Passionate champions were important in helping managers continue to see the value and need for change. These champions were typically highly respected individual contributors (perhaps an architect, a strong program manager, or a particularly influential developer). We supported these champions closely, and through these relationships we saw a healthy tension between the risk-averse middle managers, who were faced with executing change, and the optimistic influencers, who were able to rally the team around the value of customer-focused iteration and figure out how to make process changes happen.
Harness champions as change agents
Even when leadership support wasn’t crystal clear, passionate champions were a powerful force for change. Almost all teams had champions with fire in their belly that deeply believed in customer-focused iteration and were driven to do whatever it took to get their team using these tools. Sometimes they were experts in some aspect of the process or a specific technique, but often they were just passionate people with a bent toward being change agents, eager to learn and figure it out on the fly.
Champions are needed to figure out the pragmatic steps for adoption: which techniques should be used by the team, what’s mandatory and what’s optional, and what are the implications for team systems such as schedules, tools, and processes. For this reason, we sometimes call these champions operationalizers, because they take charge of figuring out the practical details of how to operationalize Scenario-Focused Engineering on their teams.
The champion role is ideally served by an individual who is senior enough to have the trust and respect of top leaders and with sufficient authority to make decisions stick. Yet, they also need to be close enough to team members doing the work to understand the realities of day-to-day activities. They act as a critical liaison, translating the desires of leadership into an actionable plan for the rest of the team. They might have a formal leadership role, such as a lead or a manager on the team, or they may be an individual contributor who acts as a thought leader.
Often, champions provide the impetus that encourages top-level leaders to continue talking about customer-focused iteration after the workshop. They feed them key ideas to reinforce with the team as they see needs arise in their interactions with the team. Champions are particularly effective when they have a close relationship with their leaders and are also often pivotal in helping a team decide to sign up for the workshop in the first place. The best champions have a touch of salesperson in them—a dynamic personality that’s fearless—as well as patience and a willingness to keep working with reluctant individuals or skeptics until they come around.
On some teams, this role is served by a single individual. On other teams, usually larger organizations, a group of people work collaboratively to coordinate and encourage changes across different parts of the team. Either way, these folks are essential for understanding the specifics of adopting this approach, for adapting it to their team, for helping explain these ideas in detail to all the members of the team, and for beating the drum to keep communication going and to keep people moving.
We’ve found that every organization already has change agents who are ready to go above and beyond for a cause they believe in. They fall into a few different categories. First, not all of them have the authority or depth of experience needed to be successful in their ambitions; these people are most effective when they are paired with a more senior person and can act as a powerful duo. Some have a lot of motivation but not a ton of direct experience with these new techniques, so while their learning curve is steep, their passion usually makes up for this, and they are still quite effective.
Some teams have passionate change agents in place who have been attempting to stimulate similar changes for years or are already deep believers in the tenets of a customer-focused, iterative approach. Some of these people have successfully gathered an enclave of like-minded individuals and are the thought leaders behind enormously successful teams or subteams, sometimes opting to fly under the radar or who call their approach the team’s secret sauce. Other times these change agents have been frustrated, knowing what the team should be doing, but finding their attempts to influence reduced to tilting at windmills, feeling powerless to affect the depth of change they know is needed. Either way, these individuals are critical to identify and harness if broad, team-wide adoption of these ideas is to be successful.
In particular, we’ve learned that it is essential to identify these people when we first start working with a team and to bring them into the conversation early. After all, they have already been down this road and have experience on this specific team about which approaches work and which don’t, what the roadblocks might be, and all of the intricacies of the team’s existing culture, processes, and tools.
We learned this lesson the hard way. One of the first large organizations we worked with started by bringing its entire executive leadership team through a full workshop. They liked what they experienced and then asked us to start bringing their individual engineering teams through workshops. From our perspective, this seemed like a great start, with strong leadership support leading the way.
But from the perspective of the change agents already on the teams, this didn’t look rosy at all. Think about it from the perspective of a person who has already been independently driving a very similar agenda. They start asking themselves, “Doesn’t our leadership know that we’ve already been pushing these ideas for years? Is this a not-so-subtle hint that we’ve been doing it wrong? Or is this confirmation that we’re just not very effective? Why didn’t they ask us to lead this training instead? We know just as much, more in some cases, than these people they’re bringing in.”
Sure enough, many of the existing change agents became upset and angry, and some even started campaigning against the need for training or for team change. But once they attended the workshop, the majority realized that we were all aiming at the same goal, although they still had some pretty ruffled feathers. And these were the people who should have been the strongest supporters and the biggest assets on the team for figuring out how to put these ideas into practice on a team-wide scale. Yipes!
This lesson deeply informed our engagements with future teams. We’ve made sure that we always identify and include a team’s natural champions from the beginning so that they fully buy in and can help direct and focus the change process for the team. Champions have ended up being instrumental in customizing the customer data used in the workshop as well as contributing and fine-tuning the workshop topics. Several were invited to serve as coaches during the training day itself to help answer questions in a visible leadership role. All of this adds up to making the training day that much more effective for a team. But, more important, it harnesses the passion and motivation of change agents to become visible, empowered champions for driving change throughout the team in the weeks and months afterward.
There is a limit to what champions can do on their own, however. When big conflicts come up—perhaps a more significant schedule change is proposed, or a long-standing process needs to be adjusted, or the need for a well-articulated target customer is questioned—sometimes even the most passionate champions hit the wall in what they are able to accomplish. As we discussed earlier, without visible, sustained support from top leadership, teams become confused about whether making the shift to customer-focused iteration is still a priority, especially as people begin to realize the more challenging implications of what needs to change.
You can’t grow a foot overnight
We’ve developed a deep appreciation for how long it takes to shift behaviors, team culture, tools, systems, and institutionalized ideas about how to get things done. We’ve known from the beginning that this was going to be a long journey for teams we’ve worked with, but we have been surprised at the depth of the implications that stem from implementing these seemingly straightforward ideas and how long it takes to build these skills and mindsets on a team. Leaders and managers consistently underestimate what it takes to start working this way.
Early on, we noticed that many teams had unrealistic expectations about how much change would occur, how long the change would take, and how quickly they would see results in the quality of the products they shipped. The more passionate champions tended to downplay the magnitude of change needed and to be bullish about the team’s ability to snap to a new way of doing things.
Looking back, as we’ve watched teams go through this transition, they’ve grown a lot more slowly than they (or we) expected. We’ve learned and observed that old habits die hard and that change takes a lot of work and sustained effort. Teams hoped to be proficient and comfortable with these new techniques by the time they started their next release cycle, but the reality is that several major release cycles were needed to make enough of the transition that the teams began to see clear results from this new way of working.
Appendix A details a list of the 10 most important capabilities we’ve identified as being central to adopting Scenario-Focused Engineering. We didn’t see any team become good at all 10 capabilities at once—most teams followed a path through a set of stages.
SFE in action: One step at a time
Erin Chapple, Partner Group Program Manager, Microsoft Windows Server
In the technology industry it is not surprising to find people who are very passionate about technology. The defining aspects of engineers are often a combination of the passion for their domain, their pride in contributing to the industry, and their desire to deliver innovation to our customers. To deliver first-class, customer-focused products, the challenge is how to channel an engineer’s passion, pride, and desire toward the customer. By focusing on specific customers and scenarios rather than on a collection of technologies or features, a product transforms into solutions that address real customer challenges. Over the last several releases, our team has been on a journey toward realizing this Scenario-Focused Engineering approach.
As part of the multiyear journey to embrace the principles of SFE, the team has unde-gone dramatic changes, both culturally and in our processes. In hindsight, while the changes seem to have taken longer than I would have expected when we began, given the size of the team (more than 1,000 engineers) and the size and complexity of the codebase (more than 25 distinct technology areas), we are actually quite happy with the consistent movement toward customers the team has achieved. At the beginning of this journey, we were perhaps a bit naïve, thinking that within a few months, or certainly by the end of our first release, the team would have transformed into a well-oiled, customer-focused machine. But in reality, that change has taken several releases and has followed a pattern that I believe is worthwhile describing here.
Step one: Pivoting from technology planning to scenario planning
The first step was to transform the way in which we planned. Historically each technology team would plan in relative isolation. They are the experts in their technology. They understand what was delivered in the last release, where the industry is going, how customers are using their technology, and from this they could easily create the next set of features to enable in the product. Often, this list was in part features that spilled over from the last release and in part new functionality. The end result was a solid plan for how to evolve the technology itself. What it lacked, however, was a focus on how the customer would use the technology. What was the end-to-end deployment experience? Operationally, what was the experience? Our first step in channeling the engineering passion was to define scenarios that captured the problems that our customers faced and the experience we could provide that would delight them with the next version of the product. This resulted in a plan focused on both the experience and the underlying features necessary to enable it. So we were done, right?
Step two: Extending scenario planning into scenario execution
While our plan improved dramatically, the end product did not. The challenge was that as we moved from planning to execution, the pull of the technology was simply too strong for our existing processes. We had the scenarios defined and in focus, but as development moved into full swing, the engineers fell back to talking about the features and the validation plan was focused on functionality and not scenarios. The second step in our journey was to put in place the necessary process to ensure that the scenarios were front and center throughout the development life cycle. Our regular project reviews ensured that we were reviewing the status of the scenarios. Our customer validation plans involved getting the customers to deploy scenarios and provide feedback. Our internal validation efforts focused around success metrics for scenarios. Because the organization was truly going through a cultural change, the focus on keeping scenarios front and center was critical in preventing the default wiring from kicking in and returning focus to the technology. So we were done, right?
Step three: Getting the scenarios right
While the product we delivered was by far the most customer-centric to date, the end product still seemed to be missing something. Upon reflection, we realized that the way we were planning was largely based on the original technology teams. While these teams were important internally for how we delivered the product, the customer didn’t make these distinctions in their usage of the product. Each technology area had become more customer-centric, but we were still falling short on the scenarios that customers wanted to enable. The third step was to break out of our technology areas and think more from the point of view of why customers buy the product and what they want to enable. This meant that both planning and execution needed to happen across technology areas. This was a huge shift for the team, but given the foundation we had laid in the previous releases, teams now had more of a scenario mindset, and creating virtual scenario teams to define and then track the progress of development was a logical extension of how we had worked in the previous release.
At this point in our journey toward using Scenario-Focused Engineering, I believe we have started to realize the benefits of the approach. Our product is no longer defined by the technologies within it but by what scenarios it enables for our customers. I do not believe we would have reached this point had we not focused on the first step toward making this shift, reflected and learned from the results, and then refocused on the next step. We will continue this approach with the goal of always increasing the end result—a first-class, customer-centric product.
Pilot with a small team first
Several teams have found that piloting with a small “tiger” team is a great way to get started, gain familiarity with these ideas, and see how they land in their own environment. This approach is surprisingly productive and has lots of benefits:
Safe A pilot team can try things out in a contained environment, where it can fail without the risk of hurting larger business priorities.
Focused On a small pilot project, leaders have the ability to minimize the surface area of issues the team needs to deal with. A leader might even choose to protect the pilot team from some of the real-world problems that can arise on “normal” projects, such as resourcing, dependencies, firefighting, and (to some extent) the time pressure to deliver.
Experiential learning Pilot projects allow teams to gain experience in the practicalities of meeting with customers, iterating, prototyping, scheduling, and so on, and to develop a visceral, firsthand understanding of how these activities play out in the team’s domain.
Inform broader adoption The pilot team can not only try out these new approaches but also translate how they will work with the team’s existing tools and processes. Through this, the pilot team ends up developing a set of standards and examples that the broader team can reference and adopt, which makes for a smoother rollout to the larger team.
Confidence Seeing a pilot team succeed helps build confidence that these ideas will work for the larger team.
Build a stable of experts Finally, when it comes time for the larger team to adopt the Fast Feedback Cycle, a crew of well-informed and practiced champions will be in place ready to help. For this reason, it’s worth being mindful when a pilot team is set up to choose people who will make good coaches later on.
For a variety of reasons, small pilot teams tend to perform extremely well. Perhaps they are more motivated because they feel like an A team. Or maybe it’s just fun working on a team that is isolated from some of the issues of the daily grind. Small teams do tend to have an easier time building team-wide customer empathy, aligning on goals and success metrics, and developing a collaborative approach. Even when pilot teams have an extremely short time frame to operate in (one standout was a single “two week experiment”), they serve as a very helpful bridge toward a broader team rollout.
The change is bigger than you think
All the teams we’ve worked with have grossly underestimated the depth of change needed to adopt Scenario-Focused Engineering and how tightly wound they were in their habits, systems, tools, and processes. Cultural and attitudinal shifts are equally massive. They challenge core values about the “best ways” to do things, unwritten rules about how decisions are made, and other deeply held values and beliefs. Changing the engineering approach isn’t only about changing the upfront design process. It affects every person on the team in every role, imposing new demands and expectations from leaders and managers. Even teams that are committed from the get-go remark that adopting these ideas takes longer and is more challenging than they had anticipated.
Months, or sometimes even years, afterward, we would check in with teams and hear back that putting these ideas into practice was much, much harder than they had thought. They had tried to make a big change, but only a few smaller aspects really stuck, or adoption was spotty, with some teams or subteams really getting great value from the approach, but others running into roadblocks and eventually settling back into old habits. Some managers were big believers, others were on the fence, and, unsurprisingly, their teams followed suit.
Mindshift
Learn the science of change management. People have studied the science behind driving change across large organizations (called “change management”) for decades. Notably, pretty much every expert says that the vast majority of attempts to introduce change into an organization fail—as often as 95 percent of the time. Over the years we have developed a strong appreciation for John Kotter’s work on the science of leading change in organizations. His eight-step model for leading change rings true with our experience, especially the need to establish a sense of urgency for change. We encourage you to read somebooks on this topic listed in Appendix C. Getting groups of people to collectively shift their behavior is dramatically harder than changing one person, and there is science and experience that you can use. There are lots of identifiable patterns and gotchas to know about. It’s highly advised that you learn about them or risk learning the hard way.
If change is so hard, is it worth all the trouble? We believe that if you embrace these changes in a way that fits your team and business, you will see a high return on the investment over the long term. The promise is that you will deliver products that delight your customers, and we have seen that happen many, many times. But what may not be as obvious is what happens to the culture of a team that effectively aligns on its customer. Working on such a team is infectious. It is gratifying to see customers respond to your work mere days after you’ve created it. Making lightning-fast progress through rapid iterations is exhilarating. Working this way is fun, it is highly productive, it creates a strong sense among team members that their work really matters, and you deliver products that your customers truly love. Once you’ve experienced it, you’ll never want to go back.
A call to action
Matt Kotler, Principal Group Program Manager, Microsoft Office
Congratulations! You are pages from finishing this book. If you picked up this book in the first place, you are probably already hooked on the idea of designing products that your customers love. And within these pages, I hope you’ve collected a set of tools that will help you tremendously along the way.
Either that or you are one of those people who likes to skip to the last chapter. No matter. This is really only the beginning. The hard work is ahead and, as they say, we’ve left that as an exercise for the reader. Your challenge is to take the tools and ideas presented throughout this book and apply them within your organization.
I have had the privilege to spend many years working with Austina, Drew, and many of the other people who contributed to this book (and countless others behind the scenes) to apply this shift in mindset to teams across Microsoft. If you have used a Microsoft product in the last several years, I hope you have been delighted by the experience. Unfortunately, it is possible that at some point over this same period one of our products disappointed you. Every day we work to ensure that that doesn’t happen.
Scenario-Focused Engineering is a journey, and delivering amazing products doesn’t happen overnight. Leading change across your organization and, just as important, to your organization’s culture will take longer than you expect and certainly longer than you would wish. And even when you think you are making progress, a long road will lie ahead. Here are a few additional tips—a call to action—if you want to create a better organization in order to create better, transformative experiences for your customers.
Drive culture change, not process change
For some, especially for those of us who are engineers, it is tempting to read the chapters of this book and want to turn them into a recipe. At first, we tried to do just that. But the reality of design is that it is messy. A surprising amount of science can be applied to creating, evaluating, and delivering great designs, but at the end of the day, design is an art form that can’t be broken down into a specific set of steps.
Take the tools from this book and experiment. Try them out and see how they work. Adapt them to your specific situation. But don’t worry about applying every tool to every situation. You don’t have to do it all to get good results. Instead, focus your energy on ensuring that cultural change is happening around you, that people are doing things with the right intent in mind.
If you are ready to take on the challenge of rolling this out across your organization, you may be about ready to find another book to read. Take a look at the references at the end of this book, especially the ones about driving culture change.
I would highlight three areas, already described in much greater depth in this book, that are at the essence of the Scenario-Focused Engineering culture shift. With every team I join and every project I work on, I focus on reinforcing these three areas over and over again:
Customer focus Never lose sight of the customer for whom you are designing your product or experience. And don’t forget that you are not that customer. Even if you fit all of the demographic characteristics, the fact that you have been designing the product means that you already know all the answers, and it is extremely hard to step back and bring a fresh pair of eyes to look at your own designs every day.
End-to-end thinking Keep stepping back to look at what you are designing as a piece of a much greater whole. In design parlance, we have moved from a focus on feature design to experience design to—these days—service design. What is the experience that spans communicating why a user needs your product, the purchase of the product, long-term use and enjoyment of the product, and the end of your product’s life?
Pride in craftsmanship Sweat the details. This is true all along the way, from ideation to first concept, but it is even more important at the very end. A great product can turn into a terrible product that is never used if it isn’t delivered with high quality. And I believe the difference between a good product and a delightful product is hugely dependent on the final fit and finish. These are often the issues that are not fixed. “We’ll get to them next time,” but next time never comes around because of other priorities. Get it right the first time.
Customize Scenario-Focused Engineering to your organization
Every organization is different. What worked for us at Microsoft may not work in your organization. Similarly, things that we tried that didn’t work because of our scale, culture, and even the type of experiences that we deliver may prove to be breakthroughs in your environment.
Don’t even think about throwing out everything your organization does and replacing it with the tools and methodology described within these pages. Use the best of the tools, processes, and mindsets that you already have to build on. The culture change that I’ve described will be much easier if you can fold it into how your team or organization already works. You might just pick two to three things that you want to focus on for a period of time.
This chapter discusses the importance of driving change top-down and bottom-up. In fact, make sure that you are looking at all levels of your organization and identifying key influencers and key partners. Again, this will vary based on your organization. If you can get buy-in from a leader at the top, that may be critical to making the changes you need.
One of our senior vice presidents asked to have a regular meeting to review a scorecard of the most important scenarios that the organization was focused on. There were endless debates and an evolution of what scenarios to include, and more importantly what scenarios not to include. There were even more debates on how to measure each of the scenarios. A key part of driving culture change was getting the organization to embrace the fact that “red” on a scorecard was okay. At the end of the day, the meeting was not the target. The meeting forced a set of hard discussions at every level of the organization and was a key to getting the culture change to happen.
In organizations where there isn’t support at the highest levels, you can still be successful in building a grassroots movement that has a huge impact on your customers. But don’t forget about middle management. If you can get middle management onboard with the culture change that you want to drive (or, even better, if you are middle management), you will have a much better chance of influencing the people above you, the people below you, and all of their peers.
Also, don’t forget to make use of the skills and perspectives from across your entire organization, depending on the size and role specialization. If you are an engineer and lucky enough to have a design and design research (or user research) team, they have years of training in most of the topics described in this book. If you are a designer or a design researcher, go find your kindred spirits in engineering.
Finally, and maybe most importantly, don’t forget to apply what you learned in this book to rolling out Scenario-Focused Engineering in your team. Who is the customer? In this case, your team and your organization. How do you get to deliver great experiences that customers love? Iteration. Iterate on the process. Experiment and try new things.
Even as this book was going to press, we tried to cram in new things we had learned. Maybe you find that writing a SPICIER scenario is great for your organization. Or maybe there is a better way to frame the problem. In certain groups we now use scenarios alongside a short list of jobs that the product or experience is meant to accomplish with specific metrics that we can map to how well we need to deliver on those jobs to exceed user expectations. By the time you pick up this book, we will probably have evolved our thinking and best practices even more. Look for ways to evolve the concepts within this book and adapt them based on you and your team.
Be patient and don’t give up
Creating experiences that customers love is very hard work. Changing the culture of an organization to be successful at creating experiences that customers love is just as hard, if not harder.
When we started working on rolling out Scenario-Focused Engineering across a large organization at Microsoft, we started with a team self-evaluation. This was a self-assessment for a group of leaders to rate how mature they were in becoming a Scenario-Focused Engineering organization. It was a 5-point scale. There was general consensus that the team was fairly mature in many ways with respect to designing for customers, but we rated ourselves at about a 2 to 2.5 on the scale. A couple of years later I gave a talk on lessons learned within our team and we rated ourselves about a 3.5.
Over those few years we had presented the workshop to thousands of employees and driven a shift in the organization. Teams were more focused on their customers, more focused on end-to-end thinking, and there was significantly more focus on the details. We had a lot to celebrate. But at the same time we had (and continue to have) work to be done.
This is not meant to scare you away from this journey. This is meant to simply communicate that this is a long path. I can say personally that being a small part of the culture change at Microsoft has been one of the most rewarding parts of my career. If you take this one step at a time, I hope that you will also find the same rewards. If you do nothing but improve how you personally design a customer experience, you have made a difference for your customers. If you can bring your team along, then you start to have an exponential impact.
Along the way, look for people to help. I mentioned the opportunity to work with so many folks across Microsoft, many who contributed to this book, and many more who contributed to this effort. These individuals were more than a group passionate about driving this change at Microsoft. They were a support network. We’ve bounced ideas and challenges off one another. We’ve leaned on one another when it looked like we weren’t making any progress or when it felt like progress was glacially slow. Find your own support system. Find those people who are as passionate about delighting customers as you are. Heck, buy them a copy of this book or at least lend them yours. Say “Yes, and . . .” a lot. Keep learning. Be patient and enjoy the journey. And most importantly . . .
Go forth and delight!
Notes
1. John Kotter, Accelerate: Building Strategic Agility for a Faster-Moving World (Boston: Harvard Business Review Press, 2014).
2. “The Wallet Project,” Design Resources, last updated October 10, 2013, https://dschool.stanford.edu/groups/designresources/wiki/4dbb2/The_Wallet_Project.html.
3. “The Marshmallow Challenge,” http://marshmallowchallenge.com.