Scenario-Focused Engineering (2014)
Part II: The Fast Feedback Cycle
CHAPTER 4 Identifying your target customer
CHAPTER 5 Observing customers: Building empathy
CHAPTER 6 Framing the problem
CHAPTER 7 Brainstorming alternatives
CHAPTER 8 Building prototypes and coding
CHAPTER 9 Observing customers: Getting feedback
CHAPTER 10 The importance of iteration
Chapter 4. Identifying your target customer
The chapters in the first part of this book explored customer delight. Today, customers expect and demand solutions that solve their real-world problems; they don’t want a pile of loosely connected features and capabilities. In the current market, you need not only to deliver complete experiences, but to do so while connecting with your customers at an emotional level.
We introduced the Fast Feedback Cycle as a structured approach to building end-to-end experiences in a customer-focused, iterative way, with high efficiency and minimum risk. But how do you know which end-to-end experiences to build in the first place?
In this chapter, we go into detail about the most important prerequisite to the Fast Feedback Cycle: identifying your target customer.
Why you need a target customer
Before you can build an end-to-end experience, you need to know who you are building the experience for and what that customer needs—you need a target customer. You need to understand your target customer deeply enough to know what problems that customer faces, to figure out whatmotivates that customer, and to discover what a truly outstanding solution would look like from that customer’s point of view.
You need to study customers in depth to start developing this understanding. This raises some immediate questions: Which customers do you study? If you have time to study only a few of them in depth, how do you ensure that the customers you talk with aren’t outliers and aren’t going to lead you astray? Who are your customers, anyway?
It turns out that selecting a target customer (and getting an entire team aligned on this customer) is a harder challenge than it first appears. Your current product likely serves many different customers who have different needs, motivations, and desires. For instance, Microsoft Office is used by many types of people: soccer moms organizing the snack schedule for weekly games, college students doing group projects, small-business owners promoting their businesses, research scientists capturing their findings, and, of course, knowledge workers in large enterprises. All of these market segments create documents, read email, and possibly also give presentations or make calculations in a spreadsheet. However, the situations in which they use this functionality differ substantially, as do the features they rely on the most. College students do a lot of group projects, so they want seamless ways to share documents, communicate status, and ensure that they don’t accidentally overwrite one another’s work. Scientists, on the other hand, care most about being able to embed graphs, charts, and mathematical equations in their research papers, and small-business owners get significant value from the ability to produce high-quality marketing collateral without having to hire an expert. All these groups are using Microsoft Word to do their work in this case, but the ways in which they use Word vary quite a bit.
You need to focus
It’s tempting and natural to want to do everything for everyone. A common approach to product development is to start by building a flexible, general-purpose tool that can be used by a wide variety of people, figuring that it will fit 80 percent of people’s needs and that will be close enough. This one-size-fits-all approach worked pretty well in the first couple of decades of the personal computer industry, when building a generally useful and reasonably usable solution was enough to distinguish yourself from competitors.
Mindshift
Learning from fast food. Even the stalwart McDonald’s has realized that a one-size-fits-all approach no longer works with today’s consumers. The company has shifted after a long history of its franchises using identical menus in cities around the world to introducing localized menus that reflect local needs, customs, and regional foods. From the McBaguette in France, to red-bean pies in China and Big Rösti in Germany, local specialties are the bestsellers that are driving McDonald’s international success and are largely why McDonald’s continues to survive overseas while Burger King has stalled.1 McDonald’s franchises in each locale are allowed to focus on what works for their specific market. The company has realized that today’s customers expect more than the standard burger-and-fries formula that worked for generations.
However, the general-purpose-tool approach isn’t really working anymore. Inevitably, you hear from customers that your default solution isn’t quite hitting the mark—they’re asking for this feature and that bug fix, compatibility with such-and-such format, and the list goes on. Product teams try to squeeze in as many of these requests as possible—a configurable parameter for this need, a fix for that issue—but even when you give customers exactly what they asked for, somehow it’s still not enough. They might even start complaining that your product is now too complicated.
One approach to finding the next breakthrough solution is to “throw spaghetti at the wall and see what sticks.” When it’s not clear what will resonate with users, you opt to ship a bunch of different things and hope that at least one of them will end up being a runaway success. While you might get lucky, this approach is inefficient and likely means that you’ll divide your team’s time across many initiatives, most of which will not pan out. The sentiment here is good—be experimental and try different things—but the key is to find ways to experiment in a cheap, fast way that lets you quickly narrow in on which ideas are working long before you invest in production code and the full release process.
Whether your development philosophy is more traditional, or—more likely these days—uses some more Agile methods, it usually boils down to a protocol that looks something like this:
Gather up a long list of all the possible things you could do. These ideas will come from all over: the engineers on the team will have suggestions, but you’ll also have customer requests, new concepts generated in brainstorming sessions, and, of course, the myriad stuff that didn’t make the cut in your last release cycle.
Next, do a rough, T-shirt-size cost estimate (XS, S, M, L, XL, XXL) of how expensive each item would be to build. Then, debate that list to end up with a stack-ranked, prioritized backlog of work items.
Finally, draw a cut line based on the number of man-hours available, and that’s the list of stuff that you attempt to get done.
With this approach, there’s never a shortage of ideas, but you can easily start arguing about the list because you don’t have time to do everything. With rare exceptions you end up arguing about this feature versus that one—or this user story versus that one—and not about end-to-end experiences. It’s easy to win a battle but lose the war, ending up with a plan that has lots of features—but without some intentional planning, very few of those features will naturally thread together into a complete end-to-end experience that delights customers.
What’s worse is that throughout the product-development process, you’ll find problems. Despite best intentions and a perennial feeling that “this time will be different,” software projects are consistently hard to schedule and always take longer than you think. Estimates are overly aggressive, problems are harder to solve than you expected, and integration issues that no one anticipated pop up. Faced with a hard deadline when time to market is essential, you can be forced late in the cycle to cut features that just aren’t coming together. What might even have started out as an end-to-end experience in the planning stages is weakened by the time it’s released because the middle of your beautifully planned solution has been cut, leaving the customer hanging.
The trouble is that it’s all too easy to reach the end of a big development push and hear that the marketing team is having a genuinely hard time figuring out how to talk about your new release. They just don’t have much to say. None of the individual features you built are big enough or important enough to make much of a splash. The team did a lot of work across the codebase, fixed a lot of bugs and resolved a lot of open issues, and perhaps even substantially improved quality, but looking back, nothing really stands out.
We call this phenomenon shipping a “peanut butter” release—you spread a thin layer of peanut butter across your solution, and, unsurprisingly, no customer gets particularly excited about the result—nothing all that interesting or remarkable differentiates your offering from your competitors—or even from your previous version. From sprint to sprint, this kind of gradual, iterative improvement can be acceptable. But if you’re trying to make a big splash with customers and end up shipping peanut butter, the results can be quite disheartening.
You can’t optimize for everyone
Actually, it’s even more complex than that—even with unlimited time and resources, building a solution for all potential customers is an unsolvable problem. Different types of customers often have conflicting needs. A soccer mom receives five email messages a day and would prefer a super-simple view in which to read her email without any confusing bells and whistles. A knowledge worker receives 150 emails per day and regularly uses folders, automatic sorting rules, and message flagging to stay on top of his daily workload. How do you build one email service that optimizes the experience for both usage patterns?
Without building a complex rat’s nest of modes (or an entirely different offering) for every user situation, it’s not possible to optimize a solution for every type of user. If you can find a win-win solution, of course that’s ideal, but usually you find yourself with an unsolvable constraint equation. If you optimize for user A, you end up making it awkward for user B. If you optimize for user B, user A’s experience isn’t as smooth. If you aim for something in the middle, no one gets what they really need. You just can’t make everyone happy all the time.
It’s clear that if you want to achieve true delight for anyone, you have to focus. Thankfully, from past experience, you know that you can build a much higher-quality solution if you start with a clear, focused problem statement—so there is hope. But, as we said at the start of this chapter, who exactly should you focus on? How do you pick?
Carryover gives you focus and breadth
A concept we call carryover has proved to be very helpful to teams for wrapping their heads around the toughest nut in all of this—how can you focus on a small number of target customers yet achieve the broad market penetration that you are likely hoping for? Many teams aspire to build a product that will have broad, mass-market appeal—whether that market is consumers, developers, enterprises, or small businesses. But, if you’re going for breadth, how can you possibly focus on a small set of target customers? It seems impossible.
Vocab
Carryover is achieving broad market appeal by focusing on and building a truly outstanding solution for a narrow target market, which then also appeals to a “halo” of similar customer segments.
A tale of two can openers
Let’s explore this conundrum by looking at a specific, albeit unlikely, example: can openers.
The can opener on the left in Figure 4-1 was designed by a small company named Swing-a-Way (which was acquired in 2005 by Focus Products Group International). It was designed to be a general-purpose tool for anyone who needs to open a can and is found in many kitchen drawers. The can opener on the right is made by OXO Good Grips. You may have recognized it by the chunky, black plastic handles that distinguish the OXO product line. This can opener usually sells for around twice the price of a Swing-a-Way can opener.
FIGURE 4-1 The can opener on the left was made by Swing-a-Way. The can opener on the right was made by OXO Good Grips.
What you may not know about OXO is that it was founded by a man named Sam Farber, a mechanical engineer whose wife had arthritis in her hands. His inspiration was to build kitchen gadgets that were highly ergonomic—gadgets that his wife could use comfortably. As OXO introduced its line of ergonomic products, a funny thing happened. The market reacted surprisingly well to the company’s innovative designs. It turns out that when you make a product ergonomic enough for someone with arthritis to use, it’s remarkably comfortable for most other people as well. Even though its design made the product more bulky—which meant it did not always sit flat in a kitchen drawer—the benefit that it brought far outweighed that downside for many, many people. So much so that OXO is able to charge a premium for its products.
Getting this carryover from a narrow target market (arthritis sufferers) into a much broader market (anyone who appreciates ergonomics) was always part of Sam Farber’s plan. The plan worked, and OXO has enjoyed strong business success. Since its founding in 1990, it has developed a portfolio of 800 products that are sold in 50 countries and has received more than 100 design awards.
Here’s another example of carryover—travel suitcases with wheels. It may be hard to remember a time when suitcases didn’t come with wheels, but those now-ubiquitous wheeled suitcases were first designed for pilots and crew members, who were constantly lugging bags around the airport. Even though mainstream consumers traveled much less frequently, the benefits of a small, portable travel bag with wheels were appealing enough that people were willing to buy a new suitcase for the convenience.
How does carryover work?
Carryover is the key principle that makes it possible to focus on a small set of customers but still achieve broad market appeal. Here’s how it works. Imagine that this oval contains all the customers who might ever use your service or buy your product.
What you want to do is pick a few very specific customers to focus on and mark each with a bull’s eye. Think of your target customers as the canonical cases around which you will optimize your solutions.
Now, for each of your target customers, you reason that if you fully solve their problems and make each specific customer truly, deeply delighted, there will also be a larger carryover population similar to that target customer who will also appreciate your solution. Your solution might not solve every one of these other customers’ needs, but the needs it does address are handled completely and delightfully, so those carryover customers are also pretty satisfied. The carryover population for one target customer may be small but perhaps financially lucrative. For another target customer, the potential carryover may be very large because there is a large population of similar people. The idea is that if you choose your targets strategically, it’s quite possible to get substantial market penetration by focusing on a few target customers who will give you the broadest possible carryover.
No, you won’t be able to nail every single customer’s needs with this approach, but you will be able to solve a lot of the most important ones. More importantly, you will be able to reach substantial market breadth while still providing clear focus for your team to ensure high-quality execution. And if you do your job right, the customers that you do reach will be those truly great customers we all dream about—the ones who are loyal, passionate, and truly love your solution because it solves some of their real-life, end-to-end problems in a completely delightful way.
Neuroscience break by Dr. Indrė Viskontas
Even before neuroscientists were able to peek inside the brain using neuroimaging, psychologists knew that the bulk of our decision-making computations were not available to our conscious minds. That is, most of the choices we make every day are the result of cognitive processes that are implicit, or outside our stream of consciousness. Indeed, the entire marketing industry is built on the observation that our decisions are often shaped by even the most subtle factors, like the music playing in the background while we shop for jeans.
Most of us remain blissfully unaware of the fact that conscious thoughts are only the tip of the iceberg, and what we feel is a rational, willful, and deliberate decision is actually the final step in a long series of calculations that our neurons have computed without our conscious help. In fact, more often than not, when we justify our reasons for having made a particular choice, we rely on the “interpreter” in our brain: the inner narrative voice that tries to make sense of our actions after the fact.
Neuroscientists first discovered the interpreter in action when they studied so-called split-brain patients—patients who underwent surgery to sever the connections between the two hemispheres of the brain to limit the spread of epileptic seizures. With these patients, neuroscientists could query each side of the brain independently, and they were shocked to find that when the right hemisphere made a decision, the left hemisphere, instead of admitting that it had no idea why the action was taken, made up a justification on the spot. Each of us displays the same type of confabulation—or “honest lying”—when we are asked to introspect and give a reason for why we made a particular choice. Study after study has shown that our interpreter weaves a narrative that makes sense of our actions, regardless of the actual reasons behind our choices.
In the past few decades, as neuroscience has permeated economics, scientists have begun to understand just how inaccurate our interpreter can be. In the 1970s and 1980s, the predecessors of modern neuroeconomists wanted to understand how shoppers chose between identical options. For example, in one famous study experimenters displayed identical nylon stockings on a table in a department store. They found that shoppers were more likely to choose the items on the right side of the table than on the left. But when the researchers asked the shoppers why they chose a particular set of stockings, the shoppers would talk about differences in quality, fabric, and other characteristics, never mentioning table position. Remember that all the items were identical.
In follow-up work, it became clear that the decision to buy is often driven by a gut instinct—an emotional or otherwise irrational reason that our rational frontal cortex doesn’t have access to. Because we think of ourselves as rational people, our interpreter finds an explanation in line with that view of our personality. This tendency toward a rational explanation for an irrational choice even permeates our dating life: in another famous study, subjects were shown pictures of people of the opposite sex and asked to pick which one they found more attractive. Using sleight of hand in a portion of the trials, experimenters actually switched out the choices so that the participant had to justify a choice that he or she in fact did not make. And in a large portion of these trials, the participants didn’t notice the switch and instead confabulated reasons for why that potential mate was more attractive than his or her partner. “I like her earrings” or “He has a nice smile,” they would say, when, in fact, that particular photo was rejected initially in favor of another.
From neuroimaging, patient work, and other techniques, neuroscientists are beginning to finally see just how much power our unconscious mind yields over our decisions and just how late our rational, thoughtful frontal cortex is to the party.
How does the nature of our brain wiring affect your choice of target customers? It should reinforce the importance of delivering a high-quality, emotionally desirable experience. Ironically, when you solve a few of the most pressing end-to-end needs of a customer in a way that is deeply delightful for the irrational, emotional part of the brain, that customer will be quite willing to forgive many transgressions.
For example, even after many years of releases, the iPhone still had deficiencies, yet it maintained an incredibly loyal fan base because of its seamless integration of music, apps, games, and communication in a single, ultraportable package, which has become a hallmark of Apple’s brand. Facebook’s privacy rules are complex and default to sharing more openly than we might ordinarily choose—but the dopamine hit you get from seeing the picture of your sister winning the 5K seconds after it happens far outweighs those problems for most users.
What you do extremely well in your solution seems to count a lot more in the customer’s mind than what you had to cut (despite the vocal complaints of a few power users who will try to convince you otherwise.) On the flip side, if you don’t address the essence of what the customer needs, every minor nit will become magnified. Figuring out how to tickle the irrational, emotional brain to achieve delight really matters.
It’s a complex ecosystem
So far we’ve talked mainly about end users, but they’re only one piece of the puzzle. The reality is that your ecosystem is much more complex. For instance, if you are writing a developer platform, who are your customers then? The developers using your platform or the end users who will use the applications that those developers write? What if you are selling enterprise software? Is your customer the IT manager who makes the purchasing decision or the knowledge workers who will use your software every day? Which one is more important? Whose experience should you optimize? Where should you invest your limited resources?
Most businesses have not just one type of customer but many customers—that is, many different types of people and organizations that they deliver value to—and those customers are almost always connected into a larger value chain or ecosystem. The end user is surely important, but in today’s markets, developer platforms, independent software vendors (ISVs), hardware vendors, service providers, and other partners can also play a big role in your ultimate success.
What is a customer, exactly?
Let’s settle on some definitions. For the purposes of this book, we’re going to use a very expansive definition of customer. A customer is any person, group, entity, company, and so on, that you need to interact with as part of the ecosystem of your business. Here are some common ones:
End users These people actually use the software and are usually the first group you think of when you think about customers. This group could include anyone from a consumer home user to a knowledge worker in a large enterprise. At the end of the day, if end users aren’t delighted with your solution, you will definitely have problems.
Purchasers and IT managers This group comes up frequently if you are selling to larger businesses in which the person who makes the buying decision (and often also owns the deployment, rollout, and support costs) has very distinct needs from the end-user knowledge workers who will use the product day to day.
Developers and ISVs Many ecosystems rely on having other developers or independent software vendors build on top of a particular platform. The availability of apps that you can purchase on all the major mobile platforms is a great example. Developer platforms are common in larger software teams, even in businesses that aren’t explicitly focused on building platforms per se, where, for example, a platform allows a crucial integration. Sometimes these developers are internal to your company—such as development teams outside your immediate workgroup. It’s just as valid to consider internal developers to be your target customers as to focus on external developers.
External partners Other business partners in your ecosystem can frequently be important target customers, whether they are mobile phone carriers, hardware vendors, cloud service providers, or others.
No matter what role these customer groups play in your ecosystem, all of them can be considered customers. Depending on your business strategy, any of these groups could be your most important (highest-priority) target customer.
Getting specific about customers
How specific do you need to be when deciding on a target customer? Can’t you just say that you’re building a product for consumer end users rather than business users? While that’s a great first-order decision, not all consumers are alike in their needs, motivations, and preferences (just like all developers aren’t alike). It’s obvious that different types of consumers have different needs—young and old, male and female, single and married, with or without kids, living in different parts of the world, and so on.
You need to consider finer-grained customer segments than just “consumer”: each target customer should represent a segment of customers who are reasonably alike in their core needs, motivations, and preferences. When settling on a target customer, you need to boil down that segment into an actionable, single customer profile that can be easily used and internalized by the engineering team. It’s hard to optimize for an entire group of people. It’s much easier if you build out a profile of one person and use that single person as the representative of the larger group.
Many teams find that developing a target customer segment based on behavioral or attitudinal aspects is more useful than developing segments based purely on similar demographics. For instance, “novice software developers” could be young or old, male or female, and from many different locales, but everyone in this category has very similar needs for an easy-to-use software development environment. Or, in a consumer space, “trendy socialites” may represent a wide variety of demographic stats, but they all share common attitudes, needs, and behaviors in the use of mobile phones, social networks, and other communication technologies.
Tip
As in all things, don’t make assumptions when thinking about customer segments; do your homework. Research is needed to understand the complexities of your market. Product planners, marketers, and other business experts are great people to lean on to help create a customer segmentation.
How many target customers do I need?
Although we often use the singular term “target customer” in this book, you will hardly ever decide to focus on a single customer—markets and business ecosystems are more complex than that. However, many teams have found tremendous benefit in explicitly prioritizing some customers in their ecosystem more than others, both for clarifying the strategic direction and to communicate that direction clearly to the entire engineering team. In the end, you are aiming to identify three or four specific customers who are central to driving your business—along with a crisp notion of priority or the interrelationship between them, including what kind of carryover you can expect to get from each to the broader market.
In our experience, three or four target customers seem to be the practical maximum for good results, regardless of the size of your organization, and very small teams may opt to focus on only one or two customers. Think of your target customers as the primary cases that you will optimize for, and be confident that you will get carryover into broader markets if you choose your targets wisely. There are some specific strategies for how to choose targets to maximize carryover that we’ll discuss in the next section.
Identify stage: Tools and techniques
Now that you see that having a clear target customer is important—and the complexity of the choices ahead of you—let’s talk about how you figure out who your target customer should be. The first step is to get some clarity about your business strategy because your target customer should be tightly aligned with it.
While this is not a book about business strategy development, we do have to begin somewhere. This section lists a few techniques to help you get started choosing a target customer and developing a strategic direction. Don’t get too hung up on this; you don’t have to have perfect answers. But you do need to make some big-picture assertions about what business you are entering and whose problems you are trying to solve.
In the rest of this book, we urge you to collect real data and to modify your plans as the problems you are trying to solve and the solutions you are building are brought more crisply into focus through iteration and learning. The data you collect as you iterate will help you fine-tune your choice of target customer, or may even point you toward a different, more lucrative target customer.
Develop a business strategy
The choice of target customers quickly becomes a strategic question. Typically, there isn’t only one possible answer: you have several viable target customers to focus on, each of which might be the key to your market success. What you should do is avoid the nightmare scenario in which you do a terrific job focusing on a target customer—and they indeed love your offering—but you find out much too late that they never had any intention of paying for your service, nor are they a particularly valuable target for advertising either.
Before your team spends any time writing code, it’s important to ask how you are going to make money, and which customers are key to making that plan work. While the specific process behind building a business strategy is outside the scope of this book, one thing is very clear: you must have a business strategy that is in sync with your choice of target customer.
Settling on a strategy is a tough decision, and since none of us owns a functioning crystal ball, you can never be certain which road will be the right one. It’s no surprise that when faced with this kind of situation, engineering leaders are apt to put off this decision. It’s not at all unusual for one person to have a gut feeling for one path, while a peer has data to suggest another one, and since both approaches seem viable, it’s hard to put the question to rest. Without clear direction, teams can end up executing against both strategies, or they ignore the business strategy altogether and instead focus on what seems to be a promising piece of technology. What results is an engineering team that is forced to operate in a world of shifting priorities—where the “most important things” are different depending on who you talk to. In a world of finite resources, this lack of clarity naturally causes a team to not execute particularly well on anything, and this is evident in the resulting solution.
Being clear about direction is important, and the responsibility sits with the team’s leaders. They must provide a clear strategic direction to guide the team’s work. For software engineering teams, one of the most tangible outputs of the strategy process is the decision of which target customers to focus on. Having a clear customer focus is an absolutely necessary precondition to delivering outstanding, high-quality end-to-end experiences.
So you know you need a business strategy, or at least a strong (and data-driven) idea about a market opportunity you want to pursue, but the question remains which strategy is actually the right one. There are so many factors to consider here, and this topic is well outside the scope of this book (and worthy of a book or two of its own!—we list a few of our favorite books on the topic of developing and iterating successful business strategies in Appendix C, “Further reading”). You must do your homework to understand the market, the competitive landscape, buying patterns, pricing models, trends, and the whole host of other factors that can affect your ultimate business success. We encourage you to seek the counsel of experts—though keep in mind that no one can predict the future.
Using the iterative approach described in this book will help you learn quickly whether your chosen strategy is working and will give you the feedback you need to change course before you have spent too much time pursuing a dead end. Especially when you’re establishing new business models, iteration is key—expect to get it wrong the first time and be willing to shift approaches when needed and figure out what actually works in the real world.
It’s no coincidence that the business strategy books we like share many similarities with the concepts underlying the Fast Feedback Cycle, especially with respect to the need to deeply understand your customer and then prototype, test, and iterate business strategies with real customer and market feedback. You may not pick the optimal strategy the first time, but as you iterate with customers, you will quickly learn and adjust. This doesn’t mean that you can go without a plan, however—it is critical to have an initial plan, test it, measure it, and then see how it did and adjust accordingly. You know, just like the scientific method.
Map out your ecosystem
Once you have identified a business opportunity you want to pursue and have crafted the beginnings of a business strategy, you need to prioritize and crisply articulate the customer segment you’re going to target. One way to better understand your customers and to help you decide which of them you want to target is to draw a diagram of your customer landscape. By doing so you can visualize the entire ecosystem and clarify the relationships and interdependencies between different customer types. Figure 4-2 shows three examples.
FIGURE 4-2 Three customer relationship diagrams: (left to right) a developer platform business, selling into enterprises, and a mobile phone business.
So which customer is really driving your market—who is holding the torch to lead the way? Which customer will give you the biggest leverage in the overall system? Is it the end user, who is demanding the service and will drive the market, making the intermediary developers and service providers merely cogs in the system? Or is the key factor the availability of apps on the platform, which means the developer is king and you should focus your primary efforts on enticing and retaining developers?
Multiple factors can easily be driving the market, and sometimes be in direct conflict with one another. Consider the mobile phone market. Who would you optimize for if you were entering that market today? Having a strong network of developers building lots of apps is crucial to attracting end users, but at the same time you also need a large, addressable market of end users to entice those developers to want to build on your platform in the first place. Will a large market of unique apps in fact be the best way to attract those end users, meaning you should focus on luring developers to your platform with a highly desirable developer experience? Or is having a beautiful, seamless user experience the key, so it matters less which apps are available or how many there are? These factors are clearly highly interdependent. But a third factor might actually be the most important—the availability of your device on different carriers, and perhaps even the pricing. Of all these complex factors, which one do you believe is the chicken and which is the egg, or must you split your energy and target both? Many paths are viable, and each represents very different business strategies.
This decision about who is driving the market will have a profound impact on your business strategy. It’s worth doing some careful analysis and thinking through what-if scenarios as you decide which of the customers in your ecosystem are really driving the market, who you are going to bank on, and how to prioritize your efforts between them.
Strategies for maximizing carryover
Earlier in the chapter you learned about carryover and saw that it’s theoretically possible to gain broad adoption by doing a great job for a few focused customers. You’ve also seen ways to gain an understanding of all the different customers who may play a role in your business, how they interact, and which of them may be more or less important to your success.
Obviously, you want to focus on customers who will be financially profitable and cull those who are unwilling or unable to pay for your solutions or are not valuable targets for indirect monetization approaches such as advertising. You may also find that particular customer segments are extremely profitable, so it can make a lot of sense to prioritize the needs of those segments so that you retain them as valuable customers.
Many times, though, you’ll have a lot of different kinds of customers who all seem to be equally important, and it can be very difficult to prioritize them. Here are a few strategies we’ve seen teams use to prioritize target customers in order to maximize carryover, which helps them maximize their breadth in the market with a minimum number of target customers to worry about:
The 80 percent case If your business is lucky enough to have an 80 percent case, where the majority of your users are alike and have similar needs, that’s a natural and obvious choice for a target customer. (No, it doesn’t have to be fully 80 percent of your customer base, just a large enough bucket to matter business-wise.) However, be warned that this situation isn’t particularly common—customer needs tend to be a lot more diverse than many may think.2
The influencer This situation surfaces in many different markets. The idea is to focus on a set of customers who are highly influential in your market. If you can get those influential customers to buy your solution, others will notice and follow. You can also approach this as a social strategy with which you focus on the users with the most connections or friends. Or you can focus on a high-profile customer with a lot of clout, where if that customer buys, others will trust your solution, too (that is, land the Mayo Clinic as a customer, and other smaller medical centers will likely buy, too). Focusing on getting great press reviews could be another approach, if those reviews will influence the buying behavior of others.
The lead user This is like the OXO can opener or wheeled-suitcase situation and is perhaps the most powerful approach. The lead user is a customer who has deeper or sharper needs than the rest of the market. Many other customers have some of these same needs, just not to as great a degree. As we mentioned, it’s hard to remember a time when suitcases didn’t come with wheels, but the first wheeled suitcases were designed for pilots and flight attendants, not consumers. A customer with arthritis needs great ergonomic products, but a user without that condition very much appreciates ergonomics as well. The novice developer needs inline SDK documentation as she is writing her first lines of code, but more-experienced programmers appreciate having the call signatures at their fingertips, too. One way to discover a potential lead-user opportunity is to study outliers in your population (novices, subject matter experts, people who use your tool in unusual ways)—their needs may be more obvious and easier to spot than the more subtle expression of those same needs in the larger population.
Tip
Beware the computer power user! Focusing on the computer power user is not a successful application of the lead-user strategy. The computer power user does indeed have deeper, sharper needs, but the rest of the population typically does not share any of those needs, so you should not expect much carryover.
The idea is to pick a set of target customers that will maximize carryover, and to be quite intentional about focusing on them. Which of these customers are the most important? Who is really driving your market, and therefore your business success? It comes right back to your business strategy. Whichever target customers you land on need to be 100 percent aligned with your business strategy.
Empower the team with a North Star
No matter how you develop your business strategy, or how you choose your target customer, your plan won’t be effective unless the entire team can pragmatically understand it and apply it in its daily decision making. From the perspective of the engineering team, the choice of target customer may be the most practical output of the leadership team’s decisions about business strategy.
Think of your target customer as your team’s North Star. No matter what decision team members make, large or small, every team member should always take a moment to look up and verify that they are still heading for true north—that is, building something that your target customer is going to find deeply delightful because it solves an important problem for that customer.
Why do you need a North Star?
Why is it important for the whole team to internalize your strategy? Because at nearly every step of the product development process, and in every layer of the codebase, individuals on the team will be making tradeoffs as the product takes shape. While the big decisions may get discussed thoroughly, many more small decisions will be made in the solitude of a developer’s office. Cumulatively, these small decisions can matter just as much as the big ones. Should this parameter be a user-configurable option or just a hard-coded, reasonable default? Is it more important to optimize this section of code for performance or for scale?
Consider this scenario about a late-night tradeoff. It’s 9:00 p.m., and your star developer is the only one left in the office; she’s on a roll and isn’t ready to quit yet. A question occurs to her: Is it better to optimize this algorithm for performance or for accuracy? She can argue the issue both ways in her head, but it comes down to whether the target user cares more about getting a complete list of search results or getting an initial result set as quickly as possible. Because she knows that the target customer is a small-business owner who is shopping primarily for price, the decision is easy—you need the full set to be sure you are returning the lowest-price items at the top of the list. If she didn’t know that, she could have just as easily coded the feature the other way or waited until tomorrow to bring it up in the daily standup.
It’s clearly not efficient to hold a meeting whenever a question comes up, and indeed that’s why companies hire smart, talented people who can make good decisions on their own. Some of these tradeoffs will be flagged as important enough for more formal attention from leaders, and spec and code reviews will provide a layer of review. However, many of these decisions tend to get made in the moment by relatively small groups or individuals. So, especially across a large project, it raises an important question: How will you ensure that these micro-tradeoffs are actually all aiming in the same direction?
Without some way to focus the team on a core set of goals, you risk having each person use his or her own best judgment when making decisions—but these decisions may not be aligned with one another across the project. For example, if I optimize my UI code for zippy responsiveness, but the underlying architecture is more focused on getting maximum throughput for a vendor’s API that has some inherent latency, I might be unwittingly working at cross-purposes with others on my team. Both decisions are reasonable tradeoffs in isolation, but together they don’t make sense. Multiplied by all the various decisions that need to be made across the architecture, platform, and user experience, this can result in an offering that seems a little muddy, like it was built by committee, without a clear vision or direction.
SFE in action: Rowing in the same direction
Panos Panay, Corporate Vice President, Microsoft Surface
Have you ever been on a team where you feel like you’re accomplishing very little, that the work you do goes around in a circle instead of progressing toward the team’s goals? The key to leading a team and driving it to success is to be sure that everyone is going in the same direction. Whether it’s the right direction is a good question, but there can be no room for ambiguity, for a lack of decision making, for a lack of alignment.
To do this, leaders have to live the team’s culture and show it in their daily actions. But almost as important, you need to talk about it, and talk about it a lot. My belief is that if you’re willing to say something twice as a leader, people listen, and if you say it on a consistent basis, your team will understand how clearly important it is.
But finding the right words, the right way to keep a team aligned and moving forward isn’t always easy, and leaders need to turn to many sources to find the inspiration. Everyone on the Surface team is familiar with a particular metaphor we use as the bedrock of our team’s culture. This metaphor was originally inspired in a class I took many years ago, but I have evolved the idea into a much broader story over the years.
Imagine a picture of a massive ship, one that needs hundreds of people at its oars to move it through the water fluidly. When I first saw this picture in class, it was a thing of beauty. The image exuded harmony, a sense of power, planfulness, and organization at a massive scale—with all the ship’s oars in the water, the ship would move gracefully through the ocean toward its destination. When showing this picture in class, the lecturer used terms such as decision making, integrity, and dealing with ambiguity to help describe leadership. It made sense. Yet, thecloser and longer I looked at this ship, the more dysfunctional it appeared. Some of the oarsmen rowed in the opposite direction from others. Some had left their post, and left their oars dragging. A desk was placed strangely in the middle of the deck, with a group of people huddled around it arguing instead of rowing. The person who was supposed to bang the drum to keep everything in order and in rhythm was kicking back in a chair, asleep under a sign labeled “On Break.” We were being taught a valuable lesson during this lecture—that although the ship was majestic and had all kinds of potential, at the end of the day, with its lack of leadership and clear direction, it did nothing but go in circles.
When we started Surface, we made it clear that anyone who wanted to join the Surface team had to get on the ship, grab an oar, put it in the water, and start moving in the same direction. If your teammate can’t row, help out. And if you notice that someone is rowing in the wrong direction, point it out and turn them around. To win, to make the best products possible, and to be sure that the team has great energy—that the people on it love what they’re doing—the team doesn’t have time for cynics, and it doesn’t have time for victims. Everyone needs to be on the boat and rowing in the same direction.
This metaphor is ever-present on our team. We use it to help drive the culture. Everybody together, everybody in the boat. We stay committed to fast decision making and clear direction. We even use oar in our day-to-day language. In the hallways, you’ll often hear someone saying “My oar is in the water.” One of the awards we give out is a large oar that’s engraved with people’s names and passed around from office to office. We might talk about how someone on the team grabbed an oar, and now look at how fast we’re moving because of that person’s initiative. While this might seem a bit over the top, it’s a clear and simple way to align a team with its culture.
The leadership in Surface is committed to providing clear direction that leaves no room for ambiguity. And the metaphor of the ship gives the team absolute license to hold leadership accountable for making decisions that remove hurdles and keep the team moving forward. Our clarity of culture and purpose reflects back on what we do, and it reflects on the quality of our products. It also reflects in the pride we have as a team—working together, creating products together, and rowing together in the same direction.
Despite everyone working their hardest, a team’s efforts can easily end up being scattered across multiple possible strategies and multiple target customers, with each member making the best local decision with the data they have on hand. The reality of resource constraints means that you won’t end up doing a great job at executing on any one of these strategies, so the risk is high that you will end up shipping peanut butter.
Communicate your North Star broadly
In most cases, it’s the job of the leadership team to make the decision about the high-level strategic direction of the team, and that direction setting won’t make a bit of difference unless the team is aware of and has bought into that direction. You may think that the responsibility to make thishappen lies solely on the top leaders, and while leaders certainly take on a large role in communicating and socializing a team’s product strategy, it’s everyone’s job to turn that strategy into a living, breathing thing that ultimately gets transformed into a solution for your customers.
There are a lot of creative ways to communicate and socialize a strategy throughout a team. One tempting approach is to avoid doing so in the first place. Instead of relying on the broad team to understand the strategy, all decision making is routed through a gatekeeper. For example, a chief designer or architect makes it his business to oversee how things are coming together and to provide guidance and make course corrections as needed. While this can be an effective approach in smaller teams and in high-stakes situations, it breaks down quickly in larger teams where the gatekeeper (or guru) job is bigger than one brain can handle. This approach can also disempower the rest of the team, and that creates its own set of problems.
A better approach is to efficiently communicate the choice of target customers broadly across the team, and explicitly connect the choice of target customers to the business strategy you are pursuing. The goal is to make sure everyone on the team knows why you are focusing on these customers (and why you aren’t focusing on others), and what kind of carryover you expect to get in the market. This enables every person on your team to make an informed judgment at every layer of the solution’s architecture whenever a tradeoff must be made.
Here are a few ideas that we’ve found effective for socializing the business and customer strategy throughout the team:
Publish a business strategy or framing memo Write it and make it broadly available to the team (and probably your partners as well). Bonus points if you write it collaboratively and allow for iteration and feedback from the team. One great way to get buy-in on a strategy is to ask for help in creating it in the first place. We provide more details about creating a framing memo (and you can read a sidebar on the topic) later in the chapter.
Hold an all-hands meeting Assemble everyone together in a room (or hold a video conference), and present the essence of the team’s strategy. These types of all-hands meetings can be incredibly boring, however, and from the team’s perspective a brutal waste of time. Put some effort into making the meeting interesting, memorable, and educational for the team. If you can’t do that, don’t bother.
Schedule round-table luncheons Meet with every member of the team informally during lunch. It’s a common practice to meet with a small group (5-10) each time until the entire team has had an opportunity to hear about and discuss the strategy (and air their points of view).
Hang posters in the halls Socialize the target customers by creating a poster that features them and their real-life issues. Hang up the posters everywhere, especially in high-traffic areas such as near the kitchen or restrooms.
Create a theme for the release More than just a code name, come up with some sort of theme that can be used throughout product development to make the main components of your strategy and target customer fun and memorable. For example, in the very early days of developing the C# programming language, the key target customer was nicknamed Elvis, which turned into a full-on, Graceland-inspired theme. Leaders dressed up as Elvis, T-shirts and coffee mugs were created, and there was a video floating around in which Elvis’s hit song “C. C. Rider” morphed into “C# Rider.” There’s nothing like a popular rock song to keep the team abuzz with the target customer in mind.
Invent a pithy acronym Assemble some of the key words of your strategy into a memorable acronym. This is a great way to build a shared understanding of a customer or a strategy that can be referenced over and over in shorthand.
Some of these ideas may seem a bit corny, and maybe they are. But the point is to create a shared understanding of your business strategy and target customer throughout the team. Make it memorable and fun and do something that the team can use to create a sense of tribe—and focus that tribal sense around your customers and their needs. Be creative in finding new ways to keep the target customer in sight as the team’s North Star throughout the development process.
Write a business strategy memo
A specific tool that has been adopted by many of the leaders within Microsoft is a framing memo. The intent is for the leadership team to collaborate and consider the current business environment, discuss and explore the world of possible opportunities, and identify any key constraints facing the team, the product, or the business environment itself. This high-level business-strategy work is done well ahead of any detailed product planning.
For the team, it spells out clearly the opportunity, the target customer, the goals, the expectations, and the constraints in which the team must operate. Typically, a handful of events are held to socialize the framing memo and its content for every member of the team, thus aligning the team on high-level goals. It’s important to understand that this memo does not specify any product features, nor does it say how the team or the product will achieve these goals. But it does a great job of explaining where the product is heading and why. The team is then empowered to figure out how to get there.
SFE in action: The framing memo
PJ Hough, Corporate Vice President, Microsoft Developer Division
I’ve had the opportunity to represent the Office leadership team and craft the framing memos for several versions of Office. The framing memo is a formalized planning document that is created to kick off a new project. It lays out the current business landscape for the product and describes the opportunities the leadership team would like the team to explore and deliver in the next version.
The notion of a framing memo is something that has evolved over time. In fact, the earliest drafts that I remember weren’t formal, nor were they broadly distributed. These early incarnations were simply notes compiled to help the leadership team come together near the end of a release and decide what it was going to do next. Over time the memo developed into a formal practice that became a grounding for the entire team.
The framing memo decomposed
The purpose of the framing memo is to align and motivate the entire team. It contains just enough information to describe where the product needs to go and why, such that the team can use its genius and creativity to figure out specifically what to build in order to achieve those goals.
Over the years, the framing memo has taken on a more or less standardized structure. Or at least there are expectations by the team that the memo will cover certain types of information and answer certain questions. Here’s what I consider to be the most salient sections of the framing memo:
State of the Union I typically begin each framing memo by literally presenting a lightweight retrospective of the product, the processes, and the team for the current release. I talk about what we have just delivered into the market, what customers are saying about it, and any initial reviews or feedback we have. In general I try to communicate a sense of what we’ve just built that the market is beginning to appreciate. I focus this section on what we have delivered, how it is landing with customers, the engineering processes we used, and how we had worked together as a team. This section is generally intended to be short and to show pride in what we have just accomplished. However, it also will highlight any major areas for improvement that the team had experienced along the way.
What has changed In this section of the memo, I take a hard look at what has changed, and I reframe the business, technical, and customer landscape for the team. I cover things like global changes that have occurred in the marketplace, new competitors, changes in customer expectations, trends, platform changes, and technology shifts. Sometimes, these changes represent major inflection points that are important to foresee and communicate, such as the emergence of mobile devices or the importance of web-based productivity tools.
Business data This is where I present the data that puts our team’s business in the context of what the larger company is trying to accomplish. In this document, I’m not concerned with engineering metrics—we have plenty of that elsewhere. I include a lot of business metrics and data in this section, including data from analyst reports, competitive reviews, and observations from our field marketing teams. I’ll also include hard business metrics, such as the rate at which the product is being deployed, or an analysis of the business value we are generating for the company. Sometimes, these business metrics illuminate clear direction on an engineering imperative we must tackle in the next release. An example is the time when the data revealed a gap between the number of copies of Office sold and the number of licenses actually deployed. This helped us realize that it was becoming much too difficult for customers to deploy Office. This would become a real business problem for us in the future because customers would have difficulty understanding the value of any upgrade we would deliver if they hadn’t even installed the current version. So we took those business metrics and framed it as an engineering challenge to the team. Something like “Let’s make our product more manageable, easier to deploy, more rapid to update and let’s get more of our customers actually using the current version that they paid for.”
Frame the business opportunity Finally, based on all of those data sources, the framing memo outlines the business opportunities the leadership team would like to pursue. This includes describing the customer markets to focus on, taking advantage of new technology trends, and responding to emerging inflection points. Sometimes, the reframing of the business landscape is very focused on tightening the constraints in which the team must innovate and operate. But more often, the memo gives the team license to approach a new set of problems they may not have felt empowered to do previously. For example, this is the place where I would say something like “The next version of Office needs to have a seamless mobile experience.” Or, “The next version of Visual Studio needs to help developers build cross-platform applications.” These types of directional changes are usually a little bit of a surprise to the team because they reflect a change in the leaders’ point of view about the direction the business is headed. Now, you can’t have many of these directional changes, but by putting them into a framing memo, you send a very strong signal that as a team we are going to figure out some new dimension of the business, there is a new opportunity we are going after.
Aligning the team
I think there are two key aspects to getting the team aligned and engaged in the high-level direction presented in the framing memo. The first is follow-through. It is imperative after publishing such a memo that the leadership team continues to use the statements in the memo as benchmarks for measuring progress toward goals throughout the release. If the leadership takes these goals seriously and follows through on measurement and accountability, so will the team.
And finally, anytime I communicate broadly to a team about change, it’s very important not to skip layers of management as you roll out that change. Before sending out the memo to the entire team, I give all levels of leaders an opportunity to participate in and to own the message, commit to it, and then personalize it for their own team. As the document gets rolled out, there are typically a series of team meetings where individual leaders in the organization take the memo, relay it in the context of their own team, and demonstrate the connection between what the business is trying to accomplish and what they, as an individual engineering team, are going to do within that context.
Final words
It’s important to note that the interesting features and experiences that we build into any individual product are rarely, if ever, described in any framing memo that we write. It’s the team’s hard work to discover and design those customer experiences and product delighters. And the team does that work in the context of fulfilling the important business and customer goals that are laid out in the framing memo.
Finally, at no point is building the wrong product justified by the fact that you wrote something incorrect in a framing memo. Teams have to be smart; you have to be flexible and listen to customer feedback. You have to recognize when the world is shifting even faster than you thought, and you have to be able to adjust your plan and be able to balance the need to complete a set of experiences for a customer segment and the need to shift to meet a new opportunity. The existence of a document like a framing memo is no excuse for building the wrong product. This is especially true with long product cycles. As the industry has shifted to delivering with ever-shorter cycles, you can learn and adjust more quickly and integrate learning of what’s happening in the market.
What if you pick the wrong North Star?
Don’t get stuck in analysis paralysis trying to pick the perfect strategy or the most optimal target customer for carryover. Rather, trust in the Fast Feedback Cycle of rapid prototyping and early user testing to tell you whether you’re on the right track. As you iterate with customers and learn what resonates with them (and what doesn’t), you may find that you need to shift your focus to a different target customer or change strategies altogether. This is fine, and even expected, especially in newer businesses and more entrepreneurial ventures—and getting frequent customer feedback via the Fast Feedback Cycle will ensure that you don’t linger too long on a bad plan.
Of course, if you do decide to make a big change, be intentional about it, and be sure the new plan gets communicated clearly to the entire team—your North Star might have just moved. Certainly beware of the temptation at the first sign of trouble to revert back to throwing spaghetti at the wall and seeing what sticks. There just aren’t enough hours in the day for that approach to be viable in today’s fast-moving markets, and you aren’t likely to end up shipping a complete end-to-end experience. Make an intentional decision, communicate it clearly, and empower your team to iterate to give you the best odds of discovering the winning combination efficiently.
Mindshift
Focus, focus, focus. A common mistake is to not focus tightly enough, and it is probably the mistake that teams make most consistently when they adopt these practices for the first time. Trying to do everything for everyone is not a winning strategy in today’s market. You really do want to settle on at most three or four target customers.
Sticking to the decision to focus on a few is genuinely hard, and team leaders need to set the tone here. Think back to your past experience—you can cut early, or you can cut late. If you cut late, you end up throwing out a lot of wasted work. The most efficient approach is to cut early.
Logically, we know this is true. But the beautiful thing about engineers is their nearly limitless ambition, a deep desire to build a breakthrough solution, and a strong cultural ideal of more must be better. It’s excruciatingly hard to leave potentially world-changing ideas on the cutting-room floor, especially when the ideas that are chosen aren’t a sure thing either. Later in a project, it is so tempting to add in “just one little feature.” Yet, limiting scope is one of the most powerful levers a team has to influence the overall quality of the end product, to be sure that all your resources are focused on building and fine-tuning the product you will actually ship to customers.
Target customer stage: How do you know you’re done?
The prerequisite to starting the Fast Feedback Cycle is that you identify a prioritized set of target customers that is aligned with a high-level business plan. You know you are ready to begin the next stage and start iterating when you have:
A prioritized list of a (very) few target customers.
A business plan, framing memo, or other written document that describes the current business environment you are working in, any real-world constraints the team faces, the opportunities you believe exist, and the rationale for how and why your chosen target customers fit into that overall picture.
Communicated and socialized the business goals, strategic direction, and prioritized target customers with the entire team.
Every member of the team can recite the list of target customers and refer to them naturally in conversation, in design discussions, and when making tradeoffs.
A word of warning: it’s easy to become overly analytical about choosing your target customer. “Which customer has which percentage carryover? Why? Show me quantitative data to prove the case!” Identifying such a customer is nearly impossible to do, by the way, since it involves predicting the future, and even the most sophisticated models fail to predict the future on a regular basis.
But your gut still insists: “What if we pick the wrong target customer and focus in the wrong direction? Won’t that be a disaster?” Focus feels like a risky decision. Having lots of irons in the fire feels intuitively like a much safer bet. However, remember that having lots of irons risks dividing your team’s attention, making it that much less likely that you will deliver any complete end-to-end experiences that will delight anyone.
Think of your choice of target customers like making an informed hypothesis based on the best available data. Then manage the risk by relying on the Fast Feedback Cycle of prototyping and getting feedback to validate that hypothesis in the first few weeks (not months!) of your project—or to discover early on that you need to make a shift.
While it is true that picking your target customers is a very important strategic decision, don’t lose the overall point of this chapter. A few end-to-end experiences will trump a large collection of features and capabilities, and you can’t build a true end-to-end experience without having someone specific in mind. So pick someone and get going on building a product that will rock their world. In doing so, you will almost certainly rock other worlds as well.
Notes
1. Matt Goulding, “Why the French Secretly Love the Golden Arches,” Slate, August 9, 2013, http://www.slate.com/articles/news_and_politics/roads/2013/08/mcdonald_s_global_expansion_the_american_fast_food_chain_has_become_an_unexpected.2.html.
2. Some engineers fall into the trap of believing that their users are homogenous. Read Chapter 5, “Observing customers: Building empathy,” do some customer research, and you’ll soon discover that customers often represent a diverse set of attitudes, behaviors, and needs.