Product Details Lean Enterprise: How High Performance Organizations Innovate at Scale (2015)

Part I. Orient

Chapter 2. Manage the Dynamics of the Enterprise Portfolio

The purpose of a business is to create a customer.

Peter Drucker

In this chapter we will examine the lifecycle of businesses and how companies can balance the exploration of new business models with the exploitation of proven ones. We’ll need this distinction in order to understand where lean startup practices and principles can be applied in an enterprise context and how they can be used as the basis of managing an innovation portfolio.

In his book Diffusion of Innovations, Everett Rogers describes the cycle through which all successful technologies and ideas progress, shown in Figure 2-1.²⁹ Over time, all successful ideas, whether technologies, product categories, business models, or even methodologies, progress from being scarce and unevenly distributed to eventually becoming a commodity. They then form building blocks for new, higher-level, more valuable innovations. Of course the time it takes for innovations to progress through the various stages of the cycle can vary substantially.

Figure 2-1. The S-curve which shows the lifecycle of innovations

Rogers believed people could be classified into groups based on how they respond to innovation, as shown in Figure 2-2. Initially, new technologies and ideas are experimented with and tested by innovators, which form the smallest group of the overall population. As innovators discover technologies that provide competitive advantage (most will not), these technologies are taken up by the early adopters. In this way, success in each group leads to further diffusion through the other groups. Rogers’ ideas were popularized and built upon by Geoffrey Moore, who introduced the concept of the “chasm,” a logical divide between uptake by early adopters and the early majority. This chasm was inspired by Moore’s observation that many innovations flounder once they are no longer seen as a source of competitive advantage by visionaries, but are not yet sufficiently established to be seen as a safe bet or proven practice by people in the early majority.

Figure 2-2. Technology adoption lifecycle, from Dealing with Darwin by Geoffrey A. Moore, 2006 (used by permission of Portfolio, an imprint of Penguin Group (USA) LLC)

Once the market has assimilated a disruptive new technology or idea, a whole range of product offerings gets spawned. Moore’s take on the product category lifecycle is shown in Figure 2-3. A successful product category will initially see high growth (stage B), followed by a mature market(stage C) in which consolidation takes place. Growth in mature markets is typically driven by acquiring competitors and new customers as well as by efficiency gains. Finally, product categories decline (stage D). At any point, a category can be disrupted by some new innovation—indeed an innovation is defined as “disruptive” based on its effect on existing product categories and business models. Even in the face of disruption, it’s sometimes possible to maintain a lucrative niche market; for instance, feature phones are still an important category in many countries, and IBM still has a profitable mainframe business.

Figure 2-3. Category maturity lifecycle, from Dealing with Darwin by Geoffrey A. Moore, 2006 (used by permission of Portfolio, an imprint of Penguin Group (USA) LLC)

The first point to observe is that products at different stages of maturity vary significantly in terms of how they are managed, developed, marketed, and funded. For example, in a mature market we have a good understanding of our customers and the value they get from the product; acquiring new customer or selling new products to existing ones is well understood, and new products in the category typically contain only incremental innovations. For new categories, the opposite is true.

While there is a lot of detail involved in understanding these different stages of the lifecycle, such as whether our customers are other businesses or consumers, we can get to the important discussion by drastically simplifying the problem and looking at two key activities that all enterprises will engage in: exploring new product categories and business models, and exploiting the proven ones.³⁰ Steve Blank refers to these activities as “search” and “execute” in the context of customer development.³¹

Startups begin by exploring new opportunities through business model innovation: they search for a new business model that is aligned with the founders’ purpose and vision, delivers value for customers, and can drive the profitability and growth of the organization. Once it is found, the business model is exploited by growing and scaling it, finding ways to drive down costs, improve efficiency, and increase market share and customer base. However, every business model is ultimately transient: eventually, every business model and product category will be disrupted by new ones—it is only a matter of time.

