Escaping the First Law of Organizational Gravity

At this point, the general idea of customer centricity has become canon for modern businesses. Every organization wants to be, and most claim to be, customer-first, customer-centric, or “customer-obsessed.” And yet, most organizations still struggle mightily to keep pace with their customers, and most employees are still much more concerned with what their boss thinks than what their customers think. The hard truth of the matter is that most organizations take precious few steps to encourage the actual work of customer centricity, regardless of what they say in their mission statements and yearly town hall meetings.

The reason for this comes down to the First Law of Organizational Gravity: individuals in an organization  will avoid customer-facing work if it is not aligned with their day-to-day responsibilities and incentives (Figure 3-1). In other words, organizational leaders can say all they want about customer centricity, but that rhetoric will not translate into action unless individuals throughout the organization see learning from customers as a critical step toward achieving the goals for which they are held accountable.

Figure 3-1. The First Law of Organizational Gravity: Individuals in an organization will avoid customer-facing work if it is not aligned with their day-to-day responsibilities and incentives. Note how the org chart clusters away from the one employee directly interacting with a customer at the lower right.

For individuals whose success is measured solely against company-centric goals like timelines and budgets, interacting with customers can be distracting at best and downright dangerous at worst. After all, time spent with customers is time not spent doing the executional work that moves a project tangibly closer to completion. And if your customers complicate your existing plans or challenge your existing assumptions, they may actually slow you down—at least from the company’s perspective. For most people in most roles at most organizations, there is simply no immediate reason to prioritize the day-to-day work of customer centricity.

In practice, this often means that the only people within an organization who interact directly with customers are those explicitly tasked with doing so as part of their day-to-day work, such as user experience researchers and customer support agents. And these people are rarely in the room when important decisions are being made. Indeed, it is not at all uncommon for senior leaders in an organization to espouse customer centricity while leaving the actual work of customer centricity to the people farthest from themselves on the org chart—or, as is often the case within marketing functions, to espouse customer centricity while delegating all direct customer research to outside vendors and agencies. This means that the people whose opinions and actions are the most impactful for the overall direction of the business are often the very people who have the least direct knowledge of customer needs and goals.

For any organization seeking to cultivate true customer centricity, this is an enormous roadblock, and one that only compounds itself over time. As leaders become more and more insulated from direct and unmediated interaction with customers, their organizations become ever more poorly equipped to deal with the rapidly accelerating rate of change in customer needs and goals. Even if such organizations succeed in implementing Agile practices, they have not achieved true agility; there is simply too great a distance between decision makers and the customers whose needs and goals should be driving those decisions.

Some organizations have addressed this issue by formally making customer support a shared responsibility across functions and levels. Craig Daniel, VP of product at Drift, described to me how his organization was able to make direct interaction with customers a part of everybody’s job, and how this improved the organization’s ability to deliver valuable products and features:

When you get people in front of the customer, stuff gets done. People are on the hook. The question is, how do you make that happen? As most organizations grow, they have more and more levels, and most of the people at most of those levels aren’t interfacing with customers at all. When you think about it, it really doesn’t make any sense.

We talk to our customers every single day. Since we are a chat company, we use chat for many of these interactions. And to make sure that everybody in the organization stays close to our customers, we have an internal chat duty—every single employee works a shift answering customer chats directly. We’ve also embedded Customer Advocates, who oversee and triage these chats, in every single product team.

The results of this approach are always a work in progress. But we’ve been consistently able to ship both the large and small features that are most important to our customers. We don’t need to have meetings to talk about our customers anymore, because knowing our customers is everybody’s job. Most of our product managers probably talk to 10 customers a week. Most of our engineers probably talk to at least one customer a week. We don’t miss ship dates and deadlines, because we are able to prioritize the work that is most important to our customers and work backward from there.

This example makes a critical point that is often lost in conversations about customer centricity: investing more time in learning directly from customers means that we need to spend less time speculating, socializing, or debating about what our customers really want. Understanding and appreciating the extremely high return on investment that comes from talking to and learning from customers directly is one critical step that organizations can take to overcome the First Law of Organizational Gravity and put customer centricity into practice.

Seeing Speed from the Customer’s Point of View

If there is one common misconception about Agile that I’ve seen have disastrous ramifications for organizations of all shapes and sizes, it is that Agile is only about increasing the speed of execution. As we will see throughout this book, implementing the basic principles of Agile often means taking the time to better understand our customers, share knowledge among our team, and reflect on the way we’re working. From the company’s point of view, this can look like slowing down. But if we are truly following the principles of Agile, we are measuring speed from the customer’s point of view.

