Sense and Respond: How Successful Organizations Listen to Customers and Create New Products Continuously

by Jeff Gothelf

Increasingly, the relationship with our partners is dominated by the two-way conversation that digital technology allows. In the face of this new pace and these new expectations, our management systems—built for the manufacturing economy that dominated in the past century—are worse than insufficient. They are failing badly. They are in need of an update.

The complexity of software systems, the challenge of predicting what the market wants, the pace of change within the market itself—all this stacks the odds against these stand-alone approaches.

When you look at the methods that have been developed in the past twenty-five years in the software world, you’ll see that many of the most influential ideas share the agile concept of a continuous feedback loop—this notion of a continuous conversation with the market—whether

designers bringing the ideas of user-centered design, design thinking, and lean UX,

bringing lean startup and customer...

technologists bringing lean and agile methods and ...

Create collaboration. All great digital efforts are collaborations—between a creator and the audience. Between developers and operations people. Between designers and business stakeholders. You need to embrace collaboration deeply and break down walls where you find them. This means that we need to consider how we organize our teams, our departments, our programs, and our initiatives.

It’s a mistake to segregate into collaborative pairs. This is an anti-pattern.

Finding Value in Uncertainty Why does Amazon release software so often? It’s not only because it can do it. No, instead, releasing software frequently is only one element in the sense and respond approach. This approach to work

involves rapid cycles of sensing what the market needs and responding rapidly. As you saw in the Facebook story, this approach allows teams to make sense of complexity, reduce uncertainty, and find solutions that work.

One technique that Amazon and similar companies use to optimize the process very quickly is to release different versions of a portion of their website—for example, the checkout flow—and route incoming traffic to the variant versions, comparing the performance of the versions. This is the scientific method in action. It’s called A/B testing,

Without embracing uncertainty, you can’t capitalize on the value that emerges from these systems. This is why many organizations are moving toward the continuous, small, rapid, experiment-and-adjust cycle that is at the heart of the sense and respond approach. By making small, continuous changes and measuring the results, teams have discovered in practice exactly the method that complexity theorists recommend for dealing with these complex contexts.

In order to operate in this new, continuous rhythm, teams must be free to act. They must be free to experiment and learn. This means that teams need to be given greater decision-making authority.

The answer is that you need to change the way all of the parts of the business operate, and what you think of as a “plan.” It’s not enough to change the way you make your products and then leave the rest of the business to operate as if those changes weren’t happening.

Adopting the Continuous Mindset: More Than Just Listening to the Customer We’re seeing many organizations that are in this gear-grinding state. Their technology teams are moving (perhaps tentatively) into the continuous rhythm and adopting the continuous mindset that makes it possible—but organizations are having trouble integrating these teams into the rest of the business. This is because the rest of the business doesn’t yet have a model for moving to this new rhythm.

Lean startup is derived from Toyota’s production system, also known as lean manufacturing. Taiichi Ohno, the father of lean thinking, worked with Eiji Toyoda at Toyota in postwar Japan to create a system to maximize value, make efficient use of limited capital, and eliminate waste. The two men believed that a system—a company, a product, a project—is always moving from a condition of doubt toward a condition of certainty in an ongoing quest for perfection. Each step in the direction of perfection and customer value

Everything else is waste.

Understanding the New Unit of Progress: Moving from Qu...

Learning, moving from doubt to certainty, is often a process of trial and error. Trial and error is how we learn to walk, ride a bicycle, read, or play an instrument. In other words, we learn through action. When we put teams on projects, then, we want them ...

So making a thing, creating an output of some sort, is not our goal. Instead, success is the extent to which we achieve an outcome and help our customers achieve an outcome they seek.

Testing Assumptions

On a team like this, there’s no place for cowboys, ninjas, rock stars, or gurus.

The team mentality must start at the executive level. Leaders must set and communicate direction and then allow the team to gather information, learn, and react.

Many of these leaders even have a clear picture of how they need to proceed. And yet the overwhelming majority of these managers face challenges in turning their organizations around. The “way we’ve always done it”—annual financial budgets, long-term strategic planning, discipline-based silos, incentive structures based on production quotas—proves to be too hard to overcome.