Exploring new opportunities and exploiting existing ones are fundamentally different strategies requiring different structure, competencies, processes, and mindset. It is hard to overemphasize this key point: management practices that are effective in the exploit domain will lead to failure if applied to exploring new opportunities—and vice versa. The differences between these two domains are listed in Table 2-1.

Startups that discover a successful business model and cross the chasm often find it hard to transition into the next stage: executing and scaling in a growth market. Meanwhile, organizations that succeed in transforming themselves into engines of execution often lose their ability to explore new business models. Eric Ries wrote himself an imaginary memo capturing this shift in mindset:

Dear Eric, thank you for your service to this company. Unfortunately, the job you have been doing is no longer available, and the company you used to work for no longer exists. However, we are pleased to offer you a new job at an entirely new company, that happens to contain all the same people as before. This new job began months ago, and you are already failing at it. Luckily, all the strategies you’ve developed that made you successful at the old company are entirely obsolete. Best of luck!³²

A key goal of successful portfolio management in an enterprise is understanding how to balance exploring new businesses with exploiting proven existing business models—and how to transition businesses successfully from one state to the other. Leaders must understand the difference between these two domains and be able to operationalize the very different mindsets and strategies that govern them.

Exploring New Ideas

Less than 50% of startups are alive five years after they start.³³ In a similar way, enterprises waste enormous amounts of money on trying to grow new businesses, creating little to no value for customers.³⁴ Of course it’s impossible to know in advance whether or not a new business will be successful, but Eric Ries’ The Lean Startup details a method for working in conditions of extreme uncertainty. The Lean Startup methodology applies within the enterprise context just as it does in the world of startups, so long as we are clear on its purpose: to discover and operationalize new and potentially disruptive business models, and to quickly discard those that will not work.

Every entrepreneur, whether they work in a startup or an enterprise, has a vision of their business and the impact it will have on legions of grateful, adoring customers. For this vision to become reality, there are two key assumptions that must be tested: the value hypothesis and the growthhypothesis. The value hypothesis asks whether our business actually provides value for users by solving a real problem. If so, we can say we have found a problem/solution fit. The growth hypothesis tests how fast we can acquire new customers and whether we have what Steve Blank calls a repeatable and scalable sales process—in other words, if our customer base can rapidly move up the “hockey stick” in Figure 2-1 and whether we have a sufficiently low customer acquisition cost. If we pass these tests, we have a product/market fit and can proceed to the final two stages in Steve Blank’s customer development process: customer creation, where we launch our business in earnest, followed by company building where we attempt to cross the chasm.³⁵

In the Lean Startup methodology, we take a systematic approach by working through this process iteratively. We start by working out what we need to learn by creating a value hypothesis. We then decide what to measure in order to test that hypothesis. We then design an experiment, called the minimum viable product, which we build in order to gather the necessary data from real customers to determine if we have a product/market fit.

The trick is to invest a minimum of work to go through this cycle. Since we are operating in conditions of extreme uncertainty, we expect that our value hypothesis will be incorrect. At this point we pivot, coming up with a new value hypothesis based on what we learned, and go through the process again. We keep doing this until we either achieve a product/market fit, decide to stop experimenting, or funding dries up. The amount of time we have before the money runs out is known as the runway, and the goal is to pivot as frequently as possible in order to find a product/market fit while we still have runway left.

An important characteristic of the Lean Startup method is that experiments are cheap and quick to run compared to building a complete product. In general, we are able to build a minimum viable product and gather data in the space of hours, days, or weeks rather than months or years, using small, cross-functional teams that are focused on executing the build-measure-learn feedback loop shown in Figure 2-4. We expect that many experiments will fail but a few will succeed; however, by being rigorous in following the steps above, every iteration will result in validated learning.Validated learning means that we test—to the necessary degree of precision and no further—the key assumptions behind our business model to understand whether or not it would succeed, and then made the decision to persevere, pivot, or stop.

The Lean Startup process being relatively cheap, in an enterprise context we can pursue multiple possible business models simultaneously using the Principle of Optionality.

WHAT IS AN OPTION?