What does it mean to see speed from the customer’s point of view? It means that the most important question for us to answer is not “How quickly are we doing as much work as possible,” but rather “How quickly are we able to deliver value to our customers?” As Mayur Gupta, VP of growth and marketing at Spotify, told me, “agility is measured in your ability to change and evolve based on customer need, not in your speed to execute.”

In practice, this means asking, “How can we solve our customers’ most important problems as quickly as possible,” instead of “What is the most amount of work we can get done in the shortest amount of time?” Product designer and researcher Dr. Anna Harrison described to me a hypothetical scenario that illustrates how customer-centric discipline can run up against executional ambition. Let’s imagine that we are working for a company that builds digital waterfowl. We’ve done our research and discovered that our customers are primarily interested in purchasing ducks. But when we go to our engineering team, they point out that in nearly the same amount of time it takes to deliver a digital duck, they could build a system that gives our users the option to choose from a duck, a goose, or a swan. That seems like a pretty good deal: an incremental increase in time, but a three-times multiple in the waterfowl we can deliver.

Allowing our users to choose between ducks, geese, and swans might seem like added value from our perspective. But from their perspective, we have given them more decisions to make and more work to do. In other words, we have slowed them down. Seeing these other options, they might wonder whether we are truly the best place to buy a digital duck. Or they might just not want to decide in the moment and abandon the transaction altogether.

If we go ahead and launch with a ducks-only product, we might realize later on that we do in fact want to give customers the option to select from a broader range of waterfowl. Or, we might discover that our customers are still primarily interested in buying ducks but are also interested in buying digital pond accessories. Whatever path we wind up taking in the future, we are prioritizing the work that will deliver the most immediate and well-understood value to our customer right now.

Seeing speed from the customer’s point of view helps us escape what author and consultant Melissa Perri calls “the build trap,” a common pitfall of Agile in practice (and an inspiration for the frameworks trap described in Chapter 2):

The amount of things we produce is no guarantee of a successful company. Building is the easy part of the product development process. Figuring out what to build and how we are going to build it is the hard part. Yet, we only allow ourselves a few days or a week at the beginning of each sprint for designing and speccing this out. We completely neglect research and experimentation in favor of spending more time writing code.

In other words, if we see Agile as simply a way to do the same things we’ve always done, only better and faster, we are in no way mitigating the very real risk that our customers might want something different.

Note that the build trap is just as treacherous for folks who are not delivering software products. Rachel Collinson, also known as the Donor Whisperer, is an Agile practitioner working with nonprofits in the United Kingdom. She described to me how the Agile principle of customer centricity stands to transform that sector as well:

What charities often do is put together a long research report, spend ages working with a designer, launch it, publish it, and then work with PR to get it out into the world. They expect that report to have a huge impact, and often it doesn’t. But accomplishing a charity’s underlying goals isn’t just about getting more organized and getting out ahead of the deadlines; it’s about asking, “Do we need the report at all?” It’s about using user-centered design principles to say, “What problem are we trying to solve? Who is this for, what are their needs?”

The same thing is true when it comes to fundraising. There is an increasing hysteria in the media about the methods charities use to raise funds, and questions about how effective charities are, whether they exist at all, should they be looking at root causes or should they just be handing food to hungry people. Rather than saying, “Maybe we should do fundraising a new way,” many nonprofits are doubling down on the old way, which is to write an extremely guilt-provoking letter and send it to as many people as possible. These organizations spend months agonizing over the text, and getting the photos right, and designing it perfectly. Then they send the direct mail and they analyze the results and say, “Oh, that didn’t do as well as we hoped.” But from a donor’s perspective, direct mail is often a fundamentally bad experience, regardless of how much time and effort a nonprofit puts into choosing the photos and writing the text.

What I’m trying to do now is just listen closely to donors and ask those bigger questions about how we can align what we do with their goals and needs. Then I test an MVC (Minimum Viable Campaign) with them and scale up, polish, and launch only if the response is good. It’s a tough sell, but I know it’s the only thing that’s going to work.

As this story illustrates, organizations of all kinds have a tendency to default to what they’ve done in the past—even if it is not what their customers (or in this case, donors) really want. In cases like this, operational “speed” is ultimately irrelevant. Thus, it is critical to put an explicit commitment to customer centricity at the heart of any Agile journey.

Beyond “Working Software”

The Agile Manifesto has its own way of reframing speed as a function of customer value:

Working software over comprehensive documentation

