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

by Jeff Gothelf

Focus on the outcomes. In the digital age, it’s difficult, and sometimes impossible, to predict which product features are needed in the market. Yet often, we plan our features and manage our business cycles as if we know exactly what’s going to work. We manage by specifying outputs—what we’ll make. Instead, we need to focus on outcomes: management needs to declare the business outcomes they wish to achieve and then set up their teams to figure out how to get there. This means that we have to create the conditions in which teams can try different approaches, experiment, learn, and discover what works through trial and error.

Large organizations tend to behave like a production line, outsourcing execution and isolating decision making within the higher levels. Instead of a conversation, these organizations are simply pushing “Play” on a prerecorded speech.

Every year, our society wastes hundreds of billions of dollars on failed software efforts, mostly because we think we can use industrial-age management approaches on digital-age problems.

Traditional IT projects tend to take a “big bang” approach, in which the software is not released to users until it is finished. This means that it’s hard to tell whether the team building the system is on the right track until the end of the project. In contrast, an agile approach, which is at the heart of sense and respond, would address this problem by releasing small pieces of the system frequently and would do so from the earliest days of the project. This reduces the risk that the software team is off course, because it creates transparency. It becomes easy to see what the team is doing, because it’s sharing its work continuously. This transparency is key because it enables a feedback loop. Is the software working? Is it meeting user needs? Is it creating the outcomes the business seeks? Why wait until the end of the project to find out?

This is the guiding principle for sense and respond organizations. Start by creating a conversation with your customers so that you can learn first, and refine and deliver second. Creating early, probing efforts will help determine which version of your idea resonates with your customers and will start the process of continuous learning. Without the learning, you risk delivering a product or service no one finds valuable. The sooner you discover whether your business strategies warrant further investment, the less time you waste on fruitless endeavors. In other words, the sooner you can find out whether you’re wrong, the better.

The point of the experiment is not to determine whether an organization can build a new service or product. Instead, these experiments, predicated on collecting market feedback quickly, determine whether the organization should work on them at all. In other words, he’s proposing that we consider market risk first, and technical risk second.

The top-down, change-resistant planning we see in the Fire Phone story is all too common. It’s the norm in large organizations. Most often it’s expressed in a document called a feature road map. This is a compelling document. It gives a clear sense of where we are, where we’re headed, and what features we’ll build to get from here to there. It provides a sense of progress and serves as a motivational tool for teams, managers, executives, and, often, external partners and stakeholders. It sets expectations about when features will be done. It’s also a complete fabrication. Imagine, for a second, the product manager for the Cooking Light Diet team committing to a feature road map at the beginning of the initiative. She would commit to a specific feature set, pricing strategy, and delivery dates. Then after each experiment and set of customer conversations, she would have to revise the road map and go back to her stakeholders to get it approved, each time watching as her credibility eroded. While this is happening, the team members would be waiting for approval, their productivity slowing to a crawl. Their learning would be causing problems. The alternative to feature road maps is to make looser plans and then adjust them as you learn.

Indeed, in 2015, a Harvard Business Review study on digital leadership revealed that many managers are aware of the challenges posed by digital technology: the risk that it will disrupt their business and the need to create an effective response.1 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.

Perhaps the most challenging and difficult objection to overcome is your company’s reward and compensation structure. 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 functions based on the continued belief that digitally powered products and services can and should be stamped out like parts on an assembly line. The faster and cheaper we can do that, the more we’ll succeed. This belief manifests as managers explicitly telling staff what to do. It’s still the dominant model in most companies.

However, we can change our attitudes toward compliance. One chief risk officer we worked with in the financial services industry recognized that his staff was functioning as a series of “red lights” to impede the progress of product teams. His goal, in the face of continuous two-way conversations and ever-increasing competitive threats, was to figure out how to redistribute his people among the product teams so that they functioned as a series of “green lights” as they moved toward production—turning red only when an important issue arose.