Purchasing an option gives us the right, but not the obligation, to do something in the future (typically to buy or sell an asset at a fixed price). Options have a price and an expiry date. Concert tickets, an agreement to go out for dinner with someone, and a decision to fund the development of a new product are all examples of options.

Figure 2-4. The build-measure-learn loop

Investing a fixed amount of time and money to investigate the economic parameters of an idea—be it a business model, product, or an innovation such as a process change—is an example of using optionality to manage the uncertainties of the decision to invest further. We limit our maximum investment loss (“downside”) on any individual idea, with the expectation that a small number of ideas will pay off big time, and offset or negate investments in those that did not, as shown in Figure 2-5.³⁶ Optionality is a powerful concept that lets you defer decisions on how to achieve a desired outcome by exploring multiple possible approaches simultaneously.

Figure 2-5. The principle of optionality, from Antifragile: Things That Gain From Disorder by Nassim Nicholas Taleb, 2012 (used by permission of Random House)

Effectuation

Limiting the downside and making sure every decision creates at least some upside (even if it is just new information) is one of several techniques that entrepreneurs apply in situations of uncertainty, where simple cause-effect (algorithmic) reasoning is an inappropriate way to manage risk. In her book Effectuation: Elements of Entrepreneurial Expertise (Edward Elgar Publishing), cognitive scientist Dr Saras Sarasvathy describes a framework for entrepreneurship based on research into how entrepreneurs work in real life.³⁷

Limiting initial investment and creating resource scarcity is essential to managing the risk of innovation. Given that most innovative ideas we have will not succeed, we must come up with simple, quick experiments to eliminate bad ideas rapidly and cheaply.

Consider the case of the ARM CPU that is at the heart of almost every mobile device today. The first version of this processor was designed in Cambridge, UK, in the 1980s by two people, Sophie Wilson and Steve Furber. It went from a concept to a production-ready design in 18 months.³⁸When their boss, Herman Hauser, was asked how they did it, he said, “When we decided to do a microprocessor, in hindsight, I think I made two great decisions. I trusted the team, and gave them two things that Intel and Motorola had never given their people: the first was no money and the second was no people. They had to keep it simple.”³⁹

The concepts at the heart of the Lean Startup are designed to rapidly evaluate business models through identifying and testing assumptions in a scientific way. Thus they have application beyond the creation of new businesses. For example, the principles of constraining time and resources, thus limiting downside, and building a minimum viable product to test your value hypothesis as soon as possible with real customers should be applied at the start of every endeavor. We should use this approach to explore all new ideas which have unknowns, uncertainties, and therefore risks—whether it’s delivering new products, replacing existing systems, adopting new tools, processes, or methodologies, or implementing commercial off-the-shelf software solutions (COTS). Whenever you hear of a new IT project starting up with a large budget, teams of tens or hundreds of people, and a timeline of many months before something actually gets shipped, you can expect the project will go over time and budget and not deliver the expected value.

APPLY LEAN STARTUP TO INTERNAL IT PROJECTS

Lean Startup principles are just as important for internal software engineering projects, including services and platforms such as private clouds, systems replacements, and so forth. Enormous initiatives, with roadmaps of months or even years, constantly pop up for these types of projects, with lip service paid to working incrementally to solve a real (internal) customer problem. In fact, teams building these systems are often dismissive of their customers’ needs and preferences—we often hear statements such as “we know what they need better than them.” Projects run in this way, without regularly delivering incremental value to their customers in order to get feedback, are an appalling waste of time and resources and rarely achieve their intent, outcome, or objectives. But there are other serious negative consequences: internal systems that are painful to use make employees frustrated, impact morale and their ability to do their work effectively. Apart from underperformance costs, businesses create systems that add further complexity to already enormously complex production environments. The inevitable outcome is “shadow IT”—teams deserting the services approved or maintained by the IT department in favor of something better so they can get their work done.

Organizations tend to start new projects with large teams both because they assume (wrongly) that this will help finish sooner and because they use processes, such as annual budgeting cycles, that stimulate land grabs for favored projects and resources. In building complex systems, however, these forces inevitably lead to system bloat, increased complexity and dependency management, inefficiency, and poor quality. Establishing and trying to maintain effective communication within large teams consumes enormous amounts of capacity on large projects. Meanwhile, the systems created grow rapidly in an uncontrolled and undirected manner.