Many critics of Agile approaches have misinterpreted this as an anarchistic decree that all documentation be torn up and discarded forever. But the intent behind this statement of values is actually pretty straightforward: focus on the things that deliver immediate value to your customers. Comprehensive documentation can feel like progress, but until you have something that your customers can actually use, you haven’t made much progress at all.

The fact that the Agile Manifesto specifies “working software” has also contributed to the misconception that Agile is only for software developers and cannot be extended to other parts of an organization. But, as Table 3-1 indicates, every kind of product or deliverable has its equivalent of “working software”—something that your customers can interact with directly to ascertain whether or not it is meeting their needs and goals.

When we take this broader approach to defining “working software,” we are able to spend less time on intermediate states that deliver no real value to our customers. Instead, we are compelled to ask, “What can we put together that our customer can actually use, and that we can actually learn from?” In the Lean Startup world, this approach is often called Minimum Viable Product (MVP), but it can be used for developing much more than products.

To use a common example, imagine that you are tasked with putting together a PowerPoint presentation for your colleagues. Your first instinct might be to fire up Word and begin meticulously constructing a long, comprehensive outline. A week later, you show the outline to a few people to get their feedback. The bullet points make sense, and the structure of the information seems pretty logical. You breathe a sigh of relief. Now it’s just a matter of taking the outline and turning it into slides.

The night before the presentation, you begin transferring your outline over into slides—and realize very quickly that your blocks of meticulously constructed text do not make for a visually compelling slide deck. But the presentation is tomorrow, and you’re running out of time, so it will have to do. The next day, you connect your laptop to the conference room TV screen and fire up your presentation. As you look out over a conference table full of scrunched-up faces trying to decipher blocks of pixelated text, it suddenly dawns on you: from your audience’s point of view, that big meticulous outline means nothing. The comprehensive document to which you devoted the majority of your time and energy may have given you a sense of progress and accomplishment, but it was dangerously disconnected from what your audience would actually experience.

Now imagine if you had started with a working-software approach. Rather than spending a week creating a meticulous and detailed outline, you could have given yourself a day or two to put together a draft slide deck, visuals and all. Rather than asking your colleagues to read several pages of dense text in a format that your audience would never see, you could have walked your colleagues through that draft and learned from their reactions. Any scrunched faces or furrowed brows could have been valuable and actionable feedback, not signs of a failure already in progress. In other words, if you had started by getting as close as possible to the experience you were creating for your audience, you would have been in a much better position to understand and improve that experience before it was too late.

Starting with our customers (or audience) and working backward also helps us understand parts of the customer experience that might fall outside the immediate scope of our working software. Even the most well-crafted presentation, for example, can fall flat if it is delivered in a sad windowless room or if the screen in that sad windowless room requires an adaptor that nobody can find. Thinking through these other contextual issues, captured in Table 3-2, can help us understand how our working software fits into the overall customer experience, and take steps to improve that experience that we might not have thought about previously.

Taking this broader, customer experience–first approach can often help us identify unexpected areas to grow our business. One of my favorite examples of this comes from Fender Musical Instruments, who zoomed out from their product offerings to grow their business by understanding the entire experience around buying and learning to play a guitar. In an interview with Forbes, Fender CEO Andy Mooney described the user research that compelled Fender to create its Fender Play instructional platform for beginner guitarists:

About two years ago we did a lot of research about new guitar buyers. We were hungry for data and there wasn’t much available. We found that 45% of all the guitars we sell every year go to first-time players. That was much higher than we imagined. Ninety percent of those first-time players abandoned the instrument in the first 12 months—if not the first 90 days—but the 10% that didn’t tend to commit to the instrument for life and own multiple guitars and multiple amps.

…The last thing we found was that new buyers spend four times as much on lessons as they do on equipment. So that shaped a number of things. It shaped the commitment we made to Fender Play because we felt there was an independent business opportunity available to us that we’d never considered before because the trend in learning was moving online.

This example illustrates how a truly Agile approach, by any name, must begin with a clear and holistic understanding of the entire customer experience. This understanding allowed a legacy business to make a big move in a challenging industry, and Fender is currently growing at a faster rate than the musical instrument business overall.

Thinking holistically about the customer experience also gives us a way to recontextualize a few well-known quotes that are often cited to defend a general lack of customer-centric practices. First, there is Steve Jobs in a 1998 interview with Business Week claiming that “A lot of times, people don’t know what they want until you show it to them.” And then there is Henry Ford’s famous, if likely apocryphal, declaration¹ that “If I had asked people what they wanted, they would have said faster horses.”