To some extent one has to acknowledge a certain level of genius in Steve Jobs.

very few leaders possess those same qualities—despite their proclamations to the contrary. And yet, for those who believe they possess a Steve Jobs-like amount of insight, little will dissuade them.

Apple’s failures in software (remember MobileMe?) and social networking (Ping) demonstrate that the development process that serves the company well in some spheres is not sufficient to deal with most complex software-based services. iTunes, formerly a model of simplicity and power, is now routinely held up as an example of corporate bloatware.

prototypes. Prototypes, as powerful as they are, can teach you only so much. They can’t reveal what happens when thousands of people are using your software at the same time; they can’t help you discover and capture the value presented by emergent behavior.

covert efforts can reveal only so much. At some point, the ideas have to be tested in the wild.

At the end of the day, your staff and, most important, your middle managers will do what they get paid to do. If your company’s bonus and promotion structure rewards on-time, on-budget delivery, the teams will optimize for delivery. If your salespeople promise features and bake those promises into contracts, your teams will have little opportunity to change course in the face of learning.

This is the industrial-age factory model applied to modern, technology-driven products: rewarding people for making things rather than rewarding them for making the right things.

It turns out, though, that, if teams’ goals are set in terms of changing customer behavior rather than shipping a set of features, they end up delivering superior results. Adopting this model requires that middle managers take a leap of faith that it will help them achieve their goals faster than the traditional ways they’ve used to date.

Notably, incentives are not something that teams themselves can change. This is a responsibility that falls squarely on upper management’s shoulders.

This may seem rather obvious, but if you look at the way most companies manage digital product development, you’d be hard- pressed to see these ideas in action. That’s because most companies manage projects in terms of outputs and not outcomes. This means that most companies are settling for “done” rather than doing the hard work of targeting success.

Instead of trying to fit agile into a command and control framework, we’ve seen many organizations adopt coordination approaches that are more in line with mission command—that move away from planning with outputs and toward managing with outcomes. These approaches use different tactics to coordinate the effort of large teams, but they tend to create something we call outcome-based road maps.

key elements we need when we direct the work of teams: The strategic intent (“We want to increase the organization’s impact by a factor of 10”) The strategic constraints (“We will do this by creating an online matching service that must be live by X date”) The definition of success (“The service will match parties at X rate”)

It’s the process by which Amazon is able to release software every 11.6 seconds.) Over the years, they have developed a culture around experimentation, A/B testing, and optimization. The agile methods it implemented made it possible to take an experimental approach to releasing new software. Let’s say, for example, it wants to redesign a product page on its website. Rather than guess which page performs better, it quickly designs and builds a few versions of the page, releases them to the site, directs a small, carefully controlled set of users to each version, and then measures which page performs best.

This is an example of what we consider an outcome-based road map. It neatly ties the work you’re planning to the outcomes you believe the work will have, and it ties the outcomes you seek to the strategic objectives you are trying to achieve. It creates a coherent story that connects the leadership of the organization to the troops on the ground. One manager at the company told us, “The best companies have a ‘product editor.’ They have a story. If you look at Apple, they have a story, a narrative. With this approach, we have a story. As a product lead, I love this. I have direction.”

The Westpac team found that it took it a while to get the vision maps right. Team members had to create a compelling story (and thus generate excitement and alignment) but avoid being too detailed. They didn’t want to lock in too soon on features that might not work. In other words, they wanted to preserve each team’s freedom of action—the team’s ability to own, or at least participate in, creating the right solution. Ian Muir, head of customer experience, told us, “The key is finding the right balance when you’re telling the story of the future and you don’t have all the information you want.”

those artifacts serve as a backdrop for the most important part of the process: the collaborative gatherings at the design walls.