In this environment it is extremely hard to establish effective feedback loops to determine whether what is being built is valuable and aligned to the product or project vision. Often it’s not even possible to integrate the components into a working system for much of the project—and when we try to do that, we find a myriad of problems that must be addressed to get the system into a working state, let alone released. It has been our experience, as reflected in Table 1-2, that adding more upfront planning to this process tends to make the eventual outcome worse, not better.

No major piece of work should be fully funded before we have evidence to support the business and economic model on which it is based, and this exploration must be done with small, cross-functional teams with a limited runway, as described in Part II.

WHEN EXPLORING NEW BUSINESS MODELS, MINIMIZE INVESTMENT IN SOFTWARE DEVELOPMENT

One large retail organization we worked with wanted to open a store in a new market—their first international expansion. The IT team were given eight weeks to adapt their point-of-sale system to work in the new country, calculating a different sales tax and using a different currency. We estimated that changing the existing system to work in multiple currencies and tax regimes would be a substantial multi-month IT project requiring significant investment. Forced to seek options to validate that the solution was actually possible, the team hard-coded the new sales tax into the existing mainframe system and implemented a simple proxy that replaced the currency symbols in real time for systems in the new store. Although the international expansion was ultimately cancelled as a result of the 2008 financial crisis, the initial software part of the project validated the proposed solution with minimal investment, before an investment into a fully functioning and robust long-term solution was agreed.

A final note on exploration. In this chapter we focus on the diffusion of innovation as it applies to products, but exactly the same principles apply to organizational change. Many enterprises try to roll out new methodologies, practices, processes, and tools across the entire organization in one go, ignoring the fact that people respond to such innovations in different ways and that there is no one-size-fits-all approach to adoption. It is common to see this kind of “big bang” approach fail to achieve expected results, or be quietly abandoned to give way to another new initiative attempting to address the failings of the last.

We should explore and experiment with radical process changes—known as kaikaku in Lean terminology—in the same way we explore potential new business models. That is, we should try them out with a relatively small, cross-functional part of the organization, with people that fall in the “innovator” category. These people must be interested in the proposed process experiments and have the necessary skills to run them. For a change that proves to be valuable, this team can help other groups adopt it so it “crosses the chasm” within the wider organization until it becomes the standard way to work. However, process improvement does not stop here. As we discuss in Chapter 6, all teams will still make continuous, incremental process improvements, known as kaizen, as part of their daily work to reduce waste and increase throughput and quality. Organizational culture will be discussed in more detail in Chapter 11.

Exploiting Validated Business Models

Enterprises are optimized to exploit business models that have crossed the chasm—it’s what they are designed to do. However, it’s very common for engineering work to be the bottleneck when evolving existing products and introducing new products within the category being exploited.

Projects form the basis of the traditional paradigm for carrying out work in the enterprise. A project typically requires a business case to be written to gain a budget allocation, which in turn leads to a large amount of upfront planning, design, and analysis. The various departments must then coordinate the work and execute the plan. Success of a project is measured by completing the original plan on time and budget. Sadly, however, whether the project “succeeds” according to these criteria is irrelevant and insignificant when compared to whether we actually created value for customers and for our organization.

Data gathered from evolving web-based systems reveals that the plan-based approach to feature development is very poor at creating value for customers and the organization. Amazon and Microsoft (along with many startups) use a technique called A/B testing to gather data on whether a feature will actually deliver value to users before it gets built in full. Ronny Kohavi, who directed Amazon’s Data Mining and Personalization group before joining Microsoft as General Manager of its Experimentation Platform, reveals the “humbling statistics”: 60%-90% of ideas do not improve the metrics they were intended to improve. Based on experiments at Microsoft, 1/3 of ideas created a statistically significant positive change, 1/3 produced no statistically significant difference, and 1/3 created a statistically significant negative change.⁴⁰ All of the ideas tested were thought to be good ones—but neither intuition nor expert opinion are good gauges of the value our ideas have for users.