At first glance, these quotes seem to tell a similar story: certain innovations—like, say, the iPhone and the automobile—are so radical, so transformative, so truly and profoundly new, that customers would never be able to imagine them, let alone ask for them. But, as any user researcher would be quick to tell you, asking customers what they want is not the same thing as learning from customers. Taking a broader view of the customer experience is exactly what allows us to see beyond narrow, transactional questions like, “How fast do you want your horse to be,” “What features do you want on your flip phone,” or, to return to the Fender example, “What color guitar would you be most likely to purchase?”

Even if we are to take these two famous quotes at face value, neither is actually a call against customer centricity. In fact, the respective successes of both the automobile and the iPhone speak to how a broader understanding of customers’ needs and goals can uncover entirely new solutions.

Agile Practice Deep Dive: Working in Sprints

If the entire universe of Agile methodologies could be summarized by a single practice, it is that of working in time-boxed iterations, often referred to as sprints. In each sprint, a team agrees to deliver some kind of working software in a short, finite, and agreed-upon timeframe. The team then gathers feedback on the working software it has produced, and incorporates that feedback into the next round of work. As we discussed earlier in this chapter, working software does not need to be actual software; it is simply something that replicates as closely as possible the customer experience you are seeking to create.

Even as an abstract thought exercise, sprints are an incredibly powerful tool. Imagine, in the middle of a six-month project, being forced to decide what you would actually release to your customers if you had only two weeks to work. Would you complete and polish a single part of what you initially planned to deliver? Or, would you try to create a smaller and potentially less-polished version of the whole thing? In either case, you are forced to ask an important and incredibly difficult question: if we only have a small amount of time in which to actually deliver something to our customers, what do we deliver?

This question, in turn, often opens up several adjacent cans of worms. How do we break apart our grand plans into more approachable pieces? How can we accurately estimate what we can actually get done in two weeks? How do we know what our customers actually want? And have we even taken the time to really define who our customers are in the first place?

Many of the practices within specific Agile methodologies and frameworks are designed to answer these very questions. But, for many teams and organizations approaching Agile for the first time, simply asking these questions is enough to bring previously uninterrogated assumptions into the light. And, because sprints are usually quite short, committing to working in this way means that we must ask these questions regularly and be prepared for our answers to change. As shown in Figure 3-2, this gives us the opportunity to frequently adjust both the work we do and the way we work to better reflect the fast-changing needs of our customers.

When I began introducing the practice of working in sprints to product teams, I found that most of the pushback I received was not actually about the relatively short duration of each sprint. Instead, it was about the idea that each sprint should involve getting feedback from customers. “If we have only two weeks to work,” I would often hear, “how are we supposed to make time to get feedback from customers?”

Figure 3-2. Using Agile sprints to incorporate customer feedback at regular intervals.

It was these conversations that helped me begin to understand the First Law of Organizational Gravity described earlier in this chapter. In far too many organizations, directly interacting with customers is simply not seen as an important or valuable use of time. Unfortunately, the idea that Agile is a means to get more work done in less time often reinforces this belief. After all, if our goal is simply to get more work done, why would we waste our time talking to customers when we could be spending that time making more stuff?

The answer, of course, is that our customers are the people who ultimately decide whether the stuff we’re making is successful. It is here where the relationship between principles and practices becomes critically important. “Work in two-week cycles called sprints” is not, and should not be, a principle or a value. Simply breaking down work into two-week chunks, as shown in Figure 3-3, does not mean that we are following our Agile principles and values. If anything, it allows us to superficially check the “doing Agile” box while only growing farther removed from our customers and more resistant to change.

Figure 3-3. Breaking a big plan into two-week chunks—which is not the same thing as working in sprints!

If we break down a large work plan into two-week chunks that do not include our customers, we are not working in sprints at all; we are, instead, simply slapping an Agile veneer on business as usual.

If you choose to pursue working in sprints, here are a few tips to make sure that you are staying true to our first guiding principle of Agile:

Make customer feedback a required part of every cycle

The easiest way to align Agile sprints with your goal of customer centricity is simply to make sure that gathering customer feedback is an essential and unskippable part of every cycle. This might seem daunting at first, but it is one of many ways that you can use the time constraints of a sprint in your favor. Prioritizing time spent with customers reinforces the value of this time and helps to avoid situations in which any time not spent “producing” is seen as wasteful.

Find your own definition of working software

What is it that you will deliver and test at the end of each cycle? And how will it help you to better understand the entire customer experience toward which you are working? Depending on the kind of work your team does, the answers to these questions might be very different. Take the time to discuss them upfront so that you don’t find yourself operating under misaligned assumptions about what “done” means.