Recognizing that it was important to test assumptions (rather than define requirements) before funding system development, GDS spent eight months getting approval for a new chartering process that involves a discovery phase followed by an alpha phase.

Platforms offer mature, stable infrastructure from which you can build products and services that reach millions. These products generate insight, thanks to the data you can collect from your systems. So the final piece of the puzzle isn’t really about technology. It’s about people—specifically, the people in your organization. Are you set up in a way that allows you to respond? Can your speed of response match your speed of insight? We’re not talking about how fast you can make things, but rather how fast you can decide to make things. Changing the speed with which you can respond to new insight is all about decision making. These decisions must reflect the pace at which information flows in. To do that, an organization has to trust that its managers will make the right decisions. The people best positioned to make real-time decisions (i.e., to respond to incoming data) are the people actually making the product or carrying out the policy change. No one has a greater level of investment than these frontline execution staff. They’re the closest to the market and are likely to have the greatest insight about how to respond. Companies that give these teams the freedom to respond quickly, without bureaucracy, enable a pace of work that unlocks all the technical capability available in our twenty-first-century market.

The most common way to organize teams so that they can respond quickly is to use agile methods. Agile methods promote team-level empowerment and decision making based on data. Unfortunately, many companies have adopted agile methods without really understanding why they are doing so. Often these methods are used simply to execute a predetermined plan. Decision making—the ability to respond to feedback from the market—remains outside the team, and thus operates at a much slower pace. This is the mindset of the industrial age, a mindset driven by the pursuit of perfection, lengthy production cycles, assembly lines, and long chains of command. It’s also what will allow more-nimble competitors to capitalize on opportunities before you do. Instead, you must hand over control of the tactical decisions to the teams that are closest to this insight.

But we need to take a step back and consider what “done” really means. Does it mean that we’ve shipped a product or launched a service? Does it mean that it’s making money for the company? Oddly, usually not. It’s usually a few steps back from that. Sometimes it means, “We’ve built the thing you specified in the contract.” Or sometimes it means, “We’ve written software, tested that it works, and deployed it to a server.” Usually, though, it doesn’t mean, “We’ve finished making something that we know adds value to the business.”

The vendor can make the website, deliver it on time and on budget, even make it beautiful to look at and easy to use, and it may still not achieve our goal, which is to sell more of our products online. The website is the output. The project may be “done.” But if the outcome—sell more products—hasn’t been achieved, then we have not been successful. 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.

Some managers try to overcome the problems caused by uncertainty by planning in increasingly greater detail. This is the impulse that leads to detailed requirements and specification documents, but, as we’ve come to understand, this tactic rarely works in software. It turns out that this problem—the way our plans are disrupted by uncertainty, and the fallacy of responding with ever-more-detailed plans—is something that military commanders have understood for hundreds (if not thousands) of years. They’ve developed a system of military leadership called mission command, an alternative to rigid systems of leadership that specify in great detail what troops should do in battle. Instead, mission command is a flexible system that allows leaders to set goals and objectives and leaves detailed decision making to the people doing the fighting.

Mission command is built on three important principles that guide the way leaders direct their people: Do not command more than necessary, or plan beyond foreseeable circumstances. Communicate to every unit as much of the higher intent as is necessary to achieve the purpose. Ensure that everyone retains freedom of decision within bounds. For our purposes, this means that we would direct our teams by specifying the outcome we seek (our intent), allowing for our teams to pursue this outcome with a great deal of (but not unlimited) discretion, and expecting that our plans will need to be adjusted as we pursue them.

SAFe is a way of decomposing large projects into smaller pieces, assigning those pieces to teams, and creating accountability to ensure that teams complete the work that they’ve signed up to complete. The problem with this approach is that it is essentially a “more detailed plan” approach, and it ignores the influence of uncertainty. SAFe moves teams away from a sense and respond approach and toward a central-planning approach. In effect, it reduces the agile team to a production team, giving them a fixed set of requirements and expecting a specific output to emerge from the end of the assembly line. This approach can be appropriate for high-certainty efforts, but it limits an agile team’s ability to learn from feedback as it goes forward. And again, it’s this learning from feedback that allows teams to navigate in high-uncertainty contexts.

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.