By building road maps around customer-centered journey maps, the Westpac team uses customer experience as a key dimension around which they align. This is a little bit different from the other examples we’ve shared in this chapter. Those teams used organizing principles that are more obviously based on business outcomes. There are advantages to organizing around customer experience, though, especially if it tracks to the strategic goal. At Westpac, this is indeed one of the strategic goals. It can be hard to create a great customer experience in an agile context. One of the frustrations we see in some organizations that work in an agile way is something called experience debt, or design debt. Similar to technical debt (an engineering term for the engineering housekeeping-type work that is useful but never gets prioritized and thus builds up over time), experience debt comes from the small design problems that build up over time and reduce the quality of the user experience: a confusing instruction here, an extra pop-up window there. Designers want to be able to go back and improve things by iterating: working on the feature again. But project owners, whose performance is sometimes measured by how many features they release, may feel pressure to move forward to the next feature. Muir points out that neither choice is inherently right or wrong. “It’s a value trade-off,” he told us. Muir says that the journey maps help make this choice visible. Teams can look at the map, see ...

Part of the power of the customer journey map is that it aligns the work of multiple teams around a single vision. It helps that it expresses the vision in terms of the customer, because this point of view cuts across the organization. It cuts across roles, departments, channels, and so on. It allows the organization to step outside itself and consider how the various pieces of the system fit together.

Software also tends to make traditional “project” thinking obsolete. When is a piece of software done? The answer is never. So instead of organizing “projects” that have a start and end date, agile approaches argue for creating standing teams that own an effort on an ongoing, continuous basis. Thus, instead of chartering a team to build a set of features, we can charter teams to achieve a set of outcomes, as we discuss in chapter 5.

Creating Culture The way you charter work creates culture. If you ask people to build features, they will, and they will value the delivery of those features, even if delivery doesn’t create big picture success. They will value the traits and behaviors that make it possible to deliver features. On the other hand, if you ask people to be responsible for success, you are asking them to work in a new way. And although eventually this approach will shape a new culture, that cultural transition needs to be made consciously, and new cultural traits need to be developed and supported.

1980s. Jidoka is the idea that any production line worker could—indeed was obligated to—stop the line if he or she saw a defect or quality problem. The idea was to fix the problem before it could affect more cars. Only after the problem was fixed could the line be restarted.

A delivery culture that values hitting your production targets and deadline targets is in direct conflict with a culture that prizes discovering and embracing emergent customer value. In a delivery culture there’s no time for conversations with the market and no time for learning and iteration. Instead, delivery culture rewards employees and managers for completing tasks on plan rather than confirming that these were the right tasks to complete in the first place.

When you separate the tasks people are performing from the logic that connects those tasks to results, bad things happen. Instead of rewarding thinking, experimenting, problem solving, and learning, you begin to reward order and discipline. In these cultures, mere discussion of the task at hand can be perceived as insubordination. Delivery culture is characterized by top-down decision making, multiyear road maps, annual planning cycles, and arbitrary deadlines. It is not a culture that builds two-way conversations.

It is, therefore, an obsolete and risky way of working in a so...

One manager at a leading financial services firm put it this way: “The struggle is really with traditional product owners who made decisions in one way in the past: these folks are used to being experts. They’re used to having the answer. And they’ve had career success up until now working this way. These folks have a hard time making decisions in a new way, a way that’s more of a conversation with customers.”

You also need the cultural permission to experiment. This means creating an understanding with your colleagues and leaders that your progress will not be linear and predictable and that you should not be judged by your delivery rate (the amount of stuff you ship) but by your learning rate, and by your overall progress toward strategic goals—in other words, by the extent to which you achieve the outcomes in question.

The motivation for this process is that failures should be treated as learning opportunities. In order to learn from failures, you need to make an accurate assessment of what happened, why it happened, and how it can be prevented next time. It would be simple to treat this inquiry as a hunt for the person responsible so that this person can be disciplined. But if this is the outcome of the inquiry, then the people involved will not be motivated to share the truth of what happened. Instead, they will cover it up to avoid punishment. So, in order for people to learn, the blameless postmortem process must include an ironclad guarantee that they can speak without fear of punishment. And that guarantee must be upheld each and every time.