The project paradigm exacerbates this problem. Projects typically take so long to go from start to finish that stakeholders try and ram as many features as possible into each one, mindful of the fact that it will be hard to get features added once the project is complete. Furthermore, the planning process happens when we have the least information and understanding of project risks—right at the beginning. Due to a cognitive bias known as the planning fallacy, executives tend to “make decisions based on delusional optimism rather than on a rational weighing of gains, losses, and probabilities. They overestimate benefits and underestimate costs. They spin scenarios of success while overlooking the potential for mistakes and miscalculations. As a result, they pursue initiatives that are unlikely to come in on budget or on time or to deliver the expected returns—or even to be completed.”⁴¹

As we execute the project, we discover new information—but since nobody wants their features cut, new information generally leads to more work, which is known as “scope creep.” Donald Reinertsen describes the vicious cycle of adding more scope as we run projects and discover more information as the “large batch death spiral”—which, combined with the planning fallacy, means projects will overrun both their budget and due date in proportion to their size. This is an important argument for working in small batches.⁴²

All of these features and added scope means that projects typically add a tremendous amount of complexity to production environments, which—as we discuss in Chapter 14—is not typically accounted for as part of the project planning process. This complexity leads to higher costs and unplanned work in the operations department, and adds significantly to the cost and effort required to execute future projects.

Finally, because the project approach judges people according to whether work is completed on time and on budget, not based on the value delivered to customers, productivity gets measured based on output rather than outcomes. This drives several damaging behaviors. Product people become judged on their ability to create comprehensive specification documents and well-crafted business cases, not on whether the products and features they come up with deliver value to users. Developers are rewarded for having code completed on their developer workstations, but not for integrating it into a working, tested system that can survive real-world usage at scale. We create an unsustainable “hero culture” that rewards overwork and high utilization (making sure everybody is busy) rather than doing the least possible work to achieve the desired outcomes.

High utilization means work involving collaboration takes longer to complete, because the people you need to work with are always busy with other priorities. In order to meet ever more serious deadlines, people fail to carry out maintenance and process improvement work (such as automation) that would increase quality and throughput. This, in turn, drives up the cost of doing further work, increasing the pressure on the organization to “work harder” and fueling a vicious cycle of overwork.

John Seddon, author of Freedom from Command & Control (Productivity Press), states that “dysfunctional behavior is ubiquitous and systemic, not because people are wicked, but because the requirement to serve the hierarchy competes with the requirement to serve customers…people’s ingenuity is engaged in survival, not improvement.”

How do we extricate ourselves from this downward spiral? In Part III of this book, we describe how to run large-scale programs of work in the exploit domain, using the following principles:

1. Define, measure, and manage outcomes rather than output. Applying the Principle of Mission, we specify “true north” for our program of work—our ideal stakeholder outcomes. Then, at the program level, we work iteratively, specifying for each iteration the measurable program-level outcomes we want to achieve. How to achieve these outcomes is delegated to teams working within the program. Based on the feedback from real customers after each iteration, we work to improve quality of demand, improve speed, and improve quality of outcomes.

2. Manage for throughput rather than capacity or utilization. We implement Kanban principles by making all work visible and limiting work in process. We then aim to stop starting work and start finishing it as soon as possible. We continuously undertake process improvement work to reduce lead time—the time it takes to deliver work—throughout the system. We use continuous delivery and work in small increments to make it cheap and low risk to deliver work in small batches with easier feedback loops.

3. Ensure people are rewarded for favoring a long-view system-level perspective over pursuing short-term functional goals. People should be rewarded for continuous and effective (win-win) collaboration, for minimizing the amount of work required to achieve the desired outcomes, and for reducing the complexity of the systems we create to enable these outcomes. People should not be punished when failures occur; rather, we must build a culture of experimentation and collaboration, design systems which make it safe to fail, and put in place processes so we can learn from our mistakes and use this information to make our systems more resilient.