Building an Outcome-Based Road Map The first part of the work involved senior leaders, who created a list of strategic themes for the coming year. These themes would be the top-down guidance—the coordinating ideas that would serve as the rudder for the ship. Strategy is about choices. It’s as much about what you don’t do as what you choose to do. So for this year, following a period of intense focus on one segment of customers, the executives chose to focus on a different segment, one they felt had been underserved previously. From this focus, the leaders created a number of smaller themes, including a focus on the mobile experience. (Stephen Bungay points out that a good strategy statement often “looks banal” to outsiders. The value comes from the alignment you create through the continuous process of articulating the strategy.)4 With the top-down strategic themes prepared, all the delivery teams were asked to create a list of initiatives they wanted to work on in the coming year. This was the bottom-up part of the process. The list came from the front line, the cross-functional team members who knew the most about the product, the customers, and the users. These were expert, informed opinions, deeply rooted in the situation on the ground. The teams also had to provide an estimate of the specific, measurable business outcomes they believed each initiative would create. Next, the product leaders in the middle management layer needed to figure out how to coordinate the effo...

Let’s review some of the elements that made this process successful and, at the same time, consider how it supports the sense and respond approach that this company embodies. Strategy is expressed as intent. Rather than lay out a detailed plan, leadership set direction and asked the folks close to the customer to figure out the details. Situational awareness defines tactics. The staff members have a deep knowledge of what the real-world conditions are, what they’d like to fix, and what is realistic. They were able to select the best tactics to achieve the mission. Commitments are made to outcomes rather than features. By tying initiatives to outcomes rather than to features, leaders gave staff members the flexibility to pursue their missions and use their best judgment to achieve the desired outcomes. A mix of bottom-up and top-down planning provides balance. Unlike previous years, in which bottom-up planning resulted in a lack of coordination—or, as we see in many organizations, top-down planning creates a lack of flexibility—this process balanced inputs to create a healthy equilibrium.

The road map also has to strike a balance between making specific promises and allowing flexibility in both time commitments and features to be delivered. In other words, it has to communicate clearly what teams intend to do and, at the same time, allow for plans to change and evolve in response to learning. The team uses a combination of tactics here. First, team members are conscientious about time promises. And second, they try to limit making hard commitments to anything except the most near- term work.6 They slice the future into three buckets. During “current” work, which looks ahead about a month, they make relatively firm commitments as to what they’ll deliver. Next comes “planned” work, which is one to three months away from being started, and work that is being considered but is not confirmed. Finally, there is a longer-term bucket called “prioritized” work. This is work that is tentative.7 You should be able to see in this approach one of the central tenets of mission command: do not command more than necessary or plan beyond circumstances you can foresee.

This final point from Intuit is critical to enabling good planning across the portfolio, because it points to the importance of managing your budget toward different goals and, by inference, with different yardsticks. About this process, former Intuit vice president Hugh Molotsi wrote, “A common mistake companies make is measuring the progress of all their offerings using standard business metrics—like revenue, profit and customer acquisition—no matter what stage those offerings are in. Horizon planning helps us avoid that mistake by providing guidance on what our expectations should be from offerings at each stage in their maturity.”13

The engine of digital production looks like the entrepreneurial team in the garage. At the heart of this team, you’ll typically find a balanced group made up of all the diverse capabilities you need to launch a digital product or service and to quickly interpret the insight generated by the resulting two-way conversations. The people on these teams generally fill three core roles: engineering, product management, and design. These three capabilities form a three-legged stool. Engineering is concerned with what’s feasible—what can be built. Product management is concerned with the viability of the business—how the business will sustain itself. Design is concerned with desirability—how you make something people want.1

