Scenario-Focused Engineering (2014)
Part II: The Fast Feedback Cycle
Chapter 6. Framing the problem
You leave the Observe stage with a short list of insights about your customers, as well as with lots of data about their habits, preferences, pain points, and desires. Many things you learned in your research naturally point to opportunities for surprising and delighting your customers by solving their unmet needs. Chances are that you uncovered many more possibilities than you have time to address in your current project timeline. You now need to make some decisions about which opportunities you’ll pursue first.
In the Frame stage, you formalize the insights you discovered about your customers and capture that information in a way that can be used by the entire team throughout the development process. In doing so, you prioritize which customer problems and opportunities you’re going to focus on. We call this framing the problem, and our favorite technique for framing these opportunities is to write scenarios, or real-world stories, about the target customers. By including quantifiable metrics in the scenarios you develop, you ensure that you have measurable goals that can be tracked during the entire project life cycle.
Vocab
A scenario is a story that introduces the target customer, describes a real situation in which the customer has a need, explains why that need is important, and articulates what qualities a good solution would have—but without saying anything about exactly how that solution would work.
While the target customer serves as your North Star, a prioritized list of scenarios provides the map that the team uses to navigate its way through the solution development process toward your North Star. Throughout the project, as you iterate through the Fast Feedback Cycle, you will continually refer to this map to ensure that you’re solving the problems you originally set out to address.
Articulate the problem you want to solve
The crucial first step in solving a problem is to figure out exactly what problem you are going to solve—you need to frame the problem.
Vocab
Framing describes a problem or opportunity clearly so that the people involved have a similar understanding of the problem that needs to be solved.
Here’s an analogy. Think about taking a picture or, better yet, filming a movie. As you shoot, you look for the best way to frame your subject in the image. Will you zoom in so that you see a close-up of the person’s face, breathless and excited? Or will you zoom out so that you see his whole family standing together at a huge stadium, cheering for their favorite football team? Will you take a short video clip of someone checking email while she stands at the airport check-in counter, or will you take a video of her entire journey—waking up early and grabbing a quick breakfast, riding a shuttle to the airport, getting caught in rush-hour traffic, being dropped off at the door, checking in, going through a long security line, and finally boarding the plane?
Determining a frame is in large part determining the scope of the problem you’re about to solve. Good framing is clear about what that problem is, how big it is, and what aspects of it are most important to address to achieve customer delight. The framing you use is referred to over successive iterations of the Fast Feedback Cycle. It serves as an anchor from which you measure progress toward your high-level customer goals and keeps the customer’s needs and viewpoint embedded in the day-to-day activities and decisions of the team.
Get everyone on the same page
One of the most important goals of framing is to get everyone on the team on the same page about what you are aiming to build. This does not mean just the engineering and user experience teams; it also includes management, marketing, sales, and especially any internal or external partners. Whichever framing technique you use must be clear and useful for all of these disciplines and stakeholders so that they can all use the same map and navigate in harmony toward your North Star—your target customer.
You can trace the failure of many software teams to produce their intended results to a very simple cause—different people had a different interpretation of the problem they were collectively trying to solve for their customer. This problem isn’t unique to software development—it shows up in hardware design, road construction, architecture, and other areas—wherever groups of people need to collaborate to build something, and the problem is complex enough that there isn’t just one way to solve it. Whether or not a project fails outright, disconnects in communication and alignment make the road unnecessarily bumpy and unpleasant for everyone involved, and greatly decrease your chances of delivering a truly delightful solution.
Planning a software project, whether a brand-new service, version 5, or version 525, is akin to solving a system of interrelated, multivariable equations—with there being only one valid solution. You must figure out what customers need, what solution to build to meet that need, and what kinds of technology the solution requires, all while balancing the realities of schedules, resources, and technology constraints. In the rush to get the project started, it’s natural to want to jump in and attempt to solve for all variables at the same time. But what can easily happen is that some people on the team argue about what technology to use, while others discuss what the solution should look like, and still others focus on understanding exactly what the customer’s needs are.
Trying to make all these decisions in parallel is tough enough for one brain to do, but it becomes nearly impossible when you have an entire team that needs to work together. Furthermore, when all the factors are variable, there are too many possible valid solutions, and each have their merits—so discussions become circular, decisions don’t seem to “stick,” and you get the feeling that the project is being built on quicksand. It’s really hard to fight against an invisible monster. This leads to a morale problem—an overwhelming sense of complexity and ambiguity during the planning phase of a project, which causes many people on the team to want to bury their heads in the sand until it’s all over, which further inhibits the collaboration and consensus building that is so important in the project’s early stages.
If you want to have a collaborative planning effort that makes use of the experiences and strengths of more than a handful of people, you need to add just a bit more structure. The key is to be disciplined enough to clearly frame the problem you’re trying to solve before you launch into solutions. You are narrowing the complexity, not by defining a specific solution path, but by articulating a firm decision about who you’re building for, what they need, and how you will define success. You must pause to get team-wide understanding and buy-in on the stated problem before you move on.
Once that’s done, the engineering team can engage productively in brainstorming solution ideas and technologies with a clear goal in mind, and not argue anymore about whether this or that problem is the most important problem to solve. With a clear framing, the team is less likely to get sidetracked on tangents that may appear promising or interesting but that result in wasted effort because they don’t align with your ultimate goals. Strong framing enables a loosely coupled team to make fast progress by providing team members with enough focus and direction that they can make decisions that consistently optimize for the same end-to-end customer needs.
Mindshift
Beware of putting a stake in the ground too soon. Many engineering teams make the mistake of leaping into technical decisions too early, at least in terms of “broad brushstrokes” or to “put a stake in the ground.” Unfortunately, deciding things too early can limit your ability to generate out-of-the-box ideas because your thinking quickly solidifies around that early plan and you have trouble seeing fresh alternatives.
Additionally, defining solution specifics too soon tends to lead to contentious arguments between disciplines, stakeholders, and partner teams on issues such as which technology or platform to use—even before the problem is fully understood. Collaboration goes much more smoothly if you identify a specific end-to-end customer problem first and have everyone agree that it is a vital one to solve for the customer—and also agree on which things you will not try to address right now. Only after you have that agreement should you go to the next stage in the Fast Feedback Cycle and together brainstorm about technology options for how you can go about solving your chosen problem. It is much easier for teams to negotiate viable solutions that work for all stakeholders after the common ground for what is required to delight the customer is established. Engineers need to resist the temptation to skip the framing step.
You will still rely on the quick iterations and continual customer feedback of the Fast Feedback Cycle to validate whether the path you choose actually works. As you iterate and learn more about your customers’ needs, desires, and preferences, you may need to adjust your framing. But it is essential to make any adjustments in a transparent way in order to keep the team aligned and pointed in the same direction and to not devolve into throwing spaghetti at a wall and seeing what sticks.
Maintain customer focus throughout the project
The second major benefit of a good frame is that it serves as a mechanism for focusing on your customers throughout the entire product cycle. A customer-focused framing should remain highly relevant even into the endgame of a project. The core customer need you describe isn’t likely to change, even though your solutions might get better and better over time. As your project progresses, your focus on customer needs is helped by continually checking against your framing, including tracking against experience metrics. Continuing to track how well you are performing against your initial framing is an essential habit to foster to ensure that you actually ship a complete solution for the customer problems you identified.
We all know how easy it is to get sucked into thinking about execution and implementation details as a project progresses past its initial planning stages. Over the course of even a short project, thinking about what technology to use, wondering whether this partner will deliver on time, and tracking how many bugs you still have to fix can quickly occupy mind share. Furthermore, it’s easy to be distracted by new discoveries, clever technology hacks, elegant algorithms, a competitor’s new release, or any of a myriad of other shiny objects that might catch the team’s attention and unintentionally distract you from your strategic goals. Even the best scenario-focused plan can easily turn into a disconnected set of features and functionality if the team forgets about its customers and scenarios midway through.
Building in regular and systematic checks of your work in progress against your framing is crucial for ensuring that you’re still solving the problem you initially set out to address—and that you stay focused on solving customer needs. Everyone on the team must keep his or her eyes on the prize all the way to the end. Without a solid, customer-focused framing to measure against, you can easily be blown off course.
The basics of framing
Now that you know why framing is so important, let’s talk about some of the most important considerations for how to build a good frame for your problem.
Capture the end-to-end experience with stories
While a problem can be framed in many ways, we’ve found that stories are particularly well suited for describing end-to-end experiences, which is why we prefer story-based framing techniques for most software projects. It is very powerful to tell the story of a customer’s problem from the customer’s point of view, showing both how a customer experiences the problem and what the customer’s life is like after the problem has been resolved (we hope with the help of your innovative software solution). Stories naturally capture the essence of the real-world problem and the important constraints and contextual factors to consider, which are all important clues about how to evoke delight. By describing a real-world story about your customers in a particular situation, at a particular time, and with a particular problem, you can capture insights about what customers care about, identify what will truly delight them, and clarify the end-to-end path that needs to be traversed to deliver a complete solution.
One great benefit of customer-focused stories is that they do not require you to speculate about what technology choices you have to make, about how the product will look or act, or even about how expensive it will be to build. Quite truthfully, in the beginning of a new project, you simply don’t have the answers to those questions yet. However, even in this early stage, stories can clearly articulate exactly what problem you are proposing to solve for your customers, how important that problem is to them, and how good the solution needs to be to evoke delight. Starting with a set of crisp stories ensures that everyone involved in the prioritization process has the same understanding of what you’re setting out to achieve.
Neuroscience break, Dr. Indrė Viskontas
We may never know why our brains have evolved to behave as they do, but there are some compelling ideas that are supported at least by correlations, if not by definitive experimentation. One such idea points to the fact that around 1.7 million years ago, our skulls began an exponential expansion that suggests our brains inside got a lot bigger very quickly. Around the same time, our ancestors began living in groups, using tools to hunt and survive and eschewing solitary existences in favor of communities.
There’s also evidence that what separates humans from other primates and other animals in general is the ratio of our brain to body size: comparatively, our brains are bigger than animals that we consider less intelligent. What’s more, the ratio of neocortex, the newest part of the brain (phylogenetically speaking), to older regions correlates strongly with group size: that is, the larger the social group of a species, the greater proportion of the brain is neocortex. And it’s the neocortex that is most active when we’re trying to decipher the thoughts and feelings of others. Our brains were likely shaped by evolution to permit us to live in socially cohesive groups. That’s the social-brain hypothesis.
So what do stories have to do with it? Well, it turns out that stories are how we learn to understand and predict the behaviors, thoughts, and feelings of others. Children love to listen to, read, and tell stories because stories help them make sense of the world around them—and the often complicated and nuanced behavior of the adults and children with whom they interact. Our conscious memory system has evolved such that we remember events by reenacting the narrative in our minds. We remember by associating new things with what we already know—and putting information into the context of a story is among the most effective ways of learning it.
Here’s an example of our favorite story-based framing mechanism, writing a scenario. We’ll go into detail about how to write scenarios in a deep dive at the end of this chapter. For now, you can study this as a good example of how to frame a customer’s situation using a storytelling format:
Jessica is a sales specialist at a small European company that sells wind turbines internationally. One of her main responsibilities is collecting sales leads and sending out roughly 500 sales circulars per month to prospects. Her information comes from multiple sources: some leads she finds on her own via the web, others are provided to her by outside services and given to her in Excel files, and some come from other employees via individual emails. Each source uses different country formats, conventions, and layouts—who knew there were that many different ways of formatting an address and phone number!
<magic happens>
Jessica can easily get 500 international mailing addresses compiled in one place and standardized in a consistent format, ready to print mailing labels, without any manual editing and in under 10 minutes. Even better, she is able to repeat this task quickly in the future. Jessica is thrilled that she no longer has to spend countless hours manually editing her data, freeing her up to spend more time acquiring a greater quantity and quality of leads.
Stories have many important benefits when they’re used as a framing mechanism:
Stories are approachable Everyone on the team, regardless of discipline, can read a story about a customer and come away with a very similar idea about who the customer is, what problem the customer has, what that customer cares about, and what a good solution needs to accomplish. This reduces the chance of having different interpretations of the problem to be solved.
Anyone can write a story Everyone on the team is capable of writing, modifying, and debating the customer problems communicated in the story. No fancy techniques or skills are required.
Stories capture insights The insights you uncover in your research are documented in a way that remains relevant throughout the project life cycle, so team members can continually remind themselves who their customer is and what that customer cares most about.
Stories evoke empathy for the customer A well-told story captures the human element, making it much easier for everyone on the team to develop empathy for the customer and genuinely care about solving this customer’s problem—and to do it in a way that will be delightful for that customer.
Stories are sticky An engineering team is much more likely to remember a complex set of needs if they are framed as a story instead of as a flat list of bulleted requirements.
Stories can pack a lot of information into a small package Stories contain the explicit needs and insights you learn about in your research but also enough context and subtext to convey subtler customer needs and attitudes that may be the key to achieving deep delight.
Stories are a reality check Writing stories helps keep you from trying to solve problems that don’t actually exist or that no one cares about. If you can’t write a compelling narrative that captures the need to solve a problem or just doesn’t seem believable, that’s a good indication that you need to do more research or that this may not be an actual customer need after all.
Customers understand stories too You can test your stories directly with customers. If you aren’t sure whether your story is hitting the mark, take a super-quick loop through the Fast Feedback Cycle. Before you even have solution ideas, ask customers to read your stories and see if they resonate. Ask the customer, “Does this story sound like you?” By doing this quick round of feedback, you can verify that you are on the right track or perhaps uncover a missing link to help you nail down the most important aspect of the customer problem you’re trying to solve.
Mindshift
Write specific “lighthouse” stories, not generic ones. We’ve noticed that when engineering teams set out to write stories, they often try to write generic ones. Rather than specifying an instance, they attempt to describe the class. For instance, instead of telling a story about Josephine using her phone to get a few things done and make the most of her spare moments while waiting in line at the grocery story, teams are tempted to broaden the story so that it applies to being productive in any location: home, work, or on the go.
It seems like the right approach because engineers want their solutions to be applicable in an array of situations, as general-purpose tools. However, the trouble with a generic story is that it leaves a lot of wiggle room in specifying what problem you’re trying to solve, and hence doesn’t give the team the focus it needs to make clear and efficient decisions.
Is Josephine sitting in traffic? Should we build a voice-activation system that can be used safely in a car? Or is she standing in line at the grocery store, where it may be too noisy and impolite to use a voice system? Maybe it’s more important to focus on switching tasks and maximizing efficiency within the usual touch interface? How important is viewing the calendar mid-task without losing your state? These questions all become judgment calls, so they become the source of contentious arguments when the problem to be solved is left too open-ended.
Specific stories give a sharper focus for the team, are easier to prioritize, and ensure that everyone is aiming toward the same result. Just like choosing a specific target customer, writing a specific story relies on the principle of carryover, which we introduced in Chapter 4, “Identifying your target customer.” You don’t write every possible customer story, but instead you carefully choose specific, representative, canonical cases. In the context of writing stories, sometimes we call these lighthouse stories because they represent the tallest, brightest, most visible stories that the solution needs to satisfy.
By focusing the team on a specific canonical situation—a lighthouse story—you get a solution that is fully aligned, where everyone on the team is clear about what aspects of the story are the most important parts to optimize. Choose the stories you will focus on with care, knowing that if you solve those canonical situations, you’ll have carryover into similar situations that will be solved as well. This requires that you recognize it’s impossible to create a solution that is optimal for every customer situation at the same time. You need to make decisions about which situations and problems are the most critical for your customer, the solutions that will produce deep delight and satisfaction. Focus your energy on building those in a complete, high-quality end-to-end way.
Keep framing implementation-free
One of the most important aspects of any framing is that it be implementation-free. Your framing needs to articulate the problem to be solved, without describing how a solution will be built or what the solution will look like. Framing should not include any details about how the product, service, device, technology, or platform will actually work.
Whether you use scenarios, another story-based technique, or even old-school requirements to develop your framing, experts have long agreed that keeping implementation details out of framing is essential (aside from an occasional implementation constraint that is truly immutable, which we discuss later). However, many engineers find this principle counterintuitive at first, perhaps because an implementation-free framing feels as though it won’t be specific and detailed enough to tell you what to build. But this line of reasoning leads to trouble.
Consider this example of a simple, implementation-free framing statement:
John wants to share the latest kid pictures with grandparents.
Let’s play out this example and see where it leads. The next step in the Fast Feedback Cycle after framing is to brainstorm and generate as many ideas as you can think of in the hope of hitting on an out-of-the-box approach that no one has tried before. The following illustration shows a wide variety of ideas you might come up with when you’re brainstorming about solutions for this small story. In fact, some of these ideas have proved over time to be very good ones and have even given rise to groundbreaking services like Flickr, Facebook, and Snapchat.
But think about it: What if we change the initial framing the tiniest bit? What if we change “share” to “email”:
John wants to email the latest kid pictures to grandparents.
Given this framing, what kind of solutions would you think of now?
This is an interesting thought experiment. If you frame the problem to be about email, it’s quite likely that you will never consider retail kiosks, social networks, or any of the myriad other ways to share a picture beyond the handful of ideas that directly relate to email. Your ideas would look something like this:
Yet it’s easy to imagine how quickly you might fall into this trap and assume that the most likely photo-sharing solution would probably involve email. It would seem natural to start your thinking there and develop framing that mentions “emailing the latest pics.”
This is why we say, over and over again, don’t let implementation details sneak in to your framing. Engineers often have a strong desire to see the details, and this is another cause of their tendency to try to skip steps in their hurry to build, but this rush is counterproductive and will lead to conflict and suboptimal solutions. Including implementation details is the single biggest mistake people make when attempting to frame a problem.
Implementation details create two major problems. First, as the photo-sharing example shows, implementation details might constrain your thinking, making it less likely that you come up with a novel idea or an innovative approach that could differentiate your solution from competitors’. You want to have room to choose the optimal way to solve a problem and not be blocked in before you even get started brainstorming solution ideas. Including implementation details unintentionally is one of the biggest mistakes that will limit your creativity.
The second problem is a practical one. Implementation details will likely cause your framing to become out of date very quickly. A problem statement that is implementation-free can easily survive the entire engineering and development process—and be just as relevant a guide on release day as it was the day it was first penned. But if your framing includes implementation details, as soon as the inevitable twists, turns, and compromises of the engineering process force you to shift your implementation approach even slightly, your framing statement will be out of date, and the likelihood is that it will be forgotten rather than continually revised as your implementation approach evolves. An implementation-free framing is a much more durable guide and will last throughout the project life cycle, no updates needed.
Now, this isn’t to say that you will get your framing right on your first try. As you loop around the Fast Feedback Cycle, you touch base with your framing in every iteration, and may even update it based on what you learn from customer feedback, especially in the first few iterations. In later cycles, however, your framing should be pretty solid, and you will focus more on tracking your progress against your framing to ensure that you are truly solving the problem you set out to solve. Tracking metrics on a scorecard is a key technique to help ensure that you haven’t drifted away from your framing goals and that your solution is achieving the customer delight you intended. This brings us to our next characteristic of good framing: specifying metrics.
Metrics set the bar for how good the solution needs to be
Framing needs not only to describe the problem itself but to articulate what a successful resolution to the problem might achieve. But remember, this is not about describing how the solution works; it’s about what will be accomplished by a good solution. What will your customers have accomplished if your product succeeds in solving their problem? What outcomes will they have achieved? As you iterate around the Fast Feedback Cycle, you need to know when your solution is good enough so that you can stop iterating and ship or move on to the next problem.
You express what a good solution would look like by incorporating a handful of specific, customer-focused metrics into your framing. The metrics should be tied to the factors that will produce the customer delight you are striving for—in that particular situation, with that particular target customer. Coming up with a dozen interesting and relevant experience metrics is easy, but this is a case where more is not better. Narrowing down the metrics to the one or two measures that are the most important is how the true intent and goal are articulated. The exercise of choosing key metrics often sharpens the framing considerably. Again, only with this level of precision in your goals does it become possible for a diverse engineering team to remain loosely coupled in their work but still optimize the end-to-end experience with alignment and consistency.
As the project progresses, these customer experience-focused metrics become critical as a way to measure and track whether your proposed solution is really solving the problem you set out to solve and keep you from convincing yourself that it’s working when it really isn’t. As Eric Ries warns in The Lean Startup, beware of creating “vanity” metrics that make you feel as though you’re making progress but aren’t actually measuring what customers really think about your solution.1 For instance, tracking the number of downloads of your product on a website is not nearly as interesting as tracking customer satisfaction and sustained usage scores over time. Lots of downloads could be the result of great publicity or the fact that your solution is the only one available, but if customers aren’t genuinely satisfied, they will quickly defect when a competitor ships a better alternative.
SFE in action: Don’t believe your vanity metrics
Clint Covington, Principal Program Manager Lead, Microsoft Office
As a lead program manager on the Microsoft Access team, I was responsible for the Access templates. At the time, the team knew that it was difficult for many customers to start using a database product and to get it to do what they want. Access templates are designed to jumpstart projects. One goal for the team was to grow the usage of Access, and these templates are a great way to help people get started faster. We had made a sizable investment in identifying new scenarios and building out a set of new templates while also improving some of our existing templates. We also changed the Start screen in Access to make it easier for people to find and discover the templates.
Most of us believed the work we had done was received positively by customers. Template downloads from Office Online grew from 1.1 million to over 8 million in about 18 months. Download trends looked like a hockey stick, ratings were above four stars, and comments were mostly all positive. I felt great about our progress.
Looking back on that now it is clear that the number of template downloads and associated ratings were “vanity metrics.” After all, our team’s goal was to increase overall usage. But at the time, my manager was skeptical that our template investment was driving overall usage. He doubted that we had made as much progress as those of us who were down in the weeds thought we had made. He asked me to look at metrics beyond downloads that pointed to overall usage growth. I had just read the book The Ultimate Question: Driving Good Profits and True Growth by Fred Reichheld, which inspired me to think hard about how we were measuring success. It seemed like a perfect application for what we were doing.
So we changed our approach to gathering usage metrics. This time, after a user had used a template four times, we gave the customer a standard Net Promoter Score (NPS) survey that asked questions such as “On a scale of 1 to 10, would you recommend this to your friends or your family or coworkers?”
The results were crystal clear—templates were not helping people get started faster with Access, nor did the templates generate greater satisfaction. Our total NPS score was terrible. There were more demoters than promoters and too many passive ratings—the NPS score did not match the type of growth we were seeing in the downloads of the templates. The verbatim comments from customers were brutal as demoters described their frustrations. Quite honestly, I was embarrassed by our Net Promoter Score. The clarity of our failure inspired us to make changes.
We categorized the negative feedback into buckets. In the NPS survey some people would voluntarily leave their email addresses, so we emailed them and arranged phone interviews. We spent several weeks calling people and digging into the color of the verbatim feedback. We learned that people were initially hopeful that the templates would save them time and help with their job. This hope is what led to the initial four-star ratings we had looked at earlier. But we now discovered that once a customer started to actually use the template, they hit a wall and became frustrated and dissatisfied. Through this new set of data and interviews it became clear to us that there were three or four design flaws in the product and there were gaps in users’ knowledge that led to the majority of the frustration that people were experiencing.
Using our new insights, we redesigned several key flows in Access. We also produced a training video focused on helping people get past the problems we identified. We then brought people into the usability lab and watched them use the templates, after which we made further refinements. Several months after the first survey went out, we rereleased an update. The feedback to our updated templates came back far more positive. The Net Promoter Score increased by about 35 points and the help videos quickly became the most popular Access help assets.
The desire to change the template design was motivated by the clarity of the feedback the NPS survey generated. We used this to prioritize this work above other things we could have been doing. The NPS survey data combined with direct customer follow-up helped focus our efforts into the experiences that mattered most for people trying to use Access templates. The team found it inspiring to see such profound change in customer delight and quantifiable progress in creating a solution people loved.
Big stories and small stories
Over the years we have seen teams use different ways to frame their software projects. Many approaches rely on a multilayer hierarchy of priorities, starting with a few major areas of focus or themes that are then systematically broken down into smaller and smaller investment areas, eventually naming the deliverables, features, and tasks that represent the engineering work that needs to be done to deliver on those goals. Historically, these hierarchies of work, or work-breakdown charts, have consisted mostly of technology-focused investment areas, features, and work items.
As teams adopt more customer-focused approaches, we have seen these hierarchies shift to use customer stories as the primary nodes that both define and organize the engineering work to be done. There are roles for many types of stories within such a hierarchy, depending on the size and scale of the team, the type of project being undertaken, and the length of the milestones, iterations, or sprints. A team might write large-scale stories to recount the overall cradle-to-grave experience. It might write smaller stories that describe specific jobs or tasks the customer is trying to do. It might even include one-liners to describe slices of a larger story that can be implemented within a single Agile sprint.
Interestingly, nearly every team we’ve worked with, from small teams to thousand-person organizations, has ended up using a two-level hierarchy of stories: a small collection of larger scope, end-to-end narratives that each comprise stories that describe particular jobs, subtasks, or aspectsof the larger end-to-end experience. Said another way, teams create big, end-to-end, or vision-level stories that articulate larger experiences, and these are then segmented into numerous small or task-level stories that align with the larger ones. (Some teams tried working with a single, flat list of stories, but found the list too long to manage, and the stories all had different sizes and scopes. A few teams tried a three-level hierarchy, but that became too complex and felt too process-heavy, for marginal benefit.)
This story hierarchy usually sits near the top of a team’s work-breakdown chart and becomes the parent of the subsequent features, deliverables, tasks, and other work items that are needed to deliver those experiences. While each team we’ve worked with has its own system for accomplishing this, some repeatable patterns do emerge. We’ll talk about where stories fit within a larger work-breakdown hierarchy, how to associate deliverables and tasks with stories, and the mechanics of how these pieces work together in Chapter 11, “The way you work.”
Mindshift
Focus scenarios on defining the length of an experience not the width. One of the biggest traps we have seen teams fall into is writing way too many scenarios. With the intent of being complete and comprehensive, teams write a scenario to describe every single related situation and edge case. You will go crazy with that approach and end up with hundreds or thousands of scenarios, and this will be unmanageable.
Instead, think of your scenarios as guideposts, not as complete specifications. Your scenarios should capture the most important end-to-end experiences that you are optimizing your solutions for; you’ll use good engineering practices to handle variations and edge cases as you get into the details of building solutions.
As our colleague Jeff Braaten would say, you can think about this as length versus width. Scenarios should focus on defining the length of the longest possible end-to-end experience, from start to finish, and should not try to cover the full width—the edge cases and possible variations within that scenario. Pick the canonical situations that describe the length you are going for, and focus on writing those scenarios. Many of the variations will be addressed naturally in the engineering process of building those long experiences.
Frame stage: Key tools and techniques
As in all of the stages in the Fast Feedback Cycle, you can choose from different tools and techniques to frame your problem. (There are many more than we cover here.) Depending on the nature of your project, its size and time frame, and the number of people involved, you should choose the techniques that best fit your needs. The techniques we highlight fall into three broad categories:
Tools that help you capture key metrics
Tools that help you tell the customer’s story
Tools to help you prioritize your list of work
Tools that help you capture key metrics
All of the framing techniques we mention should be paired with metrics or have metrics embedded in them. For all the reasons described earlier in this chapter, it is critical to keep your success metrics focused on your customers’ experience and to create metrics around specific customer outcomes. Metrics give you explicit, experience-oriented goals to reach, which are essential for keeping your focus on customer needs and scenarios through to the endgame of a project.
Generally, we have found that effective, customer-focused metrics break down into two broad categories:
Performance metrics These metrics capture information such as how quickly a customer is able to perform a task, how many clicks are needed to buy a book, how many errors a customer makes when attempting to use a new API, what does a customer do after opening a browser, or how many customers successfully complete their task. Like DO data, these metrics are more objective in nature. For larger end-to-end experiences, a relevant performance metric may stretch across multiple systems, platforms, or teams. There may be substantial investment in building instrumentation and a tracking system that can collect these metrics in an automated way. You can also capture many performance metrics with a stopwatch and careful note taking during a series of user tests.
Perception metrics These metrics capture data such as how satisfied a customer is with the overall experience, how frustrated she felt when something went wrong, how confident she was that she got the answer right, or how delighted she was to find a new way to solve an old problem. The typical approach for how to capture these types of metrics is to ask customers to rate a particular aspect of their experience on a 5-point or 7-point scale. For instance, “On a 5-point scale, please rate how difficult or easy it was to find the movie you were looking for (5 is very easy, 1 means very difficult, 3 means neutral).” Like SAY data, these metrics are more subjective in nature, though they are most often captured in a quantitative way for ease of tracking and measuring trends over time.
Whether you choose more performance-oriented or more perception-oriented metrics, you should set a specific numerical goal—for instance: “Customers can successfully send their first text message within three minutes” or “Customers rate their overall satisfaction at 4.5 or higher on a 5-point scale.” This metric should be measured frequently so that a trend can be established and any regressions in the metric can be noticed promptly.
Tip
One great way to report metrics throughout your project’s life cycle is to build a scorecard that rolls up your top metrics into one view. We’ll discuss customer-experience reporting in more detail in Chapter 11.
Some teams rely so heavily on metrics and scorecards as tracking mechanisms that the metrics themselves act as a primary framing tool. However, even if the metrics take a primary framing role, they should always be paired with scenarios to illustrate the specific, canonical usage patterns for which that metric should be assessed and measured.
Mindshift
System metrics and test-case pass stats are not customer-focused metrics. Most engineering teams already use plenty of metrics in tracking their work, whether they are tracking bug counts, burndown charts, team velocity, or test-case pass rates. These are important measures of internal work completion that help teams manage execution, but they are not customer-focused metrics. Customers don’t care how many bugs you fix, how many story points your team can achieve in a week, or how many lines of code you have written—they care only about how well their individual needs are being met by your solution right now and how fast a fix is available the next time they have a problem. It’s certainly possible that even though a team reports that its test pass is complete and everything appears to be working according to plan, the customer is not satisfied with the solution that was delivered. Engineering metrics do not tell you about the customer’s perspective.
Many teams also have system-level instrumentation to track server performance, availability, and so on. These are important metrics to track for engineering quality and system health—and failure in these areas will surely impact customer experience—but they tell you only whether something is wrong, not whether something is right. If the servers are down all the time, that will indeed create a bad customer experience. However, having a service that is reliable and performant does not tell you anything about whether the customer is delighted with the solution you provide. Again, for that you need to focus on measuring customer outcomes.
Tools that help you tell the customer’s story
The following sections describe several techniques you can use to frame a problem. Some are more suited to big stories, others are better at small stories, and some are multipurpose.
Scenarios
Best for: Capturing an end-to-end situation with contextual information, metrics, and empathy for the customer in a single package. Appropriate for big or small stories.
The first framing technique we taught at Microsoft is writing scenarios. We developed a standard two-paragraph story format that captures the essence of the customer’s perspective, the customer’s needs as expressed in a specific situation, and the customer’s contextual environment. This format also has one or two metrics embedded in the scenario that clarify the goals in a numerically succinct way. Everything you need to know to start working on solutions is captured in this one vehicle, making it a surprisingly efficient approach. Here’s an example:
Josephine gets stuff done in the grocery line
Josephine is a busy mom of two school-age kids who has a dog and is always on the go. She feels like she never has enough time. Just yesterday she almost left her son at an empty soccer field when she missed the coach’s email that practice was cancelled. Josephine is standing in the checkout line at the grocery store and realizes that she is going to be waiting a few minutes. She has so much to get done today and doesn’t want to miss another important message or deadline. Could she get a few things done while she waits?
<magic happens>
While standing in line for six minutes, Josephine was able to check off a bunch of items from her to-do list: pay for her kids’ music lessons, RSVP to a party (after checking that she and her husband are available that evening), schedule an appointment with the vet, answer her husband’s text message to assure him that she did buy milk, scan her email to learn that her son’s soccer practice was cancelled again this afternoon, and even squeeze in a quick peek at her favorite game, AlphaJax. The time waiting in line flew by. Josephine felt like she was able to maximize every second to help stay on top of her busy life and was able to give her full attention to her kids when she met them at the school bus later that afternoon.
We’ll do a deep dive on how to write scenarios at the end of this chapter.
User-journey maps
Best for: Complete end-to-end or cradle-to-grave experiences. Capture multiple stages or steps that a customer goes through. Produce a good visual chart that shows all the steps, processes, systems, and partners touched by customers during their experience.
We discussed user-journey maps in Chapter 5, “Observing customers: Building empathy,” as a way to show the steps that a customer goes through in an existing experience and analyze what is going well or poorly at each step. The user-journey technique is also great for describing the essential steps in a proposed end-to-end experience, especially for experiences with a larger scope. This technique is ideal for describing a cradle-to-grave experience that has multiple stages or steps that a customer goes through, usually over a longer period of time. User journeys are also good for describing extensive experiences that involve many different groups or stakeholders that each need to contribute in one or two steps but still be aligned to the larger whole.
Here is an example of what a simple user-journey map might look like for a cradle-to-grave experience for a mobile phone:
If you find yourself stuck and can’t quite figure out which scenarios to write, what jobs make up the experience, how it all connects, or which stakeholders are involved in which places, it may be worthwhile to put together a user-journey map to help identify the essential stages customers go through in their overall end-to-end experience.
User stories
Best for: Small stories or task-level scenarios. Articulate specific, individual paths or slices through a story or scenario. User stories are a mainstay technique for many Agile teams.
Teams who use Agile and Scrum-based approaches have been writing user stories to frame, manage, and track their work for a long time. User stories identify a single path or a slice that a user might take through a larger story. They represent atomic units of work that can be completed in a single sprint and that deliver a visible increment of functionality that the customer can see and experience. Agile teams demonstrate their latest working code to customers at the end of each sprint in order to get rapid customer feedback to inform the next sprint.
A user story has a very specific format:
As a <type of customer>
I can <achieve an outcome>
So that <reason or customer motivation>
Using our mobile phone example, you might write a user story such as the following to break down the larger story into several slices that you can start building one at a time:
As a busy mom, I can check my calendar and respond to an email while waiting in the grocery line so that I can maximize every second of my busy life.
When paired with a big scenario to provide end-to-end context, user stories are a great tool to help prioritize and order the actual work of the engineering team. While the user story guides the work of an individual sprint, the scenario is used to identify and track all of the user stories that need to be built until the complete end-to-end experience is reached. Many teams use an end-to-end scenario that is broken down into user stories as a way to understand and describe a minimum viable feature set.
The downside to user stories is that used alone, standard Agile approaches encourage teams to focus on one story at a time, and this can encourage teams to spend their time adding one piece of functionality after another without a lot of thought to the complete end-to-end experience. With shorter sprint lengths, user stories can also be broken down so finely to fit within a single sprint that the customer context may be lost. So beware that user stories that are unconnected to larger narratives can gradually devolve into a feature list, either by how they are used by the team or by incorporating actual implementation details into the user stories themselves in an attempt to scope and clarify the work for a given sprint.
Tip
Don’t mistake use cases for user stories. Use cases are a more formal way of describing customer requirements for a particular situation or sequence of events. A use case usually takes the form of a table in which you explicitly name the primary actor and stakeholders, the precondition (the state of the user and system at the beginning), triggers that start the action, the postcondition (the state of the user and system at the end), and a numbered list of detailed steps that the customer would take through a particular situation. Use cases tend to assume a particular implementation, and hence will embed implementation details in the list of steps. For this reason, we do not recommend this technique as an approach to framing, however it can be a useful way to describe a particular solution path in a specification.
Epics
Best for: Larger end-to-end stories within an Agile team. Similar in scope and usage to a scenario.
Another technique that is catching on in the Agile community is the epic. An epic is constructed at a higher level than a user story, which puts its focus on the end-to-end experience that’s desired and the larger problem that is being solved. Some Agile teams write epics in narrative, paragraph form. As such, epics can be indistinguishable from scenarios, and the terms can be used synonymously.
We’ve also seen some teams formulate epics using the standard user-story format, but they write them with a broader scope. For example:
As a busy mom, I can get multiple tasks done while standing in line at the grocery store so that I can maximize every second of my busy life.
The division between epics and user stories aligns quite well with our experience that teams usually end up with a two-level hierarchy of stories—in this case, epics serve as the higher-level or big end-to-end story, and user stories act as the lower-level, small stories. Used in concert, epics and user stories are a good approach to framing as long as the epics are written in a narrative form and contain enough context about the customer and the situation. If not, they need to be paired with the key insights, motivations, and context about the customer to ensure that enough specifics are captured and empathy with the customer is not lost.
Neither user stories nor epics naturally include a specific success metric. Hence, it’s also critical to pair this approach with some sort of mechanism to identify and track the metrics that determine what success looks like and help you to know when you have achieved the goals of the end-to-end experience.
SFE in action: The Storytelling Storyboard Toolkit
Susan Mings, PhD, Senior Design Researcher, Microsoft Windows Server Systems; Matt LaGrandeur, Designer II, Microsoft Windows Server Systems; Joe Hallock, Senior Design Manager, Microsoft Windows Server Systems; Ken Coleman, Designer II, Microsoft Windows Server Systems
As the SFE philosophy and practice has spread across Microsoft, it’s been great to see colleagues in diverse disciplines become more excited about focusing on user-centered design. The concept of “storytelling” seems especially resonant—who doesn’t like a good story? Learning about users through research, and then drafting stories about users’ current frustrations and future goals has become standard steps when specs are first drafted.
The advantages of storytelling practices are obvious: team members gain empathy for customers, get excited imagining the “happy ending” our products can provide them, and rally around a common vision that everyone can grasp. But sometimes our written customer stories have not been as powerful or as easy to use as we hoped. Drafting the text of a story is a significant time investment for the author, who has to sweat about the precise words that describe the user’s context, frustrations, and goals. And speed-reading long text blocks just before a review meeting takes time, plus there are language differences among global team members.
To address these drawbacks, and in the spirit of SFE iteration, a few brave teams decided to try picture stories. Another tenet of SFE is conveying ideas with quick sketches, so we added drawings to our storytelling. We started “small” with sketches, arranging simple drawings in a narrative sequence. Here’s an example:
Teams adopted this “sketch storyboard” method quickly. These drawings were quick, easy, and fun to sketch—certainly faster to produce than a long narrative! Sketch storyboards worked great for sharing the essence of user stories within the team.
But again, there were drawbacks. Sketch storyboards were not great to use in presentations to key stakeholders or executives or to get feedback from customers. As hand-drawn artifacts, sketch storyboards were low quality, inconsistent across storytellers, and not digital. To address these issues, the UX team added another step to the process and started creating high-fidelity illustrations as in this example:
The high-fidelity illustrations did address some of the issues with the sketch storyboards. They worked great for presentations, they were high quality, and they had a consistent look and feel. However, they were time-consuming to produce and required a skilled artist. Most importantly, we had inadvertently moved away from the SFE philosophy of team participation in design.
To address these issues, we developed the Storytelling Storyboard Toolkit. It met our goals of standardizing and digitizing storyboard creation, and it was easy enough for anyone to use to create a storyboard. The first version of the toolkit (nicknamed the “Mr. Potato Head” version) was a PowerPoint file that contained storyboard elements that could be pieced together into a story. Here’s an example of some pieces and a character created from them.
Put some characters together with some text, and you could create story frames like this one:
As teams adopted our toolkit, we realized that assembling the characters was rather tedious. Our second version of the toolkit (nicknamed the “Colorforms” version) solved this problem by providing larger elements to work with. Instead of elements such eyebrows, a nose, a mouth, and so on, the “Colorforms” version provided faces. Each face corresponded to a type of user and came with different expressions. It was easy to change faces to show different emotions. Here’s an example of one such user.
This toolkit also included galleries of backgrounds, objects, and callouts for dialog. By combining multiple elements, anyone could easily construct a high-quality storyboard:
We’ve found storyboarding to be a powerful UX tool for motivating team members to create, review, and share user stories. Our teams have integrated storyboards effectively into the engineering process both to formalize user stories in specs, and to communicate those stories effectively at executive, stakeholder, and customer reviews.
“I can” statements
Best for: Very small stories, similar in scope to an Agile user story. “I can” statements are best when paired with an end-to-end story.
An “I can” statement is really just a shortened form of a user story that focuses on that middle line: “I can <achieve an outcome>.” This approach is not normally advocated in the Agile community because it omits both the explicit definition of who the target customer is and the all-important reasoning or customer motivation for the story. However, as with user stories, we’ve seen teams successfully use “I can” statements as a detail-level small story in conjunction with a parent end-to-end narrative that clearly conveys the customer’s situation and context. Sometimes it helps to name the customer instead of using “I” if the customer’s identify isn’t clear from the supporting story.
For our mobile phone example, you might write an “I can” statement such as this:
I can RSVP to a party invitation while standing in line at the grocery store.
Josephine can check her calendar while on the phone with the doctor’s office.
Outcomes
Best for: Discrete jobs that make up an end-to-end scenario and associated metrics.
Outcomes have become more popular in the past few years. They were inspired by Clayton Christensen’s idea, “What job is the customer hiring your product to do?”2 Those jobs are the atomic units of the experience of your product and are expressed as the outcomes that customers hope your product will help them achieve. Said another way, outcomes enumerate all the actions your system must perform, along with a key metric that specifies how well the system needs to accomplish that specific job for the customer.
An outcome is typically structured in one of two ways:
<minimize/increase/etc. a key metric> + <to do this specific job> + (target: <goal>)
Example: Minimize the time it takes for Marina to send a quick message while she’s in the middle of doing another task. (Target: 30 seconds)
<Customer> can <do this specific job> + <metric>
Example: Marina can send a quick message while she’s in the middle of doing another task within 30 seconds.
Outcomes are best used in concert with scenarios or other story-based approaches. In fact, you can think about a scenario as a sequence of outcomes that the customer needs to accomplish. The atomic nature of outcomes makes them uniquely suited for helping to organize and prioritize metrics across a suite of scenarios.
Requirements
Best for: Documenting the technical constraints, policies, and implementation that are necessary for success and are nonnegotiable “must-haves.”
The idea of writing software requirements has been around for decades. If you’ve ever studied the theory, you’ll know that the key to a good requirement is for it to be implementation-free. However, in practice, this is very difficult to achieve, and most attempts at defining a list of short, crisp requirements end up with a laundry list of features, which are decidedly not implementation-free. It is tough to write a short, specific description of a customer need that is unambiguous, without also telling the customer’s story or providing the context behind it.
Even if you are successful in keeping requirements implementation-free, they are still tricky to use: they end up as a list of product attributes (fast, easy) and jobs the customer needs to accomplish (copy, edit, send). However, without context about how and why the customer does these tasks, misunderstanding is inevitable between the person who writes the requirement and a person attempting to design a solution to meet that requirement. For this reason, requirements are our least favorite approach to framing. Even if requirements are truly implementation-free, this approach often devolves into creating a long list of hundreds of detailed items, with very little connective tissue for understanding how those requirements relate to each other or how they work together to form a coherent whole. It’s very easy to get lost in the details and satisfy each of the requirements but not actually deliver an end-to-end solution.
However, although we are not big fans of using a requirements list as the sole way to frame a project, a requirements list is sometimes the right tool for the job. Sometimes, you have a set of business and technical constraints that are nonnegotiable. For example, say you are running an online business and want to expand globally. Your well-thought-out business strategy suggests that you should target Brazil as your next expansion market. In your research you discover a handful of tax, legal, and other implications for doing business and selling software in that market—issues such as how and who you make payments to, how you advertise, how you collect fees, how you do business with the banks, how you pay taxes. These are the technical and business constraints that you must implement correctly before you can even consider doing business in Brazil. In this case, it makes sense to have the legal and business requirements dutifully researched and listed in a requirements document, thus saving the engineering team the time and expense of figuring out exactly what it means to do business in Brazil.
Even though a well-researched list of requirements can be useful when you have a number of detailed business or technical constraints that are very specific, well understood, nonnegotiable, and must be implemented, don’t fall into the trap and fool yourself into thinking that by implementing those requirements, you are finished. Meeting those requirements likely means you have paid the required dues of getting into that business . . . now, how are you going to beat your competition?
Goals and non-goals
Best for: Communicating the most important feature and performance tradeoffs in a technical component that does not directly face the customer.
Another non-story-based technique is to write a list of goals and non-goals. This technique can be good for framing deeply technical problems, where the target customer’s experience is several layers away from the platform. In this case, the customer’s needs can sometimes be captured as a set of key performance and functionality tradeoffs.
This isn’t our preferred way of framing, but teams that are new to a customer-focused approach may have trouble thinking about how end-to-end scenarios feed down into the deep platform layer. This technique provides a reasonable compromise, especially when used in concert with customer-focused scenarios that describe the overall experience that a platform ultimately needs to support.
When writing goals and non-goals, keep in mind that the list of non-goals—the specific things that you are not trying to achieve—is a particularly powerful way to focus the team on the most important aspects to optimize and keep it from being distracted by tangents or details that are notas important. Writing down non-goals helps ensure that team members are on the same page about what the true goals are.
The press release
Best for: Aligning marketing claims with engineering plans.
Before you even know what the product looks like, write a press release detailing the marketing story you would tell on the day your product is released. In the style of a press release, describe what problems have been solved, what new opportunities have been realized, and what customers and reviewers would say to praise the product.
Writing a press release can be a great technique for aligning marketing plans with the development team and to clarify the business value of the proposed project. For one thing, it allows the marketing team to think through the key value propositions ahead of time and do a gut check on whether those really are differentiators and will resonate with customers. A press release can be tested with customers, analysts, and partners to gauge reactions and then fine-tuned based on that feedback. In addition, having the marketing messaging and key claims written out provides guidance to the engineering team about which aspects of the end-to-end experience are the most marketable, and hence most important to get right.
Tip
Cross-reference the press release with your stories and then mark the stories that the marketing department cares most about to ensure that those stories are tracked carefully throughout the project. If a story is at risk or a component might need to be cut, the fact that it is a key element of a marketing campaign should enter into the decision.
The art of storytelling
At the end of the day, most of these techniques boil down to telling stories about human experiences. The ancient art of storytelling can teach you a lot about how to write a captivating and insightful narrative about a human being’s experience. Various storytelling patterns and forms have emerged over the centuries. Here are a few that may provide some guidance for writing better end-to-end narratives:
Story arc Most stories gradually build tension, starting with a small crisis or two, resolve those issues, then introduce a bigger crisis, work up to a major climax, and finally have a resolution. This gradual and measured progress through successively larger crises and resolutions helps keep the reader engaged but not overwhelmed. It’s easy to see how a story arc might apply to game development, following the story of a character through multiple challenges until you meet the big boss. However, even though you are not generally trying to create crises for your customers, a similar pattern of gradual learning and successive accomplishments also applies to more productivity-oriented situations for which you want to build an end-to-end product or service experience that is engaging and productive, but not overwhelming. Sometimes the term “story arc” is used to refer to the overarching story that the smaller narratives can be tied to. In this sense, it can be used as a synonym for a user journey, epic, narrative, or big scenario.
Hero’s journey This is a literary structure or analysis technique (coined by American mythologist Joseph Campbell) that identifies typical stages in stories that feature a main protagonist, or “hero,” who undergoes a personal transformation through a special experience. Ancient stories that have survived the ages, as well as great modern-day stories, have an uncanny resonance to the Hero’s Journey pattern, implying a deep connection to fundamental truths about human experiences. Key stages include the call to adventure, threshold, challenges, revelation, transformation, and return to normalcy. Again, these stages can be guideposts for framing an end-to-end experience that will engage customers and resonate at a deep human level.
Three-act structure This classic dramatic structure is frequently found in plays and screenplays and underlies most narrative stories. Act I provides background information, introduces the characters, sets the stage, and concludes with a significant moment of conflict or a turning point in the story. Act II develops that conflict and follows the emotional journey of the main characters until the conflict reaches a climax. Act III provides the resolution of the conflict. Generally, a story should spend 25 percent of its time in Act I, 50 percent in Act II, and 25 percent in Act III.
Turning the corner: Tools to help you prioritize your list of work
As you sort through your research and start writing stories, you will inevitably end up writing about more issues than you have time to solve. Just as in choosing a target customer, it’s more important to focus on a few end-to-end stories and execute on them with a high level of quality than to spread yourself too thin and end up delivering an unremarkable layer of peanut butter.
As you start exploring your customer insights and developing stories to build, you will surely start forming opinions about which of these stories are the more important to pursue for your project. Your goal at this point is to prioritize your stories and decide which ones you will undertake. Whether that prioritization forms the beginning of your product backlog, a list of top-priority scenarios in your work-breakdown chart, or a spreadsheet that helps you schedule and sequence your work, it’s important to have clear marching orders for your team.
Here are a few techniques for figuring out which end-to-end stories you should go after first.
Cut low-priority stories early
Get in the habit from the very start of looking for stories that are less important—less likely to carry impact for the customer—and cut them as soon as possible. You can cut early or you can cut late, but late cuts are way more expensive. Cut early. The single biggest lever a team has for improving overall quality is to focus on fewer stories. With fewer priorities, you have time to iterate each of them to a higher level of quality and polish.
Effort vs. value
A classic approach for prioritizing work is to estimate the approximate “bang for the buck.” The idea is to generate very rough cost estimates, as well as estimates of how valuable each scenario is to the customer. Use that data to judge which stories might have the most impact but take the least amount of effort to build.
On the basis of your customer research, you should have some empathy-based judgment about how valuable each story would be to your customers if the problems it describes were solved well. Estimating the implementation cost is a bit trickier, however. Obviously, you don’t have complete information about how much effort it will take to build a solution (after all, the stories are implementation-free), but you can still make your best guess as to whether this will likely be a long, complex, or difficult story to build, or something smaller and more tactical compared with the other proposed stories.
Rate value and effort for each proposed story on a scale of 1 to 5 and plot it. It doesn’t matter exactly how you define 1 versus 2 versus 3, as long as your ratings are consistent. The resulting graph might look something like Figure 6-1.
FIGURE 6-1 A chart that plots value to customer on one axis and effort to build on the other.
The top area represents the region of the graph where the value to the customer is high, especially in proportion to the amount of projected effort needed to deliver it. The stories that fall into this area offer a good bang for the buck and are generally worth doing. The middle area shows stories that are probably worthwhile, but you may need to trim how many of these you can take on because of time and resource availability, especially for high-effort stories. Stories in the bottom area should be avoided because they require high effort and have a comparably low value.
Tip
Sometimes several stories require the same underlying infrastructure or will reuse key functionality. This is another way to judge “good bang for the buck”—to pursue several interrelated stories that would be expensive individually but whose cost goes down proportionally the more of them you do. However, beware of feature creep—just because building something is incrementally cheap, it might not be worth doing if it doesn’t provide much additional customer value.
This is not a very sophisticated analysis, and it’s only as good as the quality of the estimates, which by definition are going to be fuzzy at this point. But even so, it can be helpful as a way to initially think about a portfolio of stories. The greatest value of this analysis comes from the push it gives the team to start talking about the relative merits of various proposed stories and, in the process, to identify stories without as strong a value proposition, which should then be deprioritized. As such, it’s a good first-level pass for prioritization, or at least an initial cut list.
Kano analysis
Kano analysis, although it was initially developed to prioritize requirements and feature sets, can easily be applied to prioritizing stories as well. The basic approach is to take the list of proposed stories and ask a representative group of target customers two key questions about each story:
How satisfied would you be if we built that story?
How dissatisfied would you be if we did not build that story?
Customers rate their satisfaction or dissatisfaction on a 3-point or 5-point scale. Then, you use those scores to group each story into one of five main buckets:
Must-haves These are the basics that customers expect in a product, but their presence does not increase satisfaction. Some people call these “table stakes”—or the minimum amount of functionality that a product must have to be a viable competitor to existing solutions.
One-dimensional Sometimes also referred to as “the more the better,” these are the solid value stories. The more of these stories that you build, the more satisfied the customer will be. Also, customers will be dissatisfied if these stories are not built.
Delighters These are the things that the customer didn’t expect but will satisfy the customer if you deliver them. A good check is to see whether the stories that feature unarticulated needs actually end up in this bucket (they should).
Indifferent This category is less common. If the customer doesn’t care whether a story is delivered, it should end up here. Building these stories would be a waste of time.
Reverse This is also uncommon, but it is very important if a story ends up here. Reverse is the unusual situation in which the customer rating indicates that a proposed story would actually cause dissatisfaction. Obviously, these stories should be cut, but also take the time to figure out why you originally thought the customer might like this idea and what insights about your customer might need to be revised in light of this new information.
The resulting chart is a nice way to visualize the differences between these kinds of stories and to give you some level of quantitative ranking between the stories within each bucket. If you want to pursue this approach, a quick web search will help you find the details for exactly how to tabulate results and create a Kano chart.
Despite the fact that a Kano analysis can be very helpful, it has a couple of downsides you should keep in mind. Strictly speaking, these problems aren’t unique to Kano analysis, but because Kano analysis produces such tantalizingly specific numeric data, you can easy be lulled into a false sense of security, thinking you know a lot more than this analysis can actually tell you.
FIGURE 6-2 A simple Kano chart, showing how a set of stories (each marked with an X) might be distributed through the categories, after being scored and averaged across multiple target customers.
First, the whole system relies on you knowing which stories to ask about. Garbage in, garbage out. If you don’t ask about the most important needs that a customer has, the Kano approach has no mechanism to tell you that you missed that opportunity. So, your Kano results will only be as good as the insights and scenarios you write in the first place.
Second, because Kano results are so precise, we’ve noticed a tendency for people to view them as the gospel—these are the “must-haves,” therefore we absolutely must build every one of these stories before we can consider anything else. Remember, however, that Kano analysis is only getting SAY data from customers, which, as you know, is only part of the truth. In particular, customers are likely to overstate what stories are “must-haves.” Also, the “delighters” bucket (things that are satisfying if they are present but not dissatisfying if they are absent) will also likely contain some less interesting “nice to haves” that may be satisfying on a surface level but not lead to deep desirability. So, when you look at results from a Kano analysis, be mindful that you probably need to fine-tune those lists based on what you have learned in your research about your customer’s behavioral patterns (DO data).
Useful, usable, desirable
Another approach is to look at your portfolio of proposed stories and make a rough judgment of what each story’s potential is for being useful, usable, and desirable for the target customer. Remember to put on your customer hat and use your hard-earned customer empathy instead of your personal opinions to estimate what customers might perceive. Even better, do some customer interviews and show them your proposed scenarios so that a few customers can rate how useful, usable, and desirable the scenarios might be from their perspective.
Useful On a scale of 1 to 5, how useful will this story be to the target customer? How pressing is this particular need for your customer?
Usable On a scale of 1 to 5, how usable do you expect your solution to be? Of course, you always aim to build easy, straightforward experiences, but if you already know of technical or resource limitations that will hamper your ability to build a highly usable experience, this would be the place to capture that.
Desirable On a scale of 1 to 5, how much potential is there to drive an emotional connection with the customer via this story?
Not every story you prioritize will be a key driver of delight—some may necessarily be focused on basic functionality and infrastructure that will enable more exciting stories later on. However, by rating your stories by potential desirability, you can be sure that your portfolio of stories includes some dazzling moments that provide emotional resonance with the customer. When you prioritize your stories, this is a helpful lens to use to ensure that you have a good mix of high desirability stories in your portfolio, balanced with solid usefulness and usability.
Competitive strengths and weaknesses
Understanding which stories are already well served by your key competitors, and which are still as yet unsolved, is another lens that you can use for prioritization. If you can identify a story that is genuinely important to your customer but is not addressed by any competitor, that is a natural platform for differentiation and can be a very powerful lever for success. This is especially true if the experience is something that your competition would have a hard time copying. In a rapidly maturing market, focusing on customer needs that your business is uniquely suited to provide may help secure some long-lasting competitive advantages.
Business strategy alignment
At the beginning of this book, we talked about understanding your business context and goals and determining a set of target customers to focus on. At this stage, it’s also important to put on your business hat and make sure that the stories you prioritize resonate from the business, marketing, and sales points of view. Your marketing or sales experts will have data and opinions about which end-to-end scenarios are most saleable and most requested by customers, which ideas will benefit the most from network effects or word of mouth, or which are most conducive to feature in a catchy marketing campaign or social-network promotion. Depending on your business plan, any of these could be crucial input for prioritization.
Bottom line: Pick a few
It’s worth reiterating: no matter how you prioritize, resist the temptation to choose too many stories to move forward with. Pick a few that you can focus on so that you have the time and energy to iterate and fine-tune all the details with continuous customer feedback and deliver a high-quality solution in the end. One of the phrases we find ourselves repeating to teams and leaders all the time is: “Do a few things really right.”
Deep dive: Writing scenarios
Writing down real-world customer situations in the form of scenarios is a particularly effective way to frame the kind of problems that software is trying to solve. We recommend that you use scenarios as the primary description of the problems you will tackle, and then allow prioritization conversations to happen and a plan to emerge. As the Fast Feedback Cycle progresses, a small number of scenarios will form the backbone of the plan that the engineering team will work against throughout the development process.
Scenarios answer four key questions:
Who are we building this solution for?
What specific need or opportunity does this customer have?
Why does the customer care about this?
How good does a solution need to be in order to delight this customer?
The previous stage in the Fast Feedback Cycle, observing customers, gives you the raw material needed to answer these questions. If you’ve diligently done the work in that stage, you will have distilled a set of customer insights from your research data. You can now use the scenario technique to capture and communicate these customer insights in a durable way to use during the rest of the process.
This section provides a deep dive on the SPICIER scenario technique, including information about how to write a scenario, what makes a good scenario, and some tips and tricks for getting the most out of the scenario technique.
A good scenario is SPICIER
Several qualities of a good scenario can be used as a checklist to help ensure that you’ve covered your bases. These qualities form the anagram SPICIER, which is why we sometimes call narratives of this format SPICIER scenarios.
S: Tells a narrative Story
First and foremost, a good scenario is told as a narrative story. That is, it has a beginning, a middle, and an end. This means you should use sentences and paragraphs to write your story, not bullet points. The customer insights you distill from your research make for a good set of bullet points—and you should keep those. But now you are after something different. The job here is to develop those insights into a narrative about a real-world situation, ideally one you observed in your research. It’s important to note that the story format helps you catch ideas that just don’t hang together, that have something missing or don’t feel real. A good, credible story that captures a viable opportunity or customer problem should resonate well with customers—it should sound like it is telling the truth. The customer’s reaction to the story should be, “Yes, you understand me. Right on—please make this happen.”
P: Includes Personal details
Next, a good scenario includes a few relevant personal details about the target customer that help you understand who the customer is, what he or she cares about, and why the customer is in this particular situation. It is often through these personal details that you evoke the empathy for the customer that is so essential to a good scenario. However, resist the urge to add personal details purely for humor or human interest. Be sure that the details you include tie directly to the customer’s needs, motivation, or purpose. Details that illustrate the customer’s motivation are often the most helpful. However, generally speaking, the shorter your scenario the better, so mention only the most essential personal bits.
I: Is Implementation-free
This is perhaps the most important quality of a good scenario. It should not include any details about how the product, service, device, technology, or platform will actually work. As we discussed earlier in this chapter, adding implementation details is the single biggest mistake people make when writing any kind of framing, including scenarios. Having implementation details in a scenario makes it less likely that you will consider other, potentially differentiating approaches to solving the problem and makes it more likely that your scenarios will become out of date.
C: Customer’s story, not the product story
A good scenario is a story about your customer, not a story about your product or technology. It’s a story about Ken or Margie or Court and their real-life situations as small-business owners, landscape designers, or struggling artists. A scenario is not a story about a new tablet device or a narrative about Microsoft Team Foundation Server or a tale about Ruby on Rails. In fact, you might not need to mention a specific product or service or brand name for a scenario to be valid and useful as a map for your team. The focus should be on the customer’s situation, told from the customer’s perspective.
Remember earlier in the chapter when we defined framing, when the camera zoomed out from a person standing at the airport ticket counter to show more and more detail about her end-to-end situation—waking up early and getting stuck in a traffic jam before she started waiting in line to check in? When you describe the customer’s context in a scenario, you should zoom out and include just enough detail about the overall situation that you can then develop empathy and see the problems from the customer’s point of view.
Tip
Using the first-person when you write a scenario usually doesn’t make practical sense. Almost every team will have multiple target customers, and writing your scenarios in the third-person helps everyone remain clear about which customer each scenario focuses on. It’s also possible that you will end up describing more than one target customer in a single scenario, so you need names to keep everyone straight. For instance, imagine a scenario about the interaction between the director of marketing and an external ad agency.
I: Reveals deep Insight about customer needs
The best scenarios are the ones that highlight a deep insight about your target customer, preferably one that your competitors haven’t noticed yet. Identifying a need or an opportunity ahead of your competition (and developing a good solution for that need) is a great way to achieve differentiation in the market. It’s even better if you can develop that solution in a way that is not easily copied, thereby giving yourself a bit of a moat against fast-following competitors.
Mindshift
Insight spotting is not easy. Recall from Chapter 5 that a lot of observation and synthesis is needed to reveal patterns and insights. The moment you finally see a pattern and can explain why it happens might feel like a sudden flash of intuition, but that moment comes only after you have been wallowing in customer data for some time. Insights may seem completely obvious with 20/20 hindsight, but they are rarely easy to spot in the first place. If you are lucky enough to have a talented insight-spotter on your team, remember to appreciate how buried an insight was before the spotter brought it to light, and how much work went into identifying and articulating it. Also, if you do happen to have any talented insight-spotters on your team, be sure to reward them and keep them around—this is a valuable and somewhat rare skill.
You could write an infinite number of potential scenarios, so where do you start? Your task is to focus on those that are likely to make the biggest difference for your customers, and for your business. If you find yourself writing boring scenarios about people’s humdrum lives, chances are you’re missing an opportunity to really delight your customer. Remember that building something useful and usable usually isn’t enough in today’s competitive marketplace. Even if you are working on a fairly straightforward experience, you still want to strive to do it in a way that will take your customer to a high level of emotional delight.
In general, you should write a single end-to-end scenario for each insight you target. Trying to address more than one insight in a single scenario usually makes the scenario unwieldy, and that makes it hard to know what to optimize for and how to measure success. However, if you have a particularly meaty or complex insight, or a couple of distinctly different cases that must be optimized, it’s entirely possible that you’ll end up writing multiple scenarios to address various aspects of that one insight. In Chapter 11, we’ll cover more about how many scenarios to write, at what level to write them, and how to manage a portfolio of scenarios.
So where do you focus? Prioritize scenarios where you have an opportunity to solve a customer’s problem that is already emotionally charged, where a fundamental human need is attached, or where you can tap into a strong customer motivation.
E: Includes Emotions and Environment
Moving toward your North Star is all about delighting your target customer. If you’re aiming for an emotionally delightful experience, you better be clear about what kind of emotion you’re trying to evoke with each scenario you undertake, and be sure that your metrics are aligned to measure whether you actually achieve that response with real users. Not every single scenario needs to be about a magical, gee-whiz kind of experience. Sometimes what the customer desires is simply to get the task done quickly and efficiently, especially if the task occurs multiple times per day and performing it smoothly and with zero hassle is itself emotionally satisfying. When considering a portfolio of scenarios, however, you want to think about which ones will be the amazing experiences that will surprise your customer in a delightful way, and which others will aim for an experience that’s more sedate—“Check, got that crossed off my to-do list.” This should be an intentional decision, part of the strategic design of your product and something you will measure and track as the engineering process continues.
We also add one more idea into the letter E, which is that you need to include enough details about the customers’ environment that you understand the context of their situation. Where are they? What tools do they have available to them? What constraints are they working under? Again, the point here isn’t to fill the story with arbitrary details but to include the environmental and contextual factors that will have a material impact on how the story is understood and what the shape of the solution might take. For instance, you could tell a story about an operations engineer’s challenges in managing a data center, but the solution you build to address those challenges might be very different if that data center contains 300 servers instead of 30,000. This kind of context can provide important constraints about what scale the eventual solution should be optimized for.
R: Based on Research
Finally, it’s essential that a scenario be based on real research, not on hearsay, assumptions, or biased viewpoints. Most certainly, do not write a story about the problems you would like to see solved, unless you are quite certain that those problems are shared by your target customer. Remember that you are not the customer, so be sure to climb into your customer’s shoes (take yours off first!) when you write your scenarios and consider what the world looks like to your customer. If you are following the Fast Feedback Cycle and have already spent some time observing your customers and distilling key insights from those observations, this one is a no-brainer. However, it is so easy to lapse into believing that you already know what this customer needs—“It’s obvious!”—that it bears repeating that you should always stay rooted in research with real live customers—not proxies, not assumptions.
Anatomy of a scenario
While there is no rigid format for a scenario, a standard formula has emerged that many people find to be a helpful starting point. Schematically, it looks like this:
One-line headline
Introduction: Who is the customer? What motivates him or her?
Situation: What is the specific, real-world situation where there is a need or an opportunity?
<magic happens>
Outcomes: What specific outcomes has the customer accomplished? What are the key metrics for success?
Practically speaking, a scenario ends up having a two-paragraph format, where the first paragraph introduces the customer and the customer’s situation, and the second paragraph describes the outcomes.
It’s a bit goofy, but most people do find it helpful to write <magic happens> (or sometimes <skip the implementation details>) between the paragraphs as a tangible reminder to skip the details about how the product will work. You might be amazed at how well it works to have these two words as part of the team’s vocabulary. Saying it out loud takes the pressure off teams so that they don’t think about solutions right away. They give the team permission, at least for a brief period, to focus on customers and their needs, to spend time thinking deeply about what situations might give the team the best shot at delighting customers. Adding <magic happens> allows the team to put all the work of creating, building, and testing code into a box that can be dealt with later (albeit soon).
Here’s another way to think about it. Composing a scenario is like writing the first paragraph and the last paragraph of a 10-page story. You write a great first paragraph to introduce the characters and the setting and the core problem. Then you skip to the last paragraph on page 10 and give away the ending. Everything in between—the magic—is your service, your device, your product, your solution, which will magically solve the customer’s problem so well that you will achieve the outcomes. But at this point in your first iteration of the Fast Feedback Cycle, you don’t know exactly what the solution is. Sure, you have some ideas, but at this stage you’re being mindful to keep your options open, to give yourself the best possible chance of coming up with a game-changing concept. The next stages in the Fast Feedback Cycle, and the subsequent iterations around the cycle, are all about helping you write the rest of that story, to fill in the details of exactly how the magic will happen. Don’t worry. We’ll very quickly get to building creative ideas and solutions in the next step of the Fast Feedback Cycle. Just not quite yet.
Headline
It is important to write a memorable, one-line title or headline to capture the essence of each scenario. Practically speaking, this one-liner will be used a lot, so it’s worth putting some effort into making sure that it is catchy and easily remembered. You will need to refer to a scenario in shorthand in multiple places; for instance, in your work-item tracking tools, bug database, and scorecards, or when discussing a scenario in email or in a hallway conversation. Strive to write a title that captures the essence of the customer problem you are trying to solve, such as “Norman’s daughter gets sick at school” or “Marina worries about the quarterly tax filing.” Some teams find that standardizing scenario titles by using the Agile user-story format or an “I can” statement works well. No matter what format you use, the title should be focused on the customer need and not on the product functionality.
Introduction
The scenario’s introduction should identify a specific target customer for your product and provide enough personal and environmental detail that the engineering team can empathize with that person’s needs. A powerful way to create that empathy is to explain the customer’s motivation for doing this task in the first place. The introduction should answer questions such as:
Who is the target customer for this scenario?
What is the customer’s emotional state (frustrated, angry, anxious, confused)?
What is the customer’s motivation?
An example might be something like, “Sarah has just begun working as a new nanny. The children’s mother has left home on a business trip. Sarah is nervous about how the children may behave with their mother away and is intent on doing a great job and making a good first impression.”
Situation
Next, you should describe a specific situation in enough detail to illustrate the key constraints of what a good solution would need to address. The situation should answer questions such as:
What specific problem does the customer have?
How big or complex is the situation?
What other things will the customer be doing at the same time?
What happened before and after this situation?
Resist the temptation to write about a general problem—the team needs enough specific details to actually land on an optimal solution, not just a “pretty good” general case. For instance, instead of writing a scenario about sending photos in general, write a scenario about sending three photos that the nanny just took of the kids to their mother who is currently on a business trip. This more detailed, specific description is much easier to design against and will help keep the whole team aligned. As we described earlier in the chapter, write a story about a canonical problem that can act as a “lighthouse” to represent a whole class of similar problems.
Outcomes
The last paragraph of a scenario should describe what the goal state looks like. When the end-to-end problem is solved, what will the outcome look like? What will the customer have accomplished? The outcomes paragraph answers questions such as:
What specific outcomes has the customer accomplished?
What are the best metrics to measure the success of those outcomes?
What does the solution need to accomplish for this customer to be delighted?
What is the customer’s emotional state at the end of the experience?
As part of the outcomes, it’s essential to include a specific metric that pinpoints a clear goal to optimize the solution around, especially if there is a key tradeoff to make. For instance, is it more important for this customer to finish a complex task in 5 minutes, or will the customer be more satisfied if the task takes 10 minutes to complete but he sees some progress within the first 30 seconds? Is it more important for this customer to feel safe that she won’t get spam or for her to feel like she will never miss something important? Once you settle on a key metric or two and start measuring against them, those metrics will serve as the primary indicators of how close this scenario is to being done, and they can be tracked throughout the cycle as a scorecard benchmark. We’ll discuss scorecarding in more detail in Chapter 11.
Scenario tips and tricks
The basic idea behind writing scenarios is straightforward. However, when you first start writing your own scenarios, you are likely to run into a few problems. This section points out some of the most likely issues you will run into and suggests some specific tips for how to avoid common pitfalls. At the end of this section, we included several sample scenarios demonstrating a variety of customer types, situations, and scopes.
What’s wrong with this scenario?
Let’s take a look at a few hypothetical scenarios. This first has some problems. Read through it and see whether you can identify the ways in which this scenario isn’t SPICIER.
Gene regularly checks the amount of free disk space on servers that he manages. Currently he performs this task manually. He has to write a script for this task, but he is not a programmer and his scripting knowledge is limited. He opens a new script editor from the desktop. He immediately finds a Help button, which opens a help file describing how to get started. Within five minutes he can write his first script that runs on a local machine. When he tries to run it on multiple machines, however, he sees a red error message that the task failed and a line number for the error. He retypes one letter in a server name to run the task successfully.
The first thing you probably noticed is all the implementation details—“He opens a new script editor,” “finds a Help button,” “sees a red error message . . . and a line number for the error.” This scenario is brimming with implementation details. If you’re unsure whether something is an implementation detail, ask yourself the question, “Who says the solution has to work this way?” If you can come up with a credible alternative, you’ve spotted an implementation detail that doesn’t belong in the scenario. In fact, once you take the implementation details out of this example, not a whole lot is left. But other things are wrong with this scenario as well. What else did you notice?
Did you find yourself wondering who Gene really is and why he cares about free disk space on his servers anyway? The scenario is missing personal details about Gene that would give you a picture of his company or his role or how big a part this scenario plays in his overall job. Is it Gene’s full-time job to manage these servers or is it something he does in between service calls? The scenario is also missing the context of how big this company is—how many servers is he managing? Is it 2, 200, or 20,000? The solution might be quite different depending on that scale.
The scenario also doesn’t convey much emotion. Is Gene frustrated? Just plodding along? How does he feel when he finally gets his script working? Is he elated or just confident that he can move on to his next task for the day? Will he be rewarded if he succeeds, or is this a task hardly anyone notices unless there is a problem?
This scenario isn’t all bad, however. On the plus side, this scenario does provide some nice insight into Gene with the fact that he doesn’t like to write scripts, which is an important personal detail that would surely influence solution ideas.
A better scenario
Here’s another version of the same scenario, rewritten to be SPICIER. Note how it avoids including implementation details yet still paints a vivid picture of Gene and his needs in a way that everyone on the team can understand and empathize with.
Gene learns how to automate
Gene, a system administrator at an online bank, must continually check the amount of free disk space and verify that logging is working on all 200 web servers. The bank’s regulatory and compliance policies require extensive logging, and failures are a serious violation. Currently he performs this task manually several times a day. He wants this to be faster and more automatic, but he is not a programmer and he struggles with the few scripts he inherited from his predecessor. He is never totally sure if the right logging occurred.
<magic happens>
Gene discovers a new way to easily automate a common IT task and finds it straightforward despite his limited programming background. Within five minutes he is able to automate his first task, checking free disk space and logging, on a local machine. But when he tries to run it on multiple machines, it doesn’t work. However, it helps him with troubleshooting, and within an hour he is able to check free disk space successfully across his entire cloud with a single keystroke. Gene is pleasantly surprised at how easy it was to achieve such a time savings in his day-to-day work and is confident that logging is happening consistently across the cloud.
Let’s run through our SPICER checklist.
S Yes, this is told as a story in the standard two-paragraph format.
P Yes, this includes personal details about Gene, his company, his role, how often he needs to perform this task, how many servers he manages, and his limited programming knowledge. These personal details help the team empathize with Gene as well as have a common understanding for assessing what types of solutions might work well for him and which would not.
I Yes, this scenario is implementation-free. It uses general language such as “automate” to suggest a class of possible solutions rather than more solution-specific language such as “scripting” or “macros” or “C#.”
C Yes, this is a customer-focused story, not a product story. In fact, this particular scenario doesn’t mention any product or service name.
I Yes, there is a deep insight about Gene’s discomfort with programming, but his clear need is to find a way to automate a common maintenance task.
E Yes, we see Gene go from struggling to get scripts working in the past to finding it straightforward and being pleasantly surprised. And we see that we will be optimizing our solution for Gene’s environment of 200 servers.
R Well, you’re going to have trust us that this scenario was based on customer research. (Actually, a variant of this scenario was used in the development of one of Microsoft’s server products.)
Can you spot the implementation detail?
Pop quiz! Which one of these phrases from a scenario about Gene is surely an implementation detail?
Gene uses Windows Server to . . .
Gene uses the drop-down to pick the right doc.
Gene has a mobile phone and a laptop.
The obvious implementation detail is the middle one, Gene uses the drop-down to pick the right doc. Under no circumstances would mentioning a drop-down list belong in a SPICIER scenario.
But what about the other two items? If you squint, they do look something like implementation details. Are they? Let’s discuss each in turn.
The first, Gene uses Windows Server to . . ., mentions a specific product name. Is it okay to include a product, service, device, or brand name in a scenario? Yes, it is, and often this is very appropriate. But be sure that this is an intentional scoping decision. If you leave the product name out of the scenario, you are intentionally framing your problem more broadly—allowing for the possibility that you might define a new offering rather than stick to an existing product line, app, or service. On the other hand, if you include a specific—often already-existing—brand name in your scenario, you are making an intentional scoping decision to continue with your existing product line. With a narrower scope, you can discourage the team from wasting time considering options that are nonstarters from the beginning.
What about the last option, Gene has a mobile phone and a laptop? Is it an implementation detail to mention specific devices that your target customer carries with him? No, this is not an implementation detail. Having a laptop and mobile phone may be an important part of the customer’s environment. Through the inclusion of key environmental factors in the scenario, you inform the team about what platforms and tools the customer has on hand as the team brainstorms various solution ideas. And, of course, the fact that this target customer has both a mobile phone and a laptop must come from customer research.
Sometimes, you do need to include some level of implementation detail in your scenario because it is nonnegotiable. You may face specific, immovable constraints that are based on business considerations, technology investments, or even the schedule. If this is true, there’s no reason not to write the detail into your scenario—it simply becomes a constraint that the team will build around. This is the one case where it’s okay to include an implementation detail in your scenario. Just be sure you are making an intentional decision. Don’t let implementation details sneak in unawares.
Examples of big and small scenarios
Here are a few examples of SPICIER scenarios, including ones we’ve presented earlier in the chapter and additional examples that demonstrate some variation in format and scope. As we discussed previously, there are at least two levels of scenarios: higher-level, end-to-end stories that we call “big” scenarios, and lower-level, more task-oriented stories that we call “small” scenarios. Most teams find that they have stories to write at both levels, and they usually track them in separate categories or levels of a work-breakdown hierarchy. We’ll discuss that hierarchy in more detail in Chapter 11.
Let’s start with an example of a small scenario that focuses on a specific task, one we looked at briefly earlier in the chapter. This scenario is a particularly nice example of using a lead-user approach, which tells a story that demonstrates the most complex case the software should solve—being able to automatically standardize the format of mailing information, including international addresses, obtained from multiple sources of input.
Jessica’s formatting hassles
Jessica is a sales specialist at a small European company that sells wind turbines internationally. One of her main responsibilities is collecting sales leads and sending out about 500 sales circulars per month to prospects. Her information comes from multiple sources: some leads she finds on her own via the web, others are provided to her by outside services and given to her in Excel files, and some come from other employees via individual emails. Each source uses different country formats, conventions, and layouts—who knew there were that many different ways of formatting an address or phone number!
<magic happens>
Jessica can easily get the data compiled in one place and standardized in a consistent format, ready to print mailing labels, without any manual editing. Even better, she is able to repeat this task quickly in the future. Jessica is thrilled that she no longer has to spend countless hours manually editing her data, freeing her up to spend more time acquiring a greater quantity and quality of leads.
In contrast, here’s an example of a very big scenario, which is so broad in scope that it doesn’t even make sense to explicitly write <magic happens> because there will need to be innovative solutions at each stage of this cradle-to-grave experience. This big scenario, about acquiring a mobile phone, would need to be broken down into smaller, more-focused scenarios to lay out the specifics about each of the major stages: hearing about a new phone, researching it, purchasing it, learning to use it, sharing with others, and eventually upgrading to a new phone. However, a scenario like this provides the big picture for how these pieces should fit together to create an overall customer experience, and a big scenario like this can help align the team to create a meaningful whole. An alternative representation for a big scenario like this is a user-journey map that would show the same stages of customer usage behavior in a more visual format.
Margie loves her new phone
Margie, a 25-year-old college grad, is in the market for a new mobile smartphone. She never really liked her current phone—and doesn’t want to make another mistake by trusting a smooth-talking sales rep. One day, Margie overhears someone raving about a new phone. Then, the next day, she finds out her good friend recently purchased the same phone and also loves it. Margie asks her friend where she got it, and her friend shows off some of its best features. Margie trusts her friend’s recommendation, but double-checks Amazon reviews just to be safe, and decides to get this phone. She goes to her mobile carrier’s store and walks out 15 minutes later with a brand-new phone, and it has already downloaded her contacts and synced her email. Over the next few days and weeks, as she gets used to her new device and as she learns more about it, Margie runs into pleasant surprises that remind her how good a purchase this was. She eagerly tells her friends about her new phone, and several people also end up buying one and loving theirs. Two years later when it’s time to upgrade, Margie knows exactly what brand of phone to look at first.
Here’s an example of how you can break down that larger, cradle-to-grave experience by zooming in on one aspect in a small scenario. This small scenario expands on Margie’s purchase experience of buying a new phone:
Margie, a 25-year-old college grad, has done her research and knows exactly what phone she wants to buy. She walks into her mobile carrier’s store and goes straight to the display for the phone she wants. She is so ready to ditch her old phone; she never really liked it, and only got it because the sales rep talked her into it. Margie is determined not to let a smooth-talking salesman sway her again.
<magic happens>
Within 15 minutes, and with zero hassle, Margie walked out of the store with her brand-new phone in hand. Even better, no one pressured her—in fact, she felt supported with useful information that helped her finalize her choices. As she walked out the door, her new device was already set up with her contacts and email, and she placed a call to her friend from her new phone to tell her about her purchase. She couldn’t wait to go home to play with her new toy.
Now let’s take a second look at the scenario about getting stuff done in the grocery line, which we presented earlier in the chapter. This is another example of a small scenario that makes use of a lead-user situation—one that represents the most complex, longest path that a user would expect the system to handle. If you can build a solution that handles this complicated scenario smoothly, you’re in good shape for many other, easier cases—such as just sending a quick email or checking a schedule—to make the most of a couple of free moments anywhere.
Josephine gets stuff done in the grocery line
Josephine is a busy mom of two school-age kids who has a dog and is always on the go. She feels like she never has enough time. Just yesterday she almost left her son at an empty soccer field when she missed the coach’s email that practice was cancelled. Josephine is standing in the checkout line at the grocery store and realizes that she is going to be waiting a few minutes. She has so much to get done today and doesn’t want to miss another important message or deadline. Could she get a few things done while she waits?
<magic happens>
While standing in line for six minutes, Josephine was able to check off a bunch of items from her to-do list: pay for her kids’ music lessons, RSVP to a party (after checking that she and her husband are available that evening), schedule an appointment with the vet, answer her husband’s text message to assure him that she did buy milk, scan her email to learn that her son’s soccer practice was cancelled again this afternoon, and even squeeze in a quick peek at her favorite game, AlphaJax. The time waiting in line flew by. Josephine felt like she was able to maximize every second to help stay on top of her busy life and was able to give her full attention to her kids when she met them at the school bus later that afternoon.
Here’s another scenario that was presented earlier in the chapter. It’s a good example of a scenario that involves a customer in a business or enterprise environment. The big insight from customer research that drove this scenario is that getting something to work fast, albeit imperfectly, is crucial scaffolding to helping a nonprogrammer along the road toward learning to automate. Without that quick success, this system administrator is unlikely to stick with the task long enough to see it through, no matter how well the system guides him.
Gene learns how to automate
Gene, a system administrator at an online bank, must continually check the amount of free disk space and verify that logging is working on all 200 web servers. The bank’s regulatory and compliance policies require extensive logging, and failures are a serious violation. Currently he performs this task manually several times a day. He wants this to be faster and more automatic, but he is not a programmer and he struggles with the few scripts he inherited from his predecessor. He is never totally sure if the right logging occurred.
<magic happens>
Gene discovers a new way to easily automate a common IT task and finds it straightforward despite his limited programming background. Within five minutes he is able to automate his first task, checking free disk space and logging, on a local machine. But when he tries to run it on multiple machines, the task fails. However, it helps him with troubleshooting, and within an hour he is able to check free disk space successfully across his entire cloud with a single keystroke. The system administrator is pleasantly surprised at how easy it was to achieve such a time savings in his day-to-day work and is confident that logging is happening consistently across the cloud.
The next scenario targets a developer who is looking for a better way to take advantage of multicore and multiprocessor machines. It’s very high level and could be considered a big scenario or a user promise. This scenario (or one just like it) provided direction to the Microsoft Parallel Computing Platform team when it was figuring out how to make parallel computing easier to access, while avoiding the traditional pitfalls of using multithreaded, parallel code. (More of this design story is told in a sidebar in Chapter 8, “Building prototypes and coding.”)
Mark writes robust parallel code
Mark is a senior developer at a large software company. He’s been a tech geek his entire life; exploring new technology is both a passion and a hobby. It was a natural decision for Mark to get a computer science degree and land a job as a programmer. Mark enjoys staying current on the latest programming languages, tools, and trends. He prides himself on being able to learn and adopt new techniques quickly. As such, Mark places a high value on using the right tool for the job. Recently, he’s been reading about new parallel computing techniques. He sees the benefit of getting the most out of multiprocessor machines, and he’d like to figure out how to use parallel constructs in some of the server-side components he’s responsible for. But he knows that these techniques can be difficult to use, that they’re error prone, and that the subtleties of writing robust parallel code make it very time-consuming. In the past, he’s not been willing to make the complexity versus value tradeoff that parallel computing has historically required.
<magic happens>
Mark finds a beta version of a parallel computing engine and API for the platform he’s using. He downloads the beta and finds immediate benefit by simply decorating his code with some very simple constructs. His new parallelized components are on average 20 percent faster, and after rather extensive testing, Mark has not been able to detect any new bugs that result from parallel issues. Mark finds this to be very promising and reads more of the technical documentation. He discovers that the new parallel API provides customization points for him, in exactly the places where he thinks he’d like to have a bit more control over the behavior of his newly parallelized code.
The next scenario about George has a smaller scope than the scenario about Mark. This small scenario was subsequently broken down into a handful of user stories that were then prototyped and eventually coded.
George scales an existing application
George, a professional developer with expertise in the C# programming language, is fixing the responsiveness and scalability of an existing application. The application has a rich client UI that must remain responsive in the face of calls out to a server-side service. This service handles requests from a multitude of users concurrently and must achieve high scalability on a single box in order to best minimize hardware costs. The code is currently asynchronous to some degree, but the UI freezes now and again for various operations. The client code will run on various desktop machines, from single-core to quad-core, while the server code runs on manycore boxes. George is a longtime user of the ThreadPool and has some familiarity with the Task APIs in .NET 4.
<magic happens>
George easily improves the asynchrony of his application with more readable, functional, and maintainable code. Perf results show that the code can accomplish more in less time. He’s proud of himself for the improvement to the architecture and eager to highlight his perf and scale gains.
Frame stage: How do you know when you are done?
The big idea of the Frame stage is to capture the essence of the customer’s end-to-end experience—typically by writing specific customer stories called scenarios—before you start to work on solutions. Scenarios give the team a map that keeps everyone focused on solving the same problem and provide a way to check against the original customer goals all the way through to release. Embedded metrics create additional infrastructure for objective accountability and for tracking of both perception and performance goals.
Regardless of which techniques you use to frame your team’s areas of focus, you know you are ready for the next stage when you have generated:
A prioritized list of several customer scenarios (or other framing).
One or two key metrics and targets for each scenario to track throughout the project.
Remember that your goal in the Fast Feedback Cycle is not to do a stellar job at each individual stage, but to do just enough and move on, relying on the fast iterative loop to let you know whether you’re on the right track and what to focus on in the next iteration. Most teams spend too long writing and fine-tuning their scenarios. Instead, make a reasonable effort, prioritize the ones that seem most promising, and move on.
You don’t have to be sure about your scenarios. In fact, most teams find that their first set of scenarios are not quite right—it’s only in iterating them through the rest of the cycle that you realize how to fix them. Working longer in the framing stage won’t solve the problem. You need customer feedback to see one layer deeper into the onion and realize that the real customer problem isn’t quite where you thought it was.
Now it’s time to move on and start thinking about solutions to solve the problems framed in these scenarios.
Notes
1. Eric Ries, The Lean Startup (New York: Crown Business, 2011), 128.
2. Clayton M. Christensen, Scott Cook, and Taddy Hall, “What Customers Want from Your Products,” HBS Working Knowledge, January 16, 2006, http://hbswk.hbs.edu/item/5170.html.