Balancing the Enterprise Portfolio

The key to managing an enterprise business portfolio, as with any financial investment, is to use an economic model. However, this is not a widespread practice. In a survey of 161 global business decision makers shown in Figure 2-6, only 24% of respondents reported using an economic model to make investment decisions in products and services. Astonishingly, 13% admitted that the most highly paid person’s opinion (known as the HiPPO method) is the primary deciding factor.⁴³ 47% reported using the only slightly less embarrassing method of decision by committee.

Figure 2-6. How do enterprises make investment decisions?

In Escape Velocity: Free Your Company’s Future from the Pull of the Past,⁴⁴ Geoffrey Moore presents a “growth/materiality matrix” for visualizing existing investment decisions, shown in Figure 2-7, and describes how it allows us to distinguish between companies which have an effective portfolio strategy and those which do not. The y axis of the diagram measures whether a particular business is material to you relative to others, where “material” means that it generates 5-10% or more of the total revenue or profit. The x axis measures the growth rate of the business in absolute terms.

Figure 2-7. The growth/materiality matrix for portfolio management, from Escape Velocity: Free your Company’s Future from the Pull of the Past by Geoffrey A. Moore, 2011 (used by permission of HarperCollins Publishers LLC)

Many organizations—in 2014, think Microsoft, IBM, and HP—have market-leading franchises in quadrant 3, corresponding to stage C (a mature market) in Figure 2-3. But, as shown in Figure 2-7, none has been able to develop (rather than acquire) a major franchise in stage B (corresponding to quadrant 2) despite substantial R&D investments which have led to new businesses in quadrant 1. In contrast, Amazon, Google, and Apple have each created businesses in the past decade which have grown rapidly to become material to the enterprise.

In order to understand why so many companies fail to create businesses in quadrant 2, we must understand the dynamics of the enterprise portfolio. This is described in the three horizon model presented in [baghai], shown in Figure 2-8. Horizon 1 consists of your set of core product categories and businesses (corresponding to quadrant 3 in Figure 2-7).

Figure 2-8. Three Horizons, from Escape Velocity: Free your Company’s Future from the Pull of the Past by Geoffrey A. Moore, 2011 (used by permission of HarperCollins Publishers LLC)

Investments in horizon 1 businesses will deliver results in the same year, and typically take the form of developing existing products and launching new ones within the existing categories. Horizon 2 is the set of emerging businesses which will form the core business of the future. These require significant investment and the attention of sales and marketing divisions to succeed, but will not deliver the same levels of returns as horizon 1 investments.

Horizon 3 is the domain of the Lean Startup where we experiment with new business models and attempt to create a product/market fit for new businesses. We aim to invest enough time and money to create a runway to discover a product/market fit before making further investments. We then either move the idea into horizon 2 or shelve it, perhaps until market conditions or advances in technology make it favorable to try again.

There are three significant problems conspiring to kill businesses that make it into horizon 2. First, they require substantial investment in terms of research, sales, and marketing resources without delivering corresponding revenue returns—the metric by which these departments are usually measured. Second, each of the three horizons requires very different management and support practices in order to succeed, as shown in Table 2-2. Blindly applying a consistent approach to each will result in failure. Finally, as Clayton Christiensen discusses in The Innovator’s Dilemma(Harper Business), profitable enterprises are often reluctant to cannibalize their profits and market share by launching disruptive new products—those that might threaten their existing bottom line and market valuation.

We frequently see these forces conspiring to prevent businesses from making it through horizon 2, even in enterprises which do an excellent job of both exploring and exploiting business models. Often, other companies eventually bring them to market with devastating results. Xerox PARCinvented the modern GUI (as well as many other elements of modern computing), but the “toner heads” at Xerox’s head office “had no clue about a computer or what it could do” and so it was ultimately Apple and Microsoft who brought computers into people’s living rooms instead.⁴⁵