The first problem here is that the original approach—the one conceived by the client and sales team—is likely to be only partially right. This means that it’s also partially wrong. Projects need a way to correct for this situation, or else the early mistakes will be compounded. If decisions and information flow only one way—downstream—you never have the opportunity to correct mistakes as you go.

The second issue with this kind of project flow is that the knowledge you are creating in each phase of work gets lost at each hand-off point. Knowledge is not like a car chassis. It does not roll intact and complete down an assembly line. Instead, it grows and lives inside our heads. It is messy and can never be perfectly transmitted from one person to the next. No matter how well we document what we’ve learned, some of what we’ve learned stays in our head, and some of what we document gets misinterpreted or distorted by the biases of the transmitter or receiver. This all adds up to a simple and overwhelming problem: the high likelihood of building the wrong thing. So the project approach is efficient but not effective. Utilization is high, but the output creates no value.

The alternative to the industrial model is to create small, self-sufficient sense and respond teams. These teams are given autonomy to operate independently in pursuit of an assigned mission—to seek out and create value. An autonomous team has a full set of sense and respond capabilities and can create and participate in two-way conversations with the market. Teams that are able to sense are allowed to interact with the market—to interact with and observe customers, to monitor how they’re using the product, and to create probes, provocations, and tests in order to sense market needs with greater clarity. Teams that are able to respond are able to understand and interpret the sensing data, make decisions based on this data, and then produce a response. So these are the capabilities of a sense and respond team: monitoring and observing customers, creating experiments, understanding and interpreting data, deciding how to respond, and producing a response. These capabilities are not new, but the way we arrange them inside an organization is new. In industrial organizations, these capabilities are typically working in isolation and in sequence. In a sense and respond organization, there is no time for this work flow—and there is a distinct disadvantage created by the isolation this style of information flow creates.

The strategy and product management teams argued and pitched. Eventually, the executive team decided to build the single-broker app (option 2). It’s important to note that this decision was made based on the strength of the argument and the persuasive ability of the advocates, rather than on market feedback.

They pulled in the salespeople and traders who would be working on the service, and they pulled in the engineering team members who would be building it. This war room was very different from the earlier one. It’s wasn’t an engineering-only room or even a product-team-only room. It housed a self-sufficient business team. This team, working in a series of collaborative design sessions, sketched the outlines of a service that would be delivered, at least initially, mostly through human agents, backed up by a small amount of software. Over time, as they confirmed that the service was working as imagined, the team members planned to shift more of the functionality into the software in order to allow the service to scale. And it worked. The team launched the service in a matter of months, to positive reaction in the market, and was able to scale it up through frequent follow-up releases in the subsequent year.

Finally, leadership realized that top-down decision making wasn’t going to work if this team was going create a great product in twelve months. There simply wasn’t enough time for each decision to be run up the chain for the traditional set of approvals and sign-offs. The team would need more decision-making authority than normal. By embedding decision-making autonomy in the team, leadership enabled team members to move quickly enough to make several iterations over the course of the year. The end results speak for themselves. The product is selling at twice the normal rate, costs half as much, and got to market twice as fast as previous refrigerators. Although the refrigerator itself is not a software-driven product, the techniques and attitudes used in pulling together the team, creating its mission, and empowering it to pursue that mission are techniques that work in any domain in which teams face uncertainty.

Many teams require specialists if they are to succeed, although they don’t require these specialists on a daily basis. You might need someone from your company’s legal or compliance team available to review work, but you probably don’t need them daily. The same might be true for any range of specialists. For this, we’re seeing teams use what we call the orbital model of staffing. In this model, your core team is a planet, and you have a variety of specialists orbiting the planet like moons. This model works because, like a moon, each specialist is on a known orbit. Specialists check in with the team once or twice a week—an agreed-upon cadence. It’s the rhythm of this relationship that makes it work. Unlike other part-time staffing assignments, in the orbital model, the key to making the assignment work is the known and consistent rhythm of the interaction.