Be ready to throw away the work that you just did

One of the other advantages to working in sprints is that you minimize sunk cost if you’ve begun building something that you learn does not meet the needs of your customers. This can be a tough pill to swallow, but if you get out ahead of these conversations, it can be an important step toward getting people to understand that their work is only as valuable to the organization as it is to your customers. When people are comfortable discarding the work from their previous sprint, it shows that they are valuing customer learning over speed of production—a surefire sign that you are on the right track.

Don’t become paralyzed by the details

I have worked with several teams that were initially unable to commit to working in sprints because they could not agree upon how long each sprint should be or how to estimate the work that would be delivered in each sprint. These are important questions to ask, but the right answers are unlikely to present themselves without a fair amount of trial and error, and are likely to change over time regardless. Pick a place to start, and make it clear that there will be plenty of opportunities to adjust course if things are not going as planned (we discuss this at greater length in Chapter 5).

As always, staying firmly grounded in your Agile principles will help to guide you to a meaningful implementation of this and all Agile practices. Jennifer Katz, senior director of brand culture at USA and SyFy networks, described to me how taking a principles-first approach to Agile sprints can be equally valuable for large and subjective projects such as show launches:

Scrum training was very eye-opening for us, and made it clear that there was a lot we could take from the practice and incorporate into our business for a more fluid day-to-day workflow. The way software developers do it, you can be constantly producing code and getting instant feedback. For us, the feedback cycle has traditionally been very different. You do all of this work leading up to a show launching, and it’s not until that show premieres that you really see if all the work put into the campaign did its job and brought viewers in.

We were excited to learn about a more iterative approach so that we could learn faster, fail quicker, and bring our learnings back to the team. And that iterative approach feels much truer to our audience. People are no longer just watching linearly—our viewers are flocking to different channels in new and nonlinear ways, constantly. Gone are the days when you could just create a 30-second spot and then retrofit it to a bunch of different platforms. You need to think about it holistically, from the viewer’s perspective and experience and where they want to go to consume content. That’s been the big learning curve for us—getting everybody here to think a little differently. And part of that is creating a more flexible working system.

One thing we’ve learned is that you need to customize that system for the needs of your team and organization. The group of us that went through the training looked at the philosophies and the practices of Agile and said, “What works for our environment? Knowing that there are a lot of layers, there are processes that cannot be moved, how do we build and work around that in a way that still lends itself to the working practice of Agile?” A lot of it came down to getting people comfortable with sharing things in rough-draft form. Instead of waiting to too far down the line to internally share the campaign materials for approval, get it to key decision makers earlier, more often, and faster, so you aren’t sitting there doing all of this work and then having to go back and do it all again.

As this story illustrates, the foundational ideas behind sprint-based work are very much applicable beyond the world of software development. Even if we are working on projects that involve long timeframes and fixed schedules, we can always look for ways to imagine the customer experience more holistically, and gather feedback about this experience more regularly.

Quick Wins to Put This Principle into Practice

Here are some steps that different teams can take to begin putting our Agile guiding principle of customer centricity into practice:

For marketing teams, you could try…

…breaking the habit of delivering customer insights in the form of large PowerPoint decks and delivering smaller and timelier customer insights more often.

…getting out of the building and interacting with customers directly, even if it is just a matter of talking to somebody on a street corner or at a coffee shop.

For sales teams, you could try…

…sending a quick email to your counterparts in product or marketing that captures insights from a failed customer call or lost sale, to share your understanding of evolving customer needs.

For executives, you could try…

…taking a direct and unmediated look at support channels and customer feedback to better understand the real-world needs and goals of your customers.

…publicly recognizing and rewarding the actual work of customer centricity in addition to the rhetoric of “customer centricity.”

For product and engineering teams, you could try…

…walking through real-world use of your product with actual customers as part of each and every development cycle.

…starting every new product or feature idea with a clear description of the value it will provide to your customers.

For an entire Agile organization, you could try…

…getting in the habit of using your own products or services (a practice sometimes called “eating your own dog food” or “dogfooding”) to better understand the overall customer experience.

Summary: Customers First!

In theory, customer centricity is a no-brainer. In practice, however, it often means making substantial changes to the way we work and at times challenging some deeply entrenched assumptions about what we are doing and why. For these reasons and many more, it is important that we start with our customers, to make as much room as possible for their fast-changing needs and goals to guide both what we create and how we create it. 

In the chapters that follow, we discuss two more guiding principles of Agile that can help us turn the things we learn from our customers into timely and meaningful solutions: collaborating early and often, and planning for uncertainty.