Photography giant Kodak, which filed for bankruptcy in 2012, actually invented the digital camera. Steve Sasson and his team from the Kodak Apparatus Division Research Laboratory created the breakthrough innovation in 1975.⁴⁶ However, the team was met with puzzled managers who could not comprehend why customers would ever want to view photographs on a monitor. Their business was optimized for developing photographs—making paper, film, and other supplies—not capturing memories.

WHY YOU CANNOT SIMPLY HIRE OR ACQUIRE YOUR WAY TO INNOVATION

A number of enterprises have been acquiring startups in an attempt to pick on a current trend and accelerate innovation—perhaps to diversify and balance their portfolio, to turn themselves into “innovation labs,” or to tick a box in stage A, quadrant 1, or horizon 3. We have seen at close hand the poor outcomes this creates, with these acquisitions failing to produce the expected return and the senior staff leaving as soon as they could exercise their options. The problems occur when the acquired company—working on a horizon 3 or 2 product—is subjected to the horizon 1 governance, financial targets, and management structures of the acquiring enterprise, completely destroying its ability to innovate. Sometimes people from the parent organization are rotated through the innovation lab in the hope this will magically teach them how to innovate in a different horizon, instead of simply giving them culture shock. Acqui-hiring frequently fails for the same reason: taking great people and putting them into a pathological or bureaucratic culture does not change the culture—it breaks the people. The solution is to do the hard work to transform the culture of your own organization and grow effective leadership and management appropriate to each horizon—which will, incidentally, remove the need to hire in or acquire innovators.

Our hypothesis is that organizations survive and grow in the medium and long term by balancing the ability to continuously explore potential new business models with effective exploitation of existing ones. Indeed, one of the hallmarks of a truly adaptive and resilient organization is that it continually disrupts its own existing business models in search of future opportunities and new markets and customers.

For example, Amazon’s pursuit of electronic books and the production of the Kindle disrupted what was then its primary business model of selling physical books. The development of the Amazon Marketplace enabled other vendors to leverage Amazon’s infrastructure and potentially undercut products sold by Amazon. 3M defines its strategy as constant new product innovation and sets targets for the percentage of revenue from products introduced in the past five years at 30%, which it exceeded in 2008.⁴⁷ Inge G. Thulin, President and CEO of 3M, expects that number to reach 40% by 2017.⁴⁸

Intuit uses a simple model to balance horizons 1, 2, and 3, as shown in Table 2-3. Google follows a similar model, but with different allocations: 70% to Horizon 1, 20% to Horizon 2, and 10% to Horizon 3.⁴⁹

The most important point to bear in mind when balancing horizons is that unless senior leadership takes an active role in managing investments, including putting in place appropriate management practices for different horizons and paying attention to how management is incentivized, core businesses will always find a way to use their corporate clout to sideline and ultimately neutralize the other horizons. If the cultural and management barriers are simply too strong for this kind of “ambidextrous” approach, the alternative is to spin off a maximally independent business unit.

HOW AETNA CREATED NEW COMPANIES TO DISRUPT ITS CORE BUSINESSES

Aetna, like all the players in the US healthcare market, knew that the Obama administration’s Affordable Care Act represented both a serious risk and a significant opportunity. 160 years old at the time the bill was signed into law, Aetna decided to create a new company called Healthagen, “a separate organization, separately capitalized, separately compensated, and separately managed, so they’re not subject to the same management process at Aetna” with the purpose of disrupting the healthcare provider market with new technology and business models. Healthagen has a goal to drive $1.5bn-$2bn of revenue per year initially.⁵¹

Aetna has also created another subsidiary along similar lines to create a consumer marketplace and drive private exchange models. Mark Bertolini, Aetna’s Chairman, President, and CEO, states that his goal is to build a techology-based competitive ecosystem that will disrupt Aetna’s own core business.

Conclusion

Every idea has its own lifecycle, with successful ideas creating competitive advantage for early adopters and ultimately becoming the building blocks for higher-level innovations. Enterprises must ensure they have a pipeline of new ideas to provide the basis for growth in future years. Effective enterprise portfolio management requires that we create and apply an economic model to balance investments across all three horizons. For further reading on portfolio management, we recommend Geoffrey Moore’s Escape Velocity: Free Your Company’s Future from the Pull of the Past.