Managers can create the conditions for collaboration to flourish by making a few changes in the way teams are composed, managed, and organized. These changes are simple enough to describe but can be difficult to implement, because they require coordination with other departments. Indeed, without the support of senior leadership, these changes may prove quite difficult to achieve, as simple as they may seem. Here is a list of key changes that enable sense and respond teams to collaborate effectively: Creating autonomous, mission-based teams Using cross-functional teams Building dedicated teams Supporting new work flows Co-locating teams Being careful with remote work Being careful with outsourcing Holding retrospectives and using minimum viable processes Think of this list as a starting point rather than a recipe. Every organization that implements these ideas will need to do so in a slightly different way. Think of these points as principles rather than hard-and-fast rules.

One obstacle here is the shortage of skilled staff. Technology workers are in short supply, and it’s often difficult to hire and retain enough people to get the work done. Compounding this problem is a legacy of understaffing designers in organizations. Designers, once considered a luxury in the software world, are now a necessity for most teams. But organizations are struggling to adjust their staffing levels. In older organizations we often see ratios of one designer to every one hundred technology staffers. As a result, these folks are spread thin, and they typically work in central service departments that function as internal agencies. We believe that a more effective ratio is one designer for every ten engineers and, for some organizations, even higher. Some teams can get away without designers, especially those working on back-end and middleware functionality, but any team with customer- or user-facing functionality should not forgo design.

Once you have cross-functional teams, you need to ensure they are dedicated to a single mission at a time and that the staff is dedicated to the team. Again, this may not be as simple as it sounds. It can be vexingly difficult. Often, there is more work to do than staff to do it. As a result, organizations try to squeeze more work out of each staff member by assigning the staffer to multiple projects. In a physical factory, the absurdity of this way of assigning work is obvious. You can’t have someone working at two manufacturing stations simultaneously. But with thought work, the work itself is so abstract that it can shape-shift when assignments are being considered. The problem with assigning staff to multiple teams or multiple projects is that it creates dependencies among projects, and dependencies reduce flow. Although a single team can schedule tasks together and optimize its flow internally, it becomes much harder for two teams to schedule tasks together. If a designer has to produce a drawing for team A, then her work for team B is idled until that drawing is complete. And if two people on team A have responsibilities to other teams—for example, the designer owes work to team A and the developer owes work to team C—then the scheduling problem suddenly multiplies in complexity and rapidly becomes unmanageable. It is far better to keep things simple and efficient by dedicating staff to a single team and dedicating that team to a single mission.

Perhaps the most important change you need to make in terms of collaboration is helping the team itself to reimagine its work flow. This kind of collaboration typically requires team members to change the way they accomplish their individual work. Product managers may be accustomed to creating detailed plans and business cases; they need to change their approach to one of asking questions and running experiments. Designers may be good at working out each pixel in Photoshop; they need to become comfortable facilitating team design sessions at the whiteboard. Developers may be used to working from detailed requirements documents; they must get used to starting with much sketchier inputs. And everyone needs to get used to the idea that change and rework are valuable parts of the process, instead of costs to be avoided. According to PayPal’s Bill Scott, reflecting on one reason his teams at his former employer, Netflix, were so successful, “I realized that, especially in the UI layer, we were throwing out 90 percent of the code we wrote in a given year.”7 The team there bought into the idea of continuous improvement: it’s not that team members were writing bad code but that they thought of the code they were writing as simply a learning tool. It was part of the team’s ongoing effort to find the right solution.

When you’re planning teams with remote workers, it is important to pay particular attention to things that create unbalanced communication, or things that interrupt real-time communication. Teams should generally be structured across as few time zones as possible so that people are awake at the same time. And to build the social relationships and trust that make collaboration possible, teams should plan to get together in person on a regular basis every few months at minimum.

There are, of course, technology projects that are suited to outsourcing. Not every technology project faces the same level of uncertainty. Projects with low uncertainty (about what to build and what will work) are candidates for outsourced or offshore teams. One way we’ve seen this work is with so-called two-track agile approaches. In two-track agile, two tracks of work act in coordination. The first track is the experiment track. This team uses all the sense and respond techniques described in this book to take on the high-uncertainty portions of the work and figure out what solution works best. From there, the solution can be passed off to a second track—the production track—and this team implements the solution in a robust way. This arrangement works best when the hand-off between the teams is not a document, specification, or contract, but rather a working prototype that has been produced in the final delivery technology. Two-track agile has the benefit of allowing one team to move quickly to discover market needs, and another team to work at a more measured pace to handle security, internationalization, scale, and other concerns. But doing it well is tricky. It risks generating some of the old problems we face with assembly line work: that information may not flow back to the product team in a timely fashion and that it will reduce the rate of change that’s possible. It also isolates the production track, costing it the opportunity to get a preview of (or the ability...

As you would expect, each time the team released new product features, customers responded with feedback. And not all of it was positive. It would have been easy for managers to be discouraged by negative feedback, or to write it off because it contradicted their worldview. Instead, they embraced the feedback as an opportunity to learn. They thought, “If each time we roll out new software, we learn where we were right and where we wrong, then the more frequently we ship new ideas, the faster we’ll be able to learn and adjust.” They started asking themselves, “Why do we learn only four times a year? Why not four times a week?” This idea—that you can increase the rate at which your organization learns by increasing the flow of ideas through the product development process—is fundamental to successful sense and respond approaches.

One of the most exciting things to emerge from the technology world in the past decade is the DevOps movement. DevOps—the word comes from combining development with operations—is a set of ideas and processes that make it possible for teams to release software frequently, reliably, and with less risk than before. DevOps is the technical and infrastructure foundation layer of what we’ve been talking about throughout this book, so it’s worth spending a few minutes on the basic concepts that go into it and the impact it has on organizations.

Most organizations that implement DevOps approaches have a way for managers to control which end users see which new features and when. This control is provided by something called feature flags, or feature toggles. You can think of these as on-off switches for features. They allow product managers to do things like experiment with new features by exposing them to only a small, selected group of users. Feature flags make it possible to A/B test alternative versions of a feature and to kill features that are causing confusion. And generally, they ensure that the decision to deploy software is a business decision rather than a technical decision.

We can bring this idea back to organizational work with the idea of a sandbox: a safe place with clear borders within which teams may operate. A sandbox creates positive effects for leaders as well as subordinates. For leaders, there is a legitimate fear that their people will get creative in some way that will cause trouble, and for which a leader will be held responsible. Creating clear guidelines within which people can operate can ease this fear. For subordinates, the fear is about crossing some unstated line. If leaders make the lines clear, it creates space for creativity. Here’s an example: at one large firm we spoke to, managers were free to put up experimental websites without asking permission, but they couldn’t mention the company’s name or use the brand elements anywhere on these pages. These teams were also not permitted to collect any personally identifiable information, or PII, without going through a review of their plans with a security team. At another firm we spoke to, a consumer business with millions of customers, teams were free to reach out to customers to try out experimental services, as long as no experiment reached out to more than one hundred customers at a time. Teams that wanted to reach out to more customers had to get approval for their plans. At this organization, there was no prohibition against collecting PII, as long as it was handled within company guidelines. There was a restriction on collecting payments. As with many things in the se...

To become more responsive, Pearson is trying to add flexibility to the way it allocates budget, moving to a model that is more rolling in nature. In the new process that they have been deploying, Pearson allocates money to projects throughout the year, a process governed by what it calls product councils. The councils meet quarterly to make investment decisions and convene monthly to monitor the projects they’ve funded. Product councils are distributed, operating within each business unit. They are made up of leadership from those business units, typically director- and VP-level leaders. Each council is cross-functional and includes leaders from technology, product management, finance, strategy, efficacy (responsible for learning outcomes), and other key functions. Notably, the councils do not include senior executives, because they’re likely to be too far removed from the day-to-day operations to be able to make informed decisions. Instead, senior executives set strategy and set the overall goals for the councils to meet. The councils make funding decisions around what Pearson calls its global product life cycle, a structure it’s been implementing since 2013 to provide a consistent, repeatable, and scalable framework for making product investment decisions. This model is not dissimilar to the three horizon model used at Intuit (described in chapter 5). At Pearson, the life cycle has six phases instead of three, but the fundamental concepts are similar. Early-stage ideas a...

“You can’t predict the future,” Kresojevic told us. “If your only ability to respond is to cut spending in October, then you’re not a responsive business. You’re not responding in the places where you can create growth, or where you have a new opportunity presenting itself.”

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. Indeed, this is what has happened at AutoTrader UK, where teams are no longer funded annually to build a set of features. Instead, the organization now checks in with each team on a quarterly basis to see how it’s tracking against initiative goals. Initiative goals are quantitative and based on changing customer behavior in some way that benefits the business. Teams get funded to change these behaviors, one quarter at a time. As the quarter nears its end the company assesses, with the team, whether it’s worthwhile to continue working toward those outcomes. If so, the team gets another quarter’s worth of runway. If not, it moves on to a new initiative.

The annual budgeting process should be reconsidered in favor of more frequent periodic progress checks with teams, based on progress toward business outcomes. Marketing teams have to adjust to a world in which product features are frequently unknown until just prior to release. Sales teams must move away from promises about features and dates and toward taking a proactive approach that helps teams understand customer and market needs.

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 software-driven world.

One culture-building practice that organizations use to create permission to fail is the blameless postmortem. This regularly occurring meeting provides an opportunity for the entire team to go through a recent time period (product release cycle, quarter, etc.) or to review a specific incident and honestly examine what went well, what could be improved, and what should not be continued. Often, these postmortems are facilitated by someone outside the team to avoid any bias or conflict of interest. Think of this activity as continuous improvement but applied to the way the team works rather than the product it’s working on. 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.

A few years ago, design researcher Jared Spool studied teams to see what effect exposure to customers had on product success. According to the study he published in 2011, teams that met with real customers for at least two hours per team member every six weeks produced superior products.12 In the study, Spool calls this key metric exposure hours, or the number of hours that each member of the team is exposed to customers. This last point is important. Teams that do a lot of research but in which only research specialists participate do not see this improvement in product quality. The second key point in the study is that the research can’t be done only once. It has to be done continuously; the study found a frequency of at least every six weeks to be the magic number.

Sense and respond methods rely on a continuous feedback loop—an ongoing conversation (both metaphorical and literal) between our organizations and the people they serve. This conversation helps us figure out what our customers value, and it helps them express what they value. It allows us to try things out, see what works, and adjust until we find the sweet spot: something that creates value for both our customers and our business. This way of working, of navigating uncertainty, has been developed in parallel across many disciplines. We see these continuous, feedback-based processes in methods like agile, DevOps, design thinking, and lean startup. Taken together, this body of methods is the future, and our challenge now is to look at our organizations and institutions and evolve them—or risk seeing them replaced by newcomers.

The changes required will go deep. As we’ve discussed, they cut across every department and function in an organization. Finance will need to reassess the way budgets are made. Product management will need to reassess road maps and portfolio planning. Marketing and sales must move from a predictable, feature-based world into a world of continuous value creation and delivery. “This year’s model” is a thing of the past. Legal teams and compliance teams will need to work with delivery teams to find safe ways to enable continuous learning. In other words, technology is no longer only an IT problem. The rhythm of technology is changing the rhythm of business, and we’re all going to need to adapt.