We expect that there will be several ideas for new businesses incubating in horizon 3. Since we cannot predict which ones will be successful, we apply the Principle of Optionality and assume that many will fail but a few will succeed. We apply the Lean Startup methodology to rapidly pivot through business models for these businesses until the teams exploring them run out of resources or discover a product/market fit and gain traction. Most ideas will never make it to horizon 2, but those that do require a fundamentally different management approach. In horizon 3, we care mainly about finding a product/market fit, but in horizon 2 we need to identify and manage to a wider set of risks specific to our business. Instead of business model innovation, we switch to incremental innovation, which requires a different set of skills.

Too many enterprises kill innovation by trying to manage horizon 2 and 3 investments using the strategies of horizon 1. In the rest of this book we will mainly ignore horizon 1 (although many of the principles and techniques described in Part III can be usefully applied to that domain). Part IIof this book deals with the explore domain that we will leverage within horizon 3 investments. Part III discusses how to move fast at scale in the exploit domain, using the same lean principles that have been applied in manufacturing for decades to continuously drive higher quality and lower costs. In Part IV we discuss how to transform your enterprise, staring with growing an innovation culture.

Questions for readers:

§ What framework does your organization use to balance your portfolio of exploring new business models, exploiting validated ones, and developing core businesses?

§ Is there a place where you can see this portfolio at a glance?

§ What performance metrics are used to measure the health of activities in each of these domains?

§ What is the percentage ratio for investments in horizons 1, 2, and 3 in your organization? Is it intentional or accidental? What do you think should it be?

§ How does senior leadership ensure that investments in horizons 2 and 3 are nurtured, and that transitions between horizons are managed in a way that will maximize the relevant performance metrics for each individual investment?

²⁹ Rogers’ work, detailed in [rogers], was in fact derived from research into the adoption of technology by farmers in Iowa.

³⁰ This distinction was first proposed by James March in his paper “Exploration and Exploitation in Organizational Learning” [march].

³¹ [blank]

³² http://bit.ly/1v6Y8YI

³³ http://bit.ly/1v6YfTX; these numbers vary by industry, with the 5-year survival rate for infotech businesses being substantially lower than education and health: http://bit.ly/1v6YeiN.

³⁴ Hard data is harder to come by, but circumstantial evidence is everywhere.

³⁵ http://bit.ly/1v6Y8YI

³⁶ This idea of option-like trial and error, or tinkering, is explored in Nassim Taleb’s Antifragile [taleb], p. 181ff. Using the language of Dave Snowden’s Cynefin framework, options are a way to make experiments “safe to fail” by designing them so as to limit the possible negative outcomes associated with failure. For more on the application of options to IT management, read Commitment (Hathaway Te Brake Publications) by Olav Maassen et al.

³⁷ For a three-page guide to the effectuation framework, visit http://bit.ly/1v6YjmK.

³⁸ http://bit.ly/1v6Ynmw

³⁹ http://bit.ly/1v6YoH7

⁴⁰ [kohavi]

⁴¹ [kahneman], p. 252. The planning fallacy is relied upon by many service providers who submit rock-bottom bids for the initial, predefined, contractual services (especially when contracts are awarded to the lowest bidder) and then make their profit through change requests for which customers pay a premium.

⁴² Reinertsen devotes a whole chapter ([reinertsen], Chapter 5) of his book to the case for reducing batch sizes.

⁴³ This term was coined by Ronny Kohavi, partner architect at Microsoft.

⁴⁴ [moore]

⁴⁵ Steve Jobs, The Lost Interview.

⁴⁶ http://bit.ly/1v6YwGv

⁴⁷ http://for.tn/11ixTko

⁴⁸ http://www.cnbc.com/id/100801531

⁴⁹ http://cnnmon.ie/1v6YHBA

⁵⁰ http://bit.ly/1v6YI8Q

⁵¹ http://bit.ly/1v6YM8m