Copyright by Robert Blaine McNutt 2011

Copyright

by

Robert Blaine McNutt

2011

The Thesis Committee for Robert Blaine McNutt Certifies that this is the approved version of the following thesis:

Innovation Restrained: Unlocking the Innovation of Acquired Software Startups

APPROVED BY SUPERVISING COMMITTEE:

Steven Nichols, Supervisor

Thomas Darwin, Co-Supervisor

Kyle Lewis


by

Robert Blaine McNutt, B.A.

Thesis

Presented to the Faculty of the Graduate School of

The University of Texas at Austin

in Partial Fulfillment

of the Requirements

for the Degree of

Master of Science in Engineering

The University of Texas at Austin December, 2011

Dedication

For my loving wife, Sarah, and my incredible children, Bleys, Riley, and Ella. Without

your inspiration, love, and support, none of this would have been possible.

In memory of Robin Denise Lee. I am exposed without the venerable shield of my dear

friend and superb, lifelong editor.

v

Acknowledgements

Thanks to Dr. Kyle Lewis for connecting the intelligence of “team” and for

graciously reading. Thanks to Ms. Judy Estrin for her inspirational work in Closing the

Innovation Gap and her feedback; you inspired this thesis and me. Thanks to Dr. Thomas

Darwin for his guidance and support.

Thanks to James Kline and Jason Willebeek-LeMair, whose roles as trusted

sounding boards could not have been better played. And finally, thank you to Cisco

Systems, Inc. for providing me the opportunity to pursue this degree.

A special thanks goes to Eric Ries and Crown Publishing for granting early access

to The Lean Startup galley (Reis, 2011) for the purpose of this research.

December 1, 2011

vi

Abstract


Robert Blaine McNutt, M.S.E.

The University of Texas at Austin, 2011

Supervisor: Steven Nichols

Co-Supervisor: Thomas Darwin

The ability to exploit disruptive innovation is the main factor in a company’s

continued success. The ability to significantly advance a field or create a new field is

paramount not only to a venture’s ability to generate revenue, but it is key to our nation’s

economic vitality. Yet today’s business environment is dominated by funding options and

exit strategies focused on near-term results and unreasonable profit expectations (Estrin,

2008b).

Given these constraints, software startups must focus on incremental innovation

to obtain initial funding. The result is an industry focused on short-term strategies that

limit the likelihood of developing disruptive innovations and companies with long-term

focuses. Current business models do not adequately address a key factor in preventing the

loss of innovations and stagnancy in industries and their markets. New business

vii

frameworks and models are required that focus on preserving the core teams found in

software startups and to provide them with the runway they require to develop disruptive

innovations.

Nowhere is innovation more crucial than in the startup environment where the

abilities to invent, adapt, outwit, and outlast on a shoestring budget predict success. This

paper evaluates today’s business models to determine how they help overcome

roadblocks faced by software startups in today’s acquisition environment, identifies

related research, and recommends new models and adaptations to existing models to

overcome these roadblocks.

“It is estimated that 70-95 percent of acquisitions fail. A significant percentage is due to the friction that is created by trying to integrate the startup with the large company's financials, HR department, product, market and business model. Most startups when they are acquired are uncertain on many of these dimensions, and forcing them to conform on any one of these dimensions to the large company can stunt their growth and often kill them.” – (Herrmann, September 2011)

This paper investigates how to preserve innovation within a startup and within an

acquiring company, how innovation is interwoven in team members, the leadership

characteristics that inspire innovation, and the importance of balancing the value of

innovation against process. The recommended guidance and frameworks focus on

preserving the core team and their innovations, as well as generating a strong return on

investment, when an established business acquires a startup. The perspectives presented

are based on the author’s experiences as a key team member in two startups in the mid

1990s, multiple failed internal incubation groups within a fortune 100 company, and in

considering a new startup in today’s environment.

viii

Table of Contents

List of Tables ......................................................................................................... xi

List of Figures ....................................................................................................... xii

Introduction ............................................................................................................. 1 Types of Innovation ....................................................................................... 1 Reality Sets In—The Postulate ...................................................................... 2 Clarifying “Success” ...................................................................................... 6 Proposition ..................................................................................................... 7 Next Steps ...................................................................................................... 8

Literature Review .................................................................................................... 9 Innovation Management .............................................................................. 11 Startup Models ............................................................................................. 19 Team Composition and Group Cognition .................................................... 27 Organizational Placement ............................................................................ 29 Questions Answered .................................................................................... 30 Questions Not Answered ............................................................................. 30

Case Study: BRSI Core Team ............................................................................... 32 Methodology ................................................................................................ 32 Core Team .................................................................................................... 34 Blue Ridge Software, Inc. ............................................................................ 37

Key Innovations .................................................................................. 38 Transition Highlights .......................................................................... 39 Analysis of Transitions and Issues ...................................................... 40

Global Internet.Com, Inc./Global Internet Software Group ........................ 48 Key Innovations .................................................................................. 51 Transition Highlights .......................................................................... 53 Analysis of Transitions and Issues ...................................................... 55

Cisco Systems, Inc. ...................................................................................... 68

ix

Key Innovations .................................................................................. 73 Transition Highlights .......................................................................... 75 Analysis of Transitions and Issues ...................................................... 79

Recommendations ................................................................................................. 98 Introduction .................................................................................................. 98 Purchase Motivation Alignment ................................................................ 103

Pursuit of a New Opportunity ........................................................... 104 Defense of an Old Opportunity ......................................................... 104 Denial Strategy .................................................................................. 107 Considerations from the Startups’ Perspective ................................. 108 Motivation Summary ........................................................................ 108

Organizational Placement and Stability ..................................................... 109 Organize to Retain ............................................................................ 110 Location Relation .............................................................................. 111 Logistical Considerations .................................................................. 111

Core Team Retention and Growth ............................................................. 111 The Value of Relationships ............................................................... 112 The Value of the Tell ........................................................................ 114 Avoid Entrepreneurial Erosion ......................................................... 114 Avoid the Boxing in of Job Descriptions .......................................... 115 Avoid the Pitfalls .............................................................................. 116 Growth Catalysts ............................................................................... 119 Leading Transitions .......................................................................... 122

Inverse Effort-based Engagement Model .................................................. 123 Pull to Align ...................................................................................... 125 Push to Innovate ................................................................................ 125

Customer Discovery and Customer Development ..................................... 126 Bridge Management of Stakeholders ......................................................... 130 Lean Startup Models Considerations ......................................................... 132

�Minimum Viable Product ............................................................... 133

x

Build-Measure-Learn Loop Model ................................................... 133 Falsifiable Hypothesis ....................................................................... 134 Pivots ................................................................................................. 134 The Large-Batch Death Spiral vs. Continuous Deployment ............ 136 Metrics and Learning ........................................................................ 136

Innovation Pipeline Management: Corporate Kaban ................................. 138 Sales Model Alignment with Stage ............................................................ 140 Initial Sync with Expectations ................................................................... 142 Financing Model ........................................................................................ 144

Expected Spending ............................................................................ 146 False Growth ..................................................................................... 147

Conclusions ......................................................................................................... 149 Key Takeaways .......................................................................................... 149 Contributions .............................................................................................. 149 Further Areas of Study ............................................................................... 150

Appendices .......................................................................................................... 152 Press Release: Cisco Systems to Acquire Global Internet Software Group,

Invests in Parent Company Global Internet.Com ............................. 152 Press Release: Global Internet, V-ONE agree to share reseller channels .. 154 Press Release: Global Internet Introduces Windows NT Firewall for Companies

Who Want Security, Lack On-Staff Specialist; Available Through Major Distribution Outlets Nationwide. ...................................................... 156

Press Release: Cisco Introduces Windows-NT Firewall Product; Easy-to-Use Cisco Centri Firewall Targets Small/Medium Businesses. ............... 159

Bibliography/References ..................................................................................... 161

Vita .................................................................................................................... 164

xi

List of Tables

Table 1: Blue Ridge Summary Analysis ........................................................................ 41 Table 2: Global Internet Software Group Summary Analysis ....................................... 58 Table 3: Patents Filled by Centri and CSPM Team Issued to Cisco Systems ............... 74 Table 4: Cisco Systems Summary Analysis .................................................................. 84 Table 5: Sample Corporate Kaban ............................................................................... 139

xii

List of Figures

Figure 1: Category Maturity Life Cycle ........................................................................ 12 Figure 2: Growth/Materiality Matrix ............................................................................. 13 Figure 3: Three Horizons Model of Portfolio Management .......................................... 14 Figure 4: Arch of Execution Model ............................................................................... 17 Figure 5: Four Modes of Execution Model .................................................................... 18 Figure 6: Goals of Customer Development Model ........................................................ 20 Figure 7: Four Steps of the Customer Development Model .......................................... 20 Figure 8: Build-Measure-Learn Feedback Loop ............................................................ 24 Figure 9: Major Transitions and Events During the Seven Years at Cisco ................... 76 Figure 10: Technology Commercialization Lifecycle ................................................. 128 Figure 11: Gantt Chart Example of Corporate Kaban ................................................. 140

1

Introduction

Innovation is the key factor in a company’s and our nation’s economic vitality; it

is also one of the greatest challenges facing both. “Underpinning America’s strong

performance over the past two decades has been a culture and environment that optimizes

U.S. innovative performance and entrepreneurship. And yet, there are long-term

challenges the nation must face in order to avoid undermining the competitive position in

the United States.” (Competitive Index, 2007)

This thesis explores how innovative software startups can be affected in today’s

business environment, how the funding environment and exist strategies can affect the

adoption and survival of the innovative technologies they develop, and how, by

understanding specific business models, we can refine models and guidance to help these

teams successfully deliver innovative technologies.

TYPES OF INNOVATION

Understanding the types of innovation is essential for framing the focus of this

thesis. Closing the Innovation Gap (Estrin, 2008a) provides working definitions for the

types of innovations important to engineers and entrepreneurs:

• Incremental innovation—a significant improvement on an existing tool (build a

better mousetrap)

• Orthogonal innovation—repackage an existing tool in a new fashion to create a

new user experience

• Disruptive (breakthrough) innovation—significant revolutions in tools and

thinking

2

This thesis focuses specifically on the preservation of acquired disruptive

innovations and technologies1. Truly disruptive innovations often require longer

development lifecycles, defining of new markets, new channels—all of which require

greater unfettered investment and more time dedicated to those efforts. An environment

that is conducive to supporting the development of disruptive innovations is a well-

managed, well-funded company. It is the author’s assertion that a properly managed

company can acquire disruptive startups and provide for these requirements in ways that

protect and incubate the team and technologies so as to realize broad market acceptance

and cross pollination of their innovations. That is not true in today’s environment, as

illustrated by a recent quote from Bjoern Lasse Herrmann of the Startup Genome project.

“The Kauffman foundation recently showed that more than 90% of all job growth in the

US comes from highly scalable startups,” Herrmann says. “Still, more than 90% of

funded startups fail - we set out to find a way that can reduce this massive failure rate of

startups. The Startup Genome project is the result of us investigating the problem in order

to figure out a solution.” (Bryant, 2011) From the perspective of an acquiring company,

startups equate innovation. Often, they acquire startups to address innovation gaps in

their portfolios.

REALITY SETS IN—THE POSTULATE

The short-term focus of today’s venture capital and angel investing environments

has led to a hyper focus on incremental innovation at startups, which often fail due to

lack of long-term thinking and investment (Stuck and Weingarten, 2005). Because 1 This thesis focuses on those changes that companies must adopt so that startups focusing on disruptive innovations can be preserved. While the models and recommendations can be applied to the other types of innovations, the author focuses on preserving disruptive innovations as only they move companies, industries, and nations significantly ahead of their peers. Fewer and less drastic changes can be made to achieve increased preservations of incremental and orthogonal innovations.

3

software startups are often forced to consider short-term exit strategies, they make

strategic decisions to accept inferior designs, fail to adequately document their

architecture and APIs, release changes, processes, and sacrifice code quality and

completeness to shorten schedules. These tradeoffs doom the startups and their

technologies to a short life at an acquiring company2 (if they are acquired) or prevent

them from being agile when the market or competitive conditions change. Ultimately, the

innovations and technology are often discarded and integration is considered a costly

failure.

Wharton School of Business Professor Robert Holthausen states, "Various studies

have shown that mergers have failure rates of more than 50 percent. One recent study

found that 83 percent of all mergers fail to create value and half actually destroy value.

This is an abysmal record. What is particularly amazing is that in polling the boards of

the companies involved in those same mergers, over 80 percent of the board members

thought their acquisitions had created value. We are beginning to understand some of the

reasons why these mergers fail. This program offers strategies designed to improve your

odds for success." (Holthausen, 2011)

Larger companies acquire smaller ones with the hope that better marketing from a

trusted brand name and a larger customer base can catapult sales on a nosebleed

trajectory. The expectation is that this will happen with less investment in product

development than the startup’s run rate by just maintaining the same engineering team. It

makes sense, right? They just bought a successful company (often the segment leader)

2 This thesis focuses on acquisitions, not mergers. It is assumed that mergers are between two companies of equal or similar maturity level.

4

that had real customers, and they eliminated redundant staff. And for a short time, this

strategy works and everything looks rosy.

Soon after, however, problems tend to arise. The following sequence of events is

typical of failed software acquisitions and mergers (Gayle, 2011). Customers, who have

much higher expectations of the parent company’s products, begin to find fault with

architectural constraints, scale, and quality. The acquired product does not integrate with

the customer’s existing products and solutions, it’s incompatible with critical business

components, etc. As support costs and customer complaints rise, the parent company

pressures the acquired team to add new features rapidly, to support or integrate with all of

the other product lines in the company, and to increase quality with temporary or no

additional staff.

Immediate results are expected from a team that is inundated with bugs, feature

requests, processes, and bureaucracy. (Ingram, 2011) In addition, the team has lost its

leadership to company integration focused meetings and had other key team members

(e.g., sales, marketing, and administrative staff) reassigned or terminated due to overlap

with the parent company’s organization. (Siegenthaler, 2010) The team has also been

given a new marketing staff that is familiar with the parent company’s customer base to

help drive these changes into the product. As a result of the turmoil, acquisition team

members get frustrated and transfer or quit, taking critical system and tacit knowledge

that was never documented or that is poorly transferred to a junior employee hired to take

a senior employee’s place.

The assigned product marketing brings requests from a multitude of segments in

the broader markets. The product gets rushed into a multitude of incompatible segments

(of which the core team has no understanding), where customers push back to have their

requirements satisfied, as they have been oversold the value of the product within their

5

segment. The success of the sales team, not the product, heralds the beginning of an

untimely end to the technology that was trumpeted as a leap forward in innovation just a

few months earlier.

The product continues to deteriorate as programmers with an inadequate

understanding of the intended design and dependencies patch the poorly understood code.

Two to three years into the project, the parent company puts the product into maintenance

mode and withdraws most funding, leaving the product with a small support staff, few of

whom are original team members. During the next round of belt tightening or portfolio

analysis, the product gets an “end of sale” notice and the sales team must meet with

customers to perform damage control and relationship mending for the failed technology

rollout. According to a KPMG study, "83% of all mergers and acquisitions (M&As)

failed to produce any benefit for the shareholders and over half actually destroyed value."

(Gitelson, Bing, and Laroche, 2001)

It is a lose-lose situation, where the acquiring company’s image is tarnished, its

investor’s potential returns are squandered, the acquired team looses its vision and focus

and becomes disenchanted with the politics, and the customers, who see the promise and

value of a new technology, get dragged back and forth between technologies at a huge

capital and educational expense. Most tragically, the technology and team are marred

with a stigma that everyone in the company works to bury.

The team members are treated as failures and are marginalized into risk-free bit

roles until institutional memory of the incident is purged. However, they are embittered

by their treatment and, if they stay, are unwilling to again take the risks that true

innovation requires. At best, they become good individual contributors, but rarely bring

long-term value to the company not easily provided by any experienced employee with

6

similar skills. Innovative minds are shut down or leave to start new ventures (Gayle,

2011). (For more examples, google “founders leave Google.”)

The technology is discarded and rarely, if ever, considered a valid approach to the

problems it addressed. With the team and the technology marginalized, the lessons

learned from building and applying the technology, the empirical, implementation, and

tacit knowledge, is lost and unable to further the field. “The surprising fact is that

companies large and small, established corporate giants as well as brand new startups,

fail in 9 out of 10 attempts to launch their new products.” (Blank, 2007)

If that is not tragic enough, it is not uncommon to see the parent company buy

similar or overlapping technologies (often former competitors of the original acquisition)

after the initial technology push fails, because the company’s leaders recognize the

business need for addressing the problem but consider their initial purchase to have been

a poor approach, implementation, or both. These later acquisitions have the advantages of

having matured more gradually, having remained focused on the problem as they

gradually expanded their scope, and being handed customers when their new parent

company abandoned their previous competitor’s technology (the former segment leader).

These advantages are usually enough to sling shot them across the chasm if they have not

achieved that level of success on their own.

CLARIFYING “SUCCESS”

To address why startups’ innovations fail to take hold after an acquisition, we

must understand what success looks like from the perspective of innovation. For the

purpose of this thesis, successful innovation refers to a lasting influence or redefining of a

field, industry, or competitive landscape based on that innovation or its effects. If it is

7

successful, its influence will be seen in future products, competitors will imitate or

counter the innovation, and customers will pay for those innovations.

For example, the innovation of HTML is a success based on all of these attributes:

web browsers, web servers, plug-ins, ratified standards and wars, toolkits, search engines,

developer tools, and so on emerged because of the innovation that was HTML and the

concept of rendering. Most of the time, we are not talking about this level of innovation.

Consider something less dramatic, such as the QUERTY key layout, which was designed

to prevent the collision of typebars. It has long since been obsolete (e.g., the ball

typewriter), yet its influence persists today and it continues to be copied again and again.

PROPOSITION

With a basic definition of innovation, an understanding of how innovations often

wither in a corporate setting, and a working definition of success, we can explore this

question:

“What’s wrong with today’s business models and guidance that hinders acquired

software startups’ ability to deliver disruptive innovations?”

Disruptive software innovations appear more successful if they originate in large

corporations. However, startups often fail to deliver this level of innovation despite

offering a greater number and variety of breakthrough innovations than large

corporations, which typically develop incremental and orthogonal innovations.

In this thesis, we explore what business models and guidance are critical to this

success and what might be changed within those models or guidance to offer an acquiring

company a better chance of successfully delivering the breakthrough innovations of the

software startups they acquire.

8

NEXT STEPS

Chapter 2, “Literature Review” identifies the business literature used to analyze

the case study. It also identifies those models and guidance extracted from the select texts

that help manage the transition of a software startup into an acquiring company with the

intention of preserving the innovations. The literature review attempts to address the

following key topics: teamwork, planning, execution, development, marketing/sales,

finance, and exit strategies. Last, it identifies the gaps in the existing literature that will be

the focus of the recommendations in this thesis.

Chapter 3, “Case Study: BRSI Core Team” follows a core team originating at

Blue Ridge Software, Inc. in 1995 through its disbanding at Cisco Systems, Inc. in 2004.

It identifies the variety disruptive technologies developed by this team during this period,

follows them through multiple reinventions, and describes the events that led to their

eventual abandonment and disbanding. It also analyzes the transitions of the team relative

to the frameworks and models in the literature today.

Chapter 4, “Recommendations” reiterates key attributes of key existing

frameworks and models. It provides new guidance in the areas of assessing an acquisition

target, defining and valuing the core team, planning the transitions, expectations in terms

of ROI, integration of the core team, execution within the existing organizations, and

customer development.

Chapter 5, “Conclusions” identifies the key takeaways from the

recommendations. It highlights the frameworks and concepts defined in this thesis that

augment the field of business literature as well as identifies areas where further research

is needed.

9

Literature Review

This chapter identifies the tools, frameworks, and recommendations extracted

from the referenced readings that equip the startup team’s and the acquiring company’s

leadership with the tools necessary to support rapid and continuing innovation. These

tools provide guidance for, and address common weaknesses in, planning, execution,

teamwork, development, finance, marketing, and sales.

In search of solutions to the high failure rates of acquired innovations inside of

their acquiring companies, I reviewed the business management literature for the

following specific concepts:

• startup business advice,

• high performing teams,

• team intellect,

• product development models,

• customer identification and acquisition,

• organizational and management models, and

• frameworks for managing innovations.

In reviewing the current literature, I identified those frameworks and models that

can help disruptive innovations succeed both within startups and acquiring companies.

Using the frameworks and models, together with my professional experiences at several

startups and within an acquiring enterprise, this thesis explores what enhancements can

be defined to improve on the probability of preserving the innovations. Specifically, it

demonstrates the value of a startup’s core team (Dodge, 2011) and recommends

frameworks and models to yield an optimal return on investment (ROI) relative to the

acquiring company’s innovation pipeline and the acquired innovative talent.

10

Recent works by Geoffrey Moore and Eric Ries provide tools and frameworks to

solve many of the problems faced by startups and to help companies manage the

innovations that they might acquire. In Escape Velocity, Moore expands his earlier work

on innovation frameworks (Dealing with Darwin, 2005) and chasm crossing models

(Crossing the Chasm, 2002) to address strategies for overcoming stagnancy in portfolio

management. Specifically, the body of work defines organizational and business model

frameworks, identifies conflicts in funding, market applicability, and team composition at

various stages in the models, and reflects on strategies to address competitive solutions

within the same company.

Another body of work, represented by Adams, Blank, Maurya, and Reis,

addresses frameworks that focus on improving the survival rate of startups, including a

focus on market selection, organizational structure, staffing growth strategy, execution,

and meaningful metrics. Both bodies of literature are applicable as an acquired startup

straddles both worlds.

However, while exploring the question of “how to preserve disruptive startup

innovations within an acquiring company?” I found that the body of literature fails to

address the topic directly and ignores the role of the core team in continuing to drive

innovation. The “Recommendations” section of this thesis attempts to augment the works

for Ries and Moore to provide a solid toolbox for acquiring companies. However, it is the

startup team’s transition into an acquiring company that is overlooked and is the primary

focus of this thesis.

The remainder of this literature review is organized in six sections:

• Innovation Management. Describes Moore’s Hierarchy of Power meta

framework. This framework serves as the foundation for integrating the

recommended models and frameworks.

11

• Startup Models. Describes Steve Blank’s Customer Development model

and Eric Ries’ Lean Startup frameworks and models.

• Team Composition and Group Cognition. Explores the often overlooked

value of teams, specifically the relationships, shared history, knowledge,

and memory that is unique to a team.

• Organizational Placement. Identifies key considerations for placing

acquired teams within an existing organizational model.

• Questions Answered. Summarizes the key findings in the reviewed

literature.

• Questions Not Answered. Identifies the gaps in the literature that are

explored in the “Recommendations” chapter.

INNOVATION MANAGEMENT

In Escape Velocity (Moore, 2011), Geoffrey Moore presents a collection of

thirteen models and frameworks that fit at some level within his framework of

frameworks, the Hierarchy of Power. He also defines three transformation playbooks that

apply combinations of these models to be used by a languishing company to transform

execution, vision, or strategy through innovation management. Specifically, he attempts

to manage the innovation pipeline so as to continually refresh a company’s lines of

business with competitive, differentiated products. The thirteen models, organized by

their corresponding Hierarchy of Power, are as follows:

• Category Power

o Category Maturity Life Cycle. Establishes growth expectations for

a category (see Figure 1:) plotted along a theoretical timeline.

Using the timeline, management can postulate potential investment

12

returns as well as orchestrate the timing of releases from a

company’s innovation pipeline.

Figure 1: Category Maturity Life Cycle

o Growth/Materiality Matrix. Displays the company portfolio

relative to contributions to current returns and potential for future

growths. This model assists in managing the company’s portfolio

by focusing efforts on high growth categories that are material to

the business. A material category generates 5-10% of total revenue

or total profit.

13

Figure 2: Growth/Materiality Matrix

o Three Horizons model. Calls for three investment categories with

unique success metrics. In the Harvard Business Review article

“To Succeed in the Long Term, Focus on the Middle Term”

(Moore, 2007), Moore puts forth the principle that portfolio

management requires three time horizons. Horizon 1 corresponds

to the current fiscal-reporting period, its short-term concerns and

the cash cow products and services of today. Horizon 2 revs the

next generation of high-growth opportunities in the pipeline, and

14

Horizon 3 incubates new innovations that can sustain the company

far into the future. Many companies acquire Horizon 3 and even

Horizon 2 startups in lieu of internal innovation, and so in this

thesis, the Three Horizons Model (see Figure 3:) serves as the

primary framework around which acquisitions are intelligently

managed.

Figure 3: Three Horizons Model of Portfolio Management

15

• Company Power

o Competitive Separation model. For a given company, this model

clarifies its reference competitors, identifies its best target

opportunities, and identifies the innovation investments required to

achieve success.

o Two Business Architectures model. Helps narrow the competitive

landscape to a relevant reference set. Options are complex system

model (high margin, low volume) and volume operations model

(low margin, high volume).

o Crown Jewels. Identifies unique company assets that can create

and sustain competitive separation. These assets clarify the areas of

where compatible acquisitions can make sense.

• Market Power

o Nine-Point Market Strategy framework. Playbook for driving a

market segment to a tipping point, or the moment of critical mass

where the company becomes the preferred vendor of the segment.

• Offer Power

o Return on Innovation model. Defines three types of innovation

outcomes and explains why each is important and when relative to

the Three Horizons and Market Maturity Life Cycle models:

§ Innovation for differentiation—Innovation initiatives that

succeed in creating competitive separation from reference

competitors in target markets.

16

§ Innovation for neutralization—��Innovation initiatives that

succeed in reducing or eliminating a competitive separation

achieved by a reference competitor in a target market.

§ Innovation for productivity—Innovation initiatives that

improve the return on resources deployed by increasing

their yield.

o Six Levers model. A playbook for extracting resources from

context to repurpose for core. It prioritizes productivity

innovations.

o Price/Benefit Sensitivity model. Framework to prioritize

investment in neutralization innovations.

o Core/Context model. Maps the competitive-separation strategy into

specific differentiation (disruptive) innovations.

• Execution Power

o Arc of Execution and Four Modes of Execution. Provides the

framework for organizational design and business transformation,

again relative to the Three Horizons model; only in this context, it

refers to the invention, deployment, and optimization phases and

identifies the tipping points between them as the trigger for

transition between phases.

17

Figure 4: Arch of Execution Model

18

Figure 5: Four Modes of Execution Model

The goal of the Hierarchy of Power models is to drive continuous innovation

within a large company, which includes acquiring startups to populate the innovation

pipeline as focused around the prioritized Crown Jewels and vision. When viewed

through the acquisition lens, the Hierarchy of Power provides an applicable execution

strategy for managing acquired startups. Focused around the strategic planning and

budget process in terms of execution; it clarifies the priority of efforts relative to the

vision and provides the data required to make tough decisions when allocating budget.

Moore prioritizes Horizon 2 as the fragile link where many innovations critical to

the company’s future are often dropped due to the increased marketing costs required to

achieve a tipping point. He defines the organizational bucket, Horizon 3, where new

technologies are to be incubated and defines the concept and value of the innovation

19

pipeline, however, he does little to ensure that the team survives. The frameworks apply

to managing startups, as they provide the focus and identify gaps that need funding

within the innovation pipeline, but not much focus on it. He does not draw the conclusion

that the core team is central to innovation, although he does recognize the different

executive skills required to oversee each horizon.

Moore also calls out that most Horizons take two to three years to cross, which he

states is inconsistent with the demands of business which typically desire one year or

less. For greater reward, they can be persuaded to fund two years, but they find it very

difficult to invest for three years before reaping the results. To justify these investments,

Moore points out that the metrics are important, but different for each horizon. However,

he does not define the full set of metrics to use. (Ries addresses this issue by proposing

the Innovation Metrics model, which apply directly to Horizons 2 and 3.)

The following section explores selected models recommended for and used most

by today’s successful startups (Marmer, Hermann, and Berman, 20011).

STARTUP MODELS

In The Four Steps to the Epiphany, Steve Blank defines the Customer

Development model. It provides a startup (or Horizon 3 team within an enterprise) with

the tools and techniques to quickly iterate and test each part of the business model

(Figure 6:). Execution of the model depends on the business type, as distinguished by

startup type and market type. Whether an early stage startup or Horizon 3 team, the

primary focus of the organization is to identify a repeatable and scalable business model

for a product or technology.

20

Figure 6: Goals of Customer Development Model

(Copyright 2010. Steven G. Blank.)

Figure 7: Four Steps of the Customer Development Model

(Copyright 2003. Steven G. Blank)

As depicted in Figure 7:, the Customer Development model defines four steps:

§ Customer discovery. Identifies the customer for the product and

determines whether the problem being solved is important to them. The

step assesses the correctness of key assumptions in the business plan,

21

specifically the product, problem, and customer. It identifies a strong

product-to-market fit.

§ Customer validation. Develops a playbook of proven, repeatable sales

processes validated against early adopter customers. This playbook

provides a roadmap for future sales and marketing teams, and with the

customer discovery step complete, it also validates the business model.

These first two steps correspond to Horizon 3 in Moore’s Three Horizons

model and to the invention phase of the Arch of Execution model.

§ Customer creation. Creates customer demand. This occurs after the

customer has been validated to control the spending until the product-to-

market fit is well defined and proven. This step drives demand into the

selected sales channel, and it is where big spending occurs. It corresponds

to the transition to Horizon 2 in Moore’s Three Horizons model and to the

deploy phase of the Arch of Execution model.

§ Company building. Transitions the product from the informal learning-

and discovery-focused team to the team built around mission-oriented

departments focused on exploiting the early market success of the

customer creation step. It corresponds to Horizon 1 in Moore’s Three

Horizons model and to the optimization phase of the Arch of Execution

model.

As indicated in the descriptions of the steps, Blank’s models easily fit within he

Hierarchy of Powers framework. Further, the transition between customer validation and

customer creation steps corresponds to the first tipping point in the Arch of Execution,

and the second tipping point is represented by the transition between the customer

22

creation and company building steps. Both transitions also correspond to the transition

mode in Moore’s Four Modes of Execution model.

Blank’s model and guidance is equally applicable to startups and Horizon 3

incubation teams in enterprises. The objective of this model is for the product to cross the

market chasm as defined in Crossing the Chasm (Moore, 2002) and the Category

Maturity Life Cycle as quickly as possible. Blank’s model applies because it can

accelerate this crossing within the two-year window, which Moore defines as the critical

funding threshold in enterprises.

Blank further defines the desired composition of the team in terms of the expertise

required during the customer develop and customer creation steps, which can be

leveraged by an acquiring company to distinguish among the skills and expertise required

between Horizon 3 and Horizons 2 and 1. While Moore identifies a distinction in teams

and the required leadership skills within phases of the Arch of Execution, he does not

clearly address the broader team composition requirements. Blank defines the roles and

responsibilities of required team members, the required interactions and customer facing

responsibilities of the roles within the functional areas of sales/marketing and product

development. He stresses the importance of having these early team members get out of

the office and listen to the customers. He convincingly argues that this effort saves time

by not wasting effort building the wrong product or trying to sell to the wrong market

segment.

In The Lean Startup (Ries, 2011), Eric Ries identifies over nine models and

frameworks:

§ Validated Learning. The core framework strives to test hypotheses and

obtain both quantifiable and qualitative data about the test results so that a

team can learn and adapt to that learning. This learning ensures that the

23

team is developing a technology that will be accepted in the market place,

that they are targeting the correct market, and that their business models

will enable the strongest growth possible.

§ Falsifiable Hypothesis. Framing any of the plethora of assumptions made

about a startup, such as business model, customer pain point, customer

segment, product features, etc., as a falsifiable hypothesis allows it to be

tested for accuracy. This technique avoids entrepreneurial rationalization

and the perpetuation of wasted efforts.

§ Build-Measure-Learn Feedback Loop. This framework accelerates the

validated learning process. The build stage leverages the minimum viable

product, batch, and kaban models, the measure stage focuses on

innovation accounting, and the learn stage leverages the pivot, five whys,

pull rather than push, and the engines of growth models.

24

Figure 8: Build-Measure-Learn Feedback Loop

Copyright 2010-2011 Eric Ries

§ Minimum Viable Product (MVP). The MVP serves as the basis for a

specific market test. It defines a product, prototype, or pitch in terms of a

constrained change in feature or function. Ideally, it reduces the number of

variables under test to one. This model tests both the value hypothesis,

whether that particular change improves or reduces the customer’s

attraction to the product, and its growth hypothesis, whether the change

makes the product more likely to be recommended to peers. Adhering to

this model accelerates learning and reduces the time spent on undesired

features. It reduces blind development of supporting feature by first

understanding whether the minimal set increases value or growth.

§ Kaban. A model for controlling the product-to-fit of feature development.

Essentially, it extends the backlog model of Agile to include four stages:

25

backlog, in progress, built, and validated. Until the feature is

independently validated, it is not included in the product. This model

prevents costly “down the road” corrections and customer issues within

the release software trains.

§ Innovation Accounting. A framework for objectively collecting and

measuring actionable metrics, which are actionable, accessible, and

auditable. He recommends funnel metrics (acquisition, activation,

retention, revenue, and referral) and uses cohort analysis and A/B split

testing to objectively determine what the test results teach. Innovation

accounting also distinguishes between actionable metrics and vanity

metrics, which are metrics presented to business unit leaders or venture

capitalists that provide no value to the learning; they indicate no action

one way or another, they are not tied to a specific feature or work to

indicate relative value, and they cannot be compared or studied further

because they cannot be traced directly to a customer.

§ Pivot or Persevere. A framework for learning whether to pivot (change a

basic assumption about the business) or continue on with the next

iteration. Identifying required pivots is the goal of the Build-Measure-

Learn Feedback Loop as they indicate an aspect of the business that is

hold back growth. Possible pivots include the following:

o Zoom In. Narrow the scope of the product.

o Zoom Out. Expand the scope of the product.

o Customer Segment. Target a different customer segment.

o Customer Need. Target a different pain point.

o Platform. A change from an application to a platform or vice versa.

26

o Business Architecture. A change in the basic business model.

Correlates directly to Moore’s Two Business Architectures model.

o Value Capture. A change in the monetization or revenue capturing

method.

o Engine of Growth. A change in then growth strategy to achieve

faster growth and profitability.

o Channel. A change in the model used to deliver the product to the

customer.

o Technology. A change in the technology used to achieve the same

solution.

§ Batch. A framework for defining the amount of work to be performed

during the build phase. Typically, the smaller the batch the better. And, it

helps to avoid a key concept referred to as the large-batch death spiral,

which is discussed later in the “Recommendations” chapter.

§ Pull Rather than Push. A framework for identifying what experiments to

conduct as part of the validated learning process. It is focused on customer

requests, but it does not guarantee that the request will be realized in the

product. This model ensures that the product does not bloat with features

that do not help drive the growth and adoption of the product.

§ Three Engines of Growth. A framework that identifies three engines of

growth: sticky, viral, and paid. Understanding which of these models

apply to the startup allows the team to focus on those metrics that matter

to them, which in turns allows them to define a better product-to-market

fit. This framework brings into relief the metrics that determine whether

27

the business assumptions, such as pricing and channel, are achieving or

inhibiting growth.

§ Five Whys. A framework for using a simplified method of inquiry around

root cause analysis.

Ries’ frameworks can be applied to help products cross from Horizon 3 to

Horizon 2, as well as from Horizon 2 to Horizon 1, quickly and efficiently. He provides a

unique perspective on the metrics that should be used, and he provides an execution

model (on the ground) that when used within the executive management frameworks

provided by Moore (and complimentary to the customer acquisition models of Blank)

serve to ensure that the technologies are developed as quickly and accurately as possible

with minimal waste and minimal spend.

The following section evaluates key attributes of teams that should be considered

when managing acquired teams and considering the organizational roles they might hold.

TEAM COMPOSITION AND GROUP COGNITION

When considering the attributes of core teams that perform well, both at startups

and within existing companies, Paul Graham’s antidotal observations of hundreds of the

co-founders of startups applies directly to the survival of the core team (TechCrunchTV,

July 2010). In his observations as the head of Y’Combinator (a leading startup seed

funding group in Silicon Valley), he states that a key attribute is a common past and

personal friendship that extends beyond the current startup effort. This history keeps the

team engaged and loyal to each other when difficulties arise.

Likewise, acknowledging that teams have a unique team cognition and shared

memory system is critical to valuing the core teams are acquired in startups. Their shared

experiences enable them to recognize each other’s strengths and weaknesses, coordinate

28

activities more effectively, and share a common knowledge and processes required to

perform their work (Moreland, 1999). This shared knowledge is instantiated as the team’s

transactive memory system (TMS), which is defined as the cooperative division of labor

for learning, remembering, and communication relevant team knowledge (Lewis, 2003)

or knowing who knows what in the team. This shared understanding is fragile, and it, as

well as social functioning, can be affected by the role and membership change (Moreland

and Argote, 2003). However, it is critical to the rapid sharing of ideas, the shared

cognition, and the overall team performance.

TMS processes are the team-specific processes and frameworks that influence

learning, communication, and recall of the individual members. In evaluating the

“effects of group membership change on group cognition and performance, in the context

of a knowledge-intensive task,” Lewis et. al. find that composing the team of oldtimers

and new members results in ineffective TMS processes and lowers the performance of

the group (Lewis, Belliveau, Herndon, and Keller, 2005).

Cross-understanding is a team-level construct that contains each team member's

understanding of each other's mental model; it is the extent to which team members

understand other members’ beliefs, preferences, and sensitivities to particular issues

relevant to the task. Given that “low cross-understanding is associated with low group

learning and performance and that high cross-understanding is generally associated with

high group learning and performance”, it can be inferred that a unique high cross-

understanding construct is an attribute of effective core teams that enables the team “to

make the most of their diversity by encouraging members to surface, discuss, and

integrate their different understandings and perspectives.” A “member who is cognitively

central with respect to cross-understanding can control what information is discussed,

repeated, and integrated into the group’s product” while still moving the larger team

29

toward a common goal (Huber and Lewis, 2010). The proper consideration of this

research relative to the selection and transition of a startup team into an acquiring

company is key to maintaining continued high performance, preserving the innovations,

and being able to leverage the innovative capabilities of the team in the future.

The following section summarizes the organization placement issues identified in

the literature and presents the recommendations for integrating acquired teams into the

acquiring company.

ORGANIZATIONAL PLACEMENT

A long-standing issue is the conflict of interest that results when emerging

technology teams are placed in the same business unit or managed as part of the same

portfolio as the businesses they are intended to replace. As early as 1985, Drucker

identified the key organizational placement and funding conflicts found in corporations

that affect upcoming innovations that threaten to supersede established product lines.

Similar conflicts are a predictable corollary of acquired technologies. These

organizational concerns are further refined by Christiansen and then succinctly defined

and addressed from the top-down by Moore in Escape Velocity. Each of these authors

recommends distinct organizational structures, funding, and leadership for emerging

innovations and the business’ current flagship products. Moore’s Three Horizon and Arc

of Execution models provide an elegant framework for considering the distinct needs and

requirements of the organizations.

The following sections summarize the recommended findings and unaddressed

gaps in the reviewed literature.

30

QUESTIONS ANSWERED

To summarize, the existing literature, specifically the compendium of frameworks

provided by Geoffrey Moore (Sept. 2011), answers the questions of what the goals and

focus should be for an acquiring company, and how to organize, manage, and execute the

aggregate enterprise to ensure that an innovation pipeline exists within the acquiring

company. The literature defines the organic nature of team intellect and the dysfunctions

that can occur when team composition changes. The literature highlights additional

problem areas that when properly considered can help prevent transition failures.

Blank builds upon Moore’s earlier work in Crossing the Chasm to prescribe how

to iterate to find the correct customer; a direction that should be re-evaluated when a

startup is acquired and at each transition in the Moore’s Three Horizons Model. It

provides execution frameworks to ensure that the innovation matches the target market,

as well as how to develop and verify a good product-to-market fit (Blank, 2007). Blank

also defines a unique organizational model that should be practiced prior to crossing the

chasm.

Last, in The Lean Startup, Ries provides product development and operational

frameworks that enable rapid development of cost effective, high growth and targeted

technologies. He also includes extensions to Blank’s frameworks that improve product-

to-market fit and reduce wasted effort.

QUESTIONS NOT ANSWERED

When considering that acquisitions are routinely used to address holes in the

innovation pipeline, a noticeable gap in the existing literature is around the idea of

capitalizing on the startup team to future populate the innovation pipeline beyond their

acquired innovations. The research around teams provided by Lewis et. al. combined

31

with the case study depicted in the next chapter lays the foundation for the premise that

acquired core teams have unrealized value relative to the innovation pipeline.

The premise of this thesis is that by preserving the core team and their roles, you

have an effective team to drive the innovations to the next horizon, at which point, the

team can be redirected to the next up-and-coming innovation at the same horizon as their

initial acquisition. The redirection model keeps the innovation pipeline full, the acquired

teams engaged and invested, and improves the company’s long-term health and stability.

Given that premise, the existing literature also fails address how to manage a

startup’s transition into an acquiring company. Specifically, it does not answer how to

assess whether a target startup team will be a good long-term fit with an acquiring

company, how to integrate that startup team with the existing management and

organization, what that team should look like so as to maximize the potential of the

acquisition investment, or how to engage the core team so as to maximize the possibility

that the innovations will survive and cross-pollenate effectively. It neither prescribes

models for engagements within the company nor identifies the gaps that can be created

within the team during the acquisition and how to avoid or address those gaps.

In the “Recommendations” section, I present a series of recommendations that

combine frameworks, strategies, and considerations as they should be applied to preserve

the core team intact. In turn, this retention enables long-term innovations to succeed and

flourish. I extract key aspects from the various models and overlay them with the models

and guidance that I have defined. The models unique to this thesis define how the

management of the acquiring company must position itself relative to the startup’s core

team; however, a few models and perspectives remain peculiar to the core team itself and

its positioning relative to an acquiring company.

32

Case Study: BRSI Core Team

This chapter follows a core team over 10 years, from its formation at Blue Ridge

Software, Inc. in 1994 through its disbanding at Cisco Systems, Inc. in 2004. It identifies

a variety of disruptive innovations developed by this team during this period, follows

them through multiple reinventions, and describes the events that led to their eventual

abandonment and disbanding. This chapter presents the findings of how the case study

performed relative to the models described in the “Literature Review” section and

whether that performance met the expectations of the models.

The latter part of this case, where the team is at Cisco, might be construed as a

worse case scenario. However, the example speaks to the missteps and simple shuffles

common in large corporations that are disastrous to both to the technological innovations

and to innovative teams. Similar issues occur at many technology stalwarts that make

frequent acquisitions, such as Yahoo (Gayle, 2011), and Google (Fisher, 2011). More

importantly, this latter part illustrates the resiliency of one team and demonstrates how

quickly a team can dissolve when core team members depart.

METHODOLOGY

This case is based on the recollections of the author and supported by event-based

research to reconstruct the timelines. It identifies the core team and their roles, and it

follows the collective team (the BRSI team) through their acquisition by Global

Internet.Com and the later acquisition by Cisco Systems, Inc. The case concludes with

the disbanding of the team following multiple transitions within Cisco. Attempts to

interview key executives, while initially accepted, were rejected once the interview

questions were provided.

33

Three distinct periods are recounted and the strategies and transitions are analyzed

relative to the models defined by Moore, Blank, and Ries to identify which aspects and

outcomes of the transitions were aligned with the guidance and which were not.

This case includes four main sections:

• Core team. This section identifies the core team and their roles. It

establishes the composition and experience level of the team.

• Blue Ridge Software, Inc. This section follows the team and their

innovations from the formation of Blue Ridge in 1993 to their being

acquired by Global Internet in 1995.

• Global Internet.Com, Inc. This section follows the team and their

innovations from Global Internet to their being acquired by Cisco Systems

1997.

• Cisco Systems, Inc. This section follows the team and their innovations

through various groups within Cisco Systems from 1997 until they

disbanded in 2004.

Each of the sections following the team describes includes three subsections:

• Key innovations. This section identifies the key innovations developed by

the team.

• Transition highlights. This section discusses the transition and what

happened to the team during the transition. The recollection is loosely

focused on how the team was organized, how they engaged with the

parent company, and the funding landscape at the time.

• Analysis of Transitions and Issues. This section provides a general

analysis of the transition and management of the core team. Each section

concludes with a summary table that identifies the recommended models

34

from the literature review and highlights how those models applied or

could have been applied to example scenarios from the case to improve

the outcome.

CORE TEAM

Every team has core players and supporting members. This recollection is not

constructed to dismiss the valuable and, at times, crucial contributions of the many

excellent supporting members on the team. The concept of core, in this sense, really

determined the direction and focus of the team. When one of the core members was

removed from the effort, the ability of the team to execute was hindered, whether it was

through flow of communications, vision, design, or team intellect. The core team

organized not-at-work activities for the whole team, such as paintball, dinners, parties,

and later, trips to see where BRSI had started. They also acted as liaisons to other teams

and offices on behalf of the team. At times, the team grew to over 80 people.

The core team of this case study revolves around the following members:

• Scott L. Wiegel. Software Developer and co-founder of Blue Ridge

Software. Former engineering director of Addamax Corporation and

security developer for Harris Corporation. Scott provided the vision and

the technical direction for the team. While not even close to the sole

innovator, he was the common creative spark for the team. His ideas were

typically years in advance of actual market adoption. He also drove the

execution of the team, especially when he was on site.

• Alan M. Carroll. Software Developer. Alan joined the core team in the

transition from BRSI to Global Internet. Prior to that, he was a contract

software developer with NorthPoint Software. His experience included

35

developing NextStep and Windows NT device drivers for MicroMed and

contributing to Manning Environmental products. He held a Ph.D. in

Human Computer Interactions and a B.S in Computer Science from the

University of Illinois. He interned at IBM Watson for one summer. Alan

was the lead architect on the subsystems and infrastructure of the systems

developed, and the lead architect and designer of the overall system. He

also contributed heavily to the user interface.

• Susan Hinrichs. Software Developer. Susan also joined the core team in

the transition from BRSI to Global Internet. Prior to that, she contracted

with Manning Environmental products. She was a former software

development and testing engineer at Addamax Corporation. Susan held a

Ph.D. in Parallel Compiler Technology, Carnegie-Mellon University and a

B.S in Computer Science from the University of Illinois. During her

summers as an undergraduate student, she interned at IBM Watson, and

her PhD research included working closely with Intel on next generation

chip designs. Susan was the database designer and developer, as well as

key consultant on all designs.

• Blaine McNutt. Technical Communicator. Blaine joined the core team

from FutureSource, Inc. Previously, he documented the retrofit and

upgrade procedures for the AINet system at Bell Labs in Naperville,

Illinois. Prior to that, he wrote proposals for Radian Corporation and

developed presentations under Air Force contracts with Radian. He held a

B.A. in Engineering with a minor in Technical Communications from

Texas Tech University. Blaine developed training, marketing, user

documentation, help system, API documentation, technical specifications,

36

and contributed to the user models for security system designs. Blaine also

acted as the boundary communicator, especially when the core team got

out of sync.

• Bradley A. Frank. Software Developer. A graduate of Rutgers

University, Brad served as a member of the technical staff for AT&T Bell

Laboratory. As an original member of the team at Blue Ridge, Brad served

the lead software developer for kernel level development.

• Richard A. Wells. Software Developer. At the time of the formation of

the BRSI core team, Rick was the owner of NorthPoint Software. He was

an experienced entrepreneur and former a real-time computer systems

programmer for IBM Corporation at the NASA Manned Spacecraft

Center. He served in various technical and management positions with the

Data Systems Division of Gould, Inc. In 1977, he co-founded KMW

Systems Corporation, which he took public and served as Chairman and

CEO for seven years. Rick received a BA degree from the University of

Texas and a MS from the University of Illinois. As a member of the BRSI

core team, Rick was the lead software developer and architect for user

interfaces, and he was a trusted advisor who helped keep the team united

across locations, despite being a remote worker throughout his tenure with

the team.

The relationships among the core team were intricate and complex, extending

beyond a simple working relationship. In addition to a previous shared work history, the

team members developed close family bonds.

Previously, Susan worked for Scott at Addamax before pursuing her Ph.D. in

Pittsburgh. (She also sold Scott her canoe when she moved to Pittsburgh.) While under

37

contract with FutureSource in 1995, Alan and Blaine were roommates until Alan’s wife,

Susan, completed her Ph.D. thesis, and later became the godfather of their first born son.

Scott and Blaine were also best friends, and Blaine later became roommates with Scott’s

younger brother, who was hired by Global Internet Software Group in 1997. At times,

Susan, Alan, and Blaine all rented properties from Scott. Brad’s children attended the

local daycare at a discount, as Scott owned it too.

Rick had worked with Alan’s father, which is how Alan later came to work with

Rick at NorthPoint Software. Alan and Sue both worked for his father, who owned the

Manning Environmental. Following the acquisition by Global Internet, Scott married

Blaine’s cousin, although they later divorced.

These intricate webs of relationships, exemplifying Paul Graham’s antidotal

observations (Graham and Rusli, 2011), kept the core team together through the many

difficult times experienced both at Global Internet and Cisco Systems, Inc. The

following section explains how the team first came together at Blue Ridge Software, Inc.

and it describes the initial innovations they stared developing at Blue Ridge, which were

leveraged extensively in their latter efforts and technologies.

BLUE RIDGE SOFTWARE, INC.

Blue Ridge Software, Inc. (BRSI) was located in the small bedroom community

of Monticello, Illinois, located on I-72 between the larger towns of Champaign and

Decatur. The office was located on the town square, and originally had five employees.

BRSI formed after the breakup of Addamax Corporation in Champaign, which developed

trusted operating systems based on ATT System V and Berkeley (BSD) variants of

UNIX. Originally founded in 1986, Addamax Corporation dissolved in 1993 with assets

dividing into BSRI, which focused on Windows NT security and founded by Scott

38

Wiegel and Michelle Ruppel, and Argus Systems Group, which focused on UNIX

security.

The following sections identify the key innovations developed by the core team.

Key Innovations

At BRSI, the initial staff of Scott, Brad, and two additional software developers

licensed the Microsoft Windows NT TCP/IP network stack source code and developed

the Trusted Network Technology (TNT), a B-level DNSIX 2.1 compliant network stack

for the Microsoft Windows NT operating system. Scott also laid the conceptual

groundwork for the Audit Management System (AMS); a planned but never realized

system to correlate audit events and identify behavior based attacks and system

compromises. To fund these product development efforts, the staff worked on contract

developing custom software applications for customers.

It was under the umbrella of such a contract that the “core team” came together in

February 1995. BRSI had accepted a contract with FutureSource, Inc., a Chicago Board

of Trade (CBOT) futures data trading company. BRSI and NorthPoint Software were

contracted to co-develop a next generation CBOT trading system.

The two teams developed an event-driven, object oriented database and a high-

speed local bus control protocol. BRSI owned these technologies, and they leveraged

them in future products. Originally, these technologies were targeted as the core

technologies for the AMS product. The team also developed an audit event and reporting

framework for pulling high-speed events off of a feed source and storing them in a

lossless manner. The underpinnings of the graphical interface framework were also

developed during this period. All of these innovations or the concepts they introduced

would be leveraged over the next 10 years.

39

The following section highlights some key details about the transition from BRSI

to Global Internet and the effects of this transition on the core team.

Transition Highlights

In August 1995, BRSI was purchased by Global Internet.Com. The entire team

was retained in their existing roles. As a contingency of the closing, the non-employee

core members were hired into the company as part of the transition. Brad joined Scott at

BRSI as a founding employee. Blaine, Alan, and Rick worked closely with Scott and

Brad in the months leading up to the acquisition, and they officially transitioned onto the

core team as a term of the closing of the sale of BRSI to Global Internet. Upon the

completion of her degree at CMU, Susan formerly joined the team when Global Internet

hired her.

The team was not relocated. The team stayed in Monticello in the BRSI office,

and Rick Wells remained at his remote location in Mason, Texas. Additional travel was

required, as Scott and key team members visited the San Mateo, California site to learn

more about the desired direction of the company.

The Global Internet executive management team improved the gathering of

market requirements, identified the target Windows NT firewall market, provided access

to better sales channels, and drove a focus on time to market. However, the transition was

not without conflict. The former BRSI co-founders did not always agree with the

direction nor were they comfortable in their roles. As a result, Michelle Ruppel resigned

in 1996. Steve Sutton also departed in 1996 following the decision to transition the

Centri TNT product to Argus Systems Group.

The following section analyzes the team’s transition from BRSI to Global Internet

relative to the frameworks recommended in the literature review.

40

Analysis of Transitions and Issues

BRSI self-funded rather than seeking venture capital. This model worked well as

long as the contract work furthered the product development, but it made contract

negotiations difficult and the requirements of the BRSI products and the contracted work

often conflicted, resulting in rework or the development of features that were not

germane to one team or the other. This model also made it difficult to seek out potential

customers and to develop the BRSI product technologies beyond a very slow,

incremental innovation perspective.

The transition from Blue Ridge to Global Internet was well managed and

effective. The effectiveness was due in part to the income constraints of Global Internet,

the fact that no existing development group was in place to drive standards into the BRSI

team, and a belief by the GI executives in the Scott’s leadership abilities. The intention of

Global Internet was to hire an effective “core team” that could build the products that

they identified a need for in the Internet market. At the time of the acquisition, Global

Internet had two other teams: Cohesive Systems, a network consultant group, and

MIDnet, a service provider group. In May 1996, a third group, Forte Computer Systems

(another consultant group) was added.

The GI team allowed the completion of outstanding contract obligations with

FutureSource, although requested that the scope be limited to that which had already been

committed. As BRSI retained the technologies under contract, the effort generated

sustaining income for the team and allowed some of the core technologies to be

developed. The BRSI team was prepared for the level of effort and able to innovate

quickly and adapt to changes in the market quickly. The executive team at Global

Internet, for the most part, allowed the team to find their way within the charter and

frameworks that set the direction for Global Internet.

41

The team was kept intact, not relocated, and key members who were not part of

BRSI were brought on board, which was due to the negotiation skills of Scott Wiegel as

much as those of Global Internet executives. However, GI executives understood that

those members were critical to the team. The group was organized as an independent

team, with Scott and the BRSI team reporting directly to GI executive management.

The GI team also filled in some of the key missing roles (market intelligence) and

supported the transfer of resources to support the BRSI team (test engineers), and the

Cohesive team provided access to customers for investigative discussions and domain

expertise in network and firewall administration. The initial transition to Global Internet

did not have any shortcomings.

Blue Ridge is an interesting case model; so many things were done well under

Scott’s leadership, yet the company never grew beyond a few early adopter customers in

the defense markets. Moore’s model that focus on portfolio management do not apply to

the Blue Ridge, as it was a startup that had a single product. However, the models

presented by Blank and Ries do apply. Table 1: summarizes specific activities at BRSI

relative to the recommended models in the literature review.

Table 1: Blue Ridge Summary Analysis

Table 1, cont.

Applicable Stage or Model Activity

Customer Development Framework (Blank)

Customer discovery Developed initial TNT product and secured three early

adopters. However, the product iteration to fit was

driven more by entrepreneurial vision than by

customer validation. The business model required high

42

Table 1, cont.


volume sales into the same accounts, and Microsoft

Windows NT was not a platform that was deployed in

many markets in 1994 and 1995, as the product was

first released by Microsoft in July 1993. The attempt

was to re-segment the existing market into a trusted

Windows NT niche market; however, the Windows

NT market was a niche in itself, and fundamentally,

the team could not sustain itself on when the identified

market was using the TNT product to evaluate

Windows NT as a replacement for secure UNIX

installations.

Customer validation Stalled. The product-to-market fit was never achieved,

as the TNT product never progressed beyond the

evaluation phase (never deployed at scale). Therefore,

the business model was not validated.

Customer creation Not applicable (N/A). Stalled in customer validation

stage.

Company building N/A.

Lean Startup Framework (Ries)

Validated learning Pitched the idea for AMS via a brochure and a

technical paper rather than developed the product.

However, there was no attempt to collect quantitative

43

Table 1, cont.


or qualitative feedback around specific features or to

prioritize that effort.

While TNT was in development, existing and

prospective customers were engaged regarding

upcoming features. The team performed installs on

site to learn more about the environment and

problems.

Falsifiable hypothesis No formal efforts were undertaken to define falsifiable

hypotheses around the business models, customer,

market, or product features.

Build-Measure-Learn Feedback

Loop

The initial release of the TNT product took over a

year; during that period, the team hunkered down and

coded. No effort to accelerate the learning was made.

However, the team was not secretive about their

efforts.

Minimum viable product After the initial release, most TNT releases were

essentially a minimum viable product. The team did a

good job of building out the bare minimum. However,

no attempts were made to measure the success of the

MVP or to test the hypothesis of the changes before

shipping them. No attempt was made to measure the

value or growth hypotheses.

44

Table 1, cont.


Kaban No use of the Kaban model. No formal validation of

features with respect to market acceptance was

conducted.

Innovation accounting Metrics were not collected around the use of the

product. However, funnel metrics—acquisition,

activation, retention, revenue, and referral—could

have provided insight into issues that might have

accelerated adoption. Split test and cohort analysis was

not possible due to the small number of early adopters.

The business model really focused on the low volume

of customers who could afford a higher cost. The pain

point was not great because existing solutions were

available on other platforms that were more complete

implementations of the DNSIX requirements

specifications.

Pivot or persevere As conceived and built, TNT did not have a

sustainable market, therefore, a pivot was in order. No

attempt was made to pivot.

Batch Because of the intermittent contracting work required

to sustain the team, the batches following the initial

release of TNT were fairly small. However, they could

have been smaller.

45

Table 1, cont.


Pull rather than push Because the market segment with a critical need was

never defined, TNT’s focus was a push model. In

addition, no validated learning was conducted to

ensure that the features pushed were the ones that

would accelerate growth. The model was more of one

where adding features was the method of trying to

achieve market adoption.

Three Engines of Growth The engine of growth analysis was never performed.

As a result, the team began contracting to sustain

development in the TNT product. That effort was a

symptom that something was wrong.

Five Whys Blue Ridge did not use of the Five Whys or an

equivalent root cause analysis model.

Hierarchy of Powers Framework (Moore)

Category Power

Category Maturity Life Cycle No analysis of the category maturity life cycle was

performed. This analysis could well have identified

that the specific target market was not large enough to

sustain the Blue Ridge team.

Growth/Materiality Matrix Not applicable, as there were no competing products at

BRSI. The only product was TNT, which was resource

starved by software development contracts; however,

46

Table 1, cont.


no other funding models were pursued.

Three Horizons Model This model was not applicable per say, but a pipeline

of new products was planned and in the early

idea/incubation stages.

Competitive Separation The sole developer of Windows NT-based DNSIX

software.

Two Business Architectures Low volume, high margin.

Crown Jewels The unsuspected crown jewel for BRSI was the

Microsoft TCP/IP stack code under exclusive license

to modify. While this differentiation was solid, it was

fragile in the sense that Microsoft could simply revoke

the license.

Market Power

Nine-Point Market Strategy This model applied to Blue Ridge in that this area

need refinement; however, the Customer

Development, Validated Learning, Falsifiable

Hypothesis, and the Engines of Growth models were

better vehicles for iterating to address these nine points

at this early stage.

Offer Power

Return on Innovation Using the model to assess the validity of the

innovation relative to the market was difficult given

47

Table 1, cont.


the small number of customers.

Six Levers This model did not apply; the team was never more

than five people, which was too small. With the

market not affording even the staff at the time,

contracts were the only way to sustain the business.

Price/Benefit Sensitivity The price/benefit sensitivity would categorize the

market as one that required customer intimacy at a

premium price. However, the pricing was based on

installed seats and customer kept TNT under

evaluation while budgets were considered. When they

did deploy, they deployed slightly larger test cases,

which was not enough to sustain BRSI.

Core/Context Little context existed; the team focused on

development and close customer engagement.

Execution Power

Arc of Execution The team remained in the innovation phase, never

reaching the initial tipping point.

Four Modes of Execution Not applicable. The team construct recommended by

Blank was most applicable. Additional customer

engagement and feature prioritization was required.

The team needed someone who was more marketing

driven, but they simply could not afford one without

48

Table 1, cont.


venture capital. BRSI self funded with angel investors

and software development contracts.

While the team essentially came together at BRSI, and its future direction was

determined by the Global Internet focus. The following section describes the team’s

product focus and innovative efforts at Global Internet, which were key to the group’s

later acquisition by Cisco Systems.

GLOBAL INTERNET.COM, INC./GLOBAL INTERNET SOFTWARE GROUP

BRSI was purchased by Global Internet.Com, Inc. in August 1995. While Global

Internet was headquartered in Palo Alto, California with an office in San Mateo, the

BRSI team remained in their original offices in Monticello. The BRSI team was

instructed to extract from the FutureSource contract as quickly and ethically as legally

possible.

While the credentials of the BRSI team were very strong in security, the GI team

focused on building that image. The BRSI team was originally identified by the GI

executives because they held the only license to the Microsoft Windows NT TCP/IP

stack, a license that most of the Microsoft team remained unaware of until GI began

advertise this fact as a competitive advantage relative to other Windows NT network

security firms. Once other Microsoft partners and developers began complaining about

competitive fairness, it was clear that Microsoft intended to pull the license at its first

legal opportunity.

Development manager, Steve Sutton, joined the former BRSI team temporarily as

the team supported a Department of Defense contract to enable Fortezza support in

49

Microsoft Windows NT as part of key and privilege management infrastructure

developed under the Multi-level Information Systems Security Initiative (MISSI). It was

under the effort to build the BRSI security credentials that this MISSI work took place.

The Global Internet executive management team improved gathering of market

requirements (identifying the need for Windows NT firewalls), provided better sales

channels, and drove a strong focus on time to market. As a result, the GI management

transitioned the Centri TNT product line to Argus Networks to allow the BRSI team to

focus on the Windows NT firewall industry.

However, the transition was not without conflict. As a result, one of the co-

founders of BRSI resigned, being uncomfortable with the role she was offered after the

transition and in general disagreement with the direction the team was pursuing.

To expedite entry into the Windows NT firewall market, a second development

team was formed in San Mateo. Combined with the BRSI team and managed as a wholly

owned subsidiary, the new composite group became known as Global Internet Software

Group (GISG), and the leadership of the two teams became split between Scott Wiegel,

who led the BRSI team, and Mark Kriss, who led the San Mateo team.

The San Mateo team was charted to port the Trusted Information System (TIS)

Firewall toolkit to Windows NT. Incremental innovations were added to this firewall, as

well as a bundling with a strategic partner MetaInfo’s Sendmail and DNS server

software. This version of Centri Firewall was also introduced into the Japanese market in

October 1996, and the initial release was dubbed 3.1 to avoid the negative perceptions of

an initial software release. The product was released to fair reviews, but it lagged the TIS

Gauntlet Firewall product, which ran on UNIX and was the leading firewall product in

the enterprise market.

50

In the spring of 1996 and under pressure to release a new product as TIS began

developing their own Windows NT firewall product, the BRSI team was directed to

develop a “from scratch” replacement for the Centri Firewall product, which was based

on the TIS Firewall Toolkit. This effort was referred to the Centri Security Manager

firewall project. As a result, the BRSI team worked in isolation to avoid conflicts of

interest and to ensure that TIS would have no legal grounds to block the shipping of their

firewall based on exposure to their toolkit code base.

The initial release of Centri Security Manager, Bronze Edition occurred in March

1997. Also during March 1997, a reseller partnership was announced with V-ONE,

whose chief scientist was the lead developer of the DEC SEAL firewall and the TIS

Firewall toolkit, Marcus Ranum. Again, this partnership was established to augment the

network security reputation of GISG.

With pressure mounting to generate revenue and the perception of a closing

window of opportunity to explore the planned exit strategy of selling the company to a

larger player in the space (originally, directed at Microsoft, who was now disenchanted

with the marketing tactics), the GI team accelerated the press and analyst tours.

Separately, in an effort to showcase the innovations in hopes of being acquired, the BRSI

team documented the technologies underlying Centri Security Manager rather than

develop user documentation. These efforts culminated in Cisco Systems, Inc.’s

acquisition of the GISG team (20 members) and the Centri Security Manager product for

$40.2 million dollars in June 1997.

The following sections identify the key innovations developed by the core team

and analyze the effects on the team of the transition from GISG into Cisco Systems.

51

Key Innovations

The Centri Security Manager firewall project led to the development of two

disruptive technologies, both of which were patented by Cisco Systems: the kernel proxy

architecture (US Pat. 6131163) and the graphical policy-based user interface design (US

Pat. 6484261). However, within Centri Security Manager, numerous innovations existed

and many played key roles in later Cisco products (see

http://www.cisco.com/univercd/cc/td/doc/product/iaabu/centri4/user/scf4ch5.htm) also

developed by the BRSI team. Other innovations included the following:

• ExPLORE scripts engine. A Java-based kernel-level proxy scripting

language that precompiled into a kernel-level JIT file enabling custom

implementations of new proxies to close the protocol gap in between

product releases.

• Reporting and Monitoring subsystems. These technologies were key to

later products, and the initial frameworks were developed at Global

Internet but all based on the AMS concepts that Scott had designed and

documented at BRSI.

• Core technologies. Refined frame-based, event-driven Knowledge

Representation System (KRS) database, communication channels

(including the Controlled Host Communications channel and the Local

Communications Bus), and the agent-based architecture.

• Integration with Windows NT Domain Controller Users and Groups.

While really just supporting a documented API call provided by

Microsoft, the use of these objects for network policy was new, allowing

host, group, and user-based firewall policies without having to administer

a separate user and network node database.

52

• Secure VPN channels. Allowed for secure transport of traffic between two

Centri Firewalls. This technology was innovative because it pre-dated the

general acceptance of IPSec and secure sockets layer (SSL) tunnels.

• Tiered administration models. Enabled the design of the layered,

distributed firewall management models. While targeted at customers who

simply were never going to use a Windows NT bastion host as their

firewall node, it was leveraged in Cisco Centri Firewall 5.0.

• Security Verification Engine (SVEN). The security engine at the heart of

the Centri Security Manager. While this technology did not move forward

at Cisco after the product reached end of sale, it remains a key innovation

developed by the BRSI team.

By April 1996, the conceptual framework was completed and early discussions

were held for a suite of security products including:

• Centri Firewall

• Centri Modular Encryption Engine

• Centri TNT Network Stack for Microsoft Windows NT

• Centri KidSafe Firewall

• Centri Audit Management System (AMS)

• Centri Encrypted File System (EFS)

• Centri Internet File System

• Centri Encryption Toolkit

• Centri Common Administrative Tool (CAT)

In retrospect, this roadmap of technologies would have required very careful

management as their support and maintenance overhead could have been much higher

than envisioned. Many of these products would have been product drop offs based on the

53

Centri TNT and Centri Firewall (Centri Security Manager) roadmaps as well as

repositioning some of the products toward different markets (e.g., KidSafe Firewall).

Conceptually, the AMS product, which was important to Scott, was one that never

gained traction outside of the core team. Later, this market would be addressed by

Security Information and Event Management (SIEM) systems, a market that earned

revenues of $678.1 million in 2009 and is projected to reach $1.3 billion by 2015

(Wilson, 2011).

The following section highlights some key details about the transition from

Global Internet to Cisco and the effects of this transition on the core team.


Global Internet Software Group (GISG) was purchased by Cisco in July 1997.

The group became part of an incubation style group, the Internet Appliances and

Applications Business Unit (IAABU), under the leadership of Vice President and General

Manager Christine Hemrick within Cisco’s Small/Medium Business line of business.

This group shared a testing director and a marketing director, and it was focused

on small and medium businesses, but it also had its eye on the ever lucrative enterprise

market. This lack of refined market focus may have been the cause for this group’s

eventual demise. However, the author was not privy to the discussions leading up to that

decision.

Where the Global Internet transition was smooth, the Cisco transition was not.

Beginning with the press release, which included the statement “The approximately 20

employees of the Global Internet Software development team will continue to work out of

two locations, the SF Bay area and a remote office in Champaign, Illinois,” it was clear

54

that the BRSI team would be moved to a neighboring city. The San Mateo team was

moved to the San Jose headquarters within a few weeks of the closing date.

Scott Wiegel, the leader of the BRSI team, was relocated to San Jose, California.

The BRSI team floated along in limbo with spotty updates and vague guidance from

Scott while they awaited the completion of their new building in Champaign, Illinois. It

was deemed that airport access and easy accommodations was critical for the number of

prospective incoming Cisco executives and staff. Months after the closing and only after

the new facilities were complete, the acquisition integration team descended on the BRSI

team to drive new processes and tools adoption and explain the Cisco culture, benefits,

policies and procedures, the grade and job descriptions, performance review processes,

etc. After several days of meetings, the acquisition integration team boarded the planes

and departed.

Team members were also repurposed into different roles (e.g., the network

administrator became site building construction supervisor) and were often removed from

the roles they preferred into ones that were selected for them by the closing negotiators,

with little or no input from the individuals themselves.

The Cisco sales and partner channels were even more inappropriate for the newly

christened Cisco Centri Firewall for Windows NT than Global Internet.Com’s channels

had been, almost solely targeted at the exploding enterprise market of the pre-Internet

Bubble heyday.

The following section analyzes the team’s transition from Global Internet to Cisco

Systems relative to the frameworks recommended in the literature review.

55


In 1996, Global Internet selected large distributors as their primary sales channel

model. These distributors, led by Ingram Micro, represented an incorrect model relative

to the market maturation as well as the maturation of the product. Instead, the BRSI team

needed dedicated, experienced sales staff accustomed to working in the accounts of early

adopters. This level of hands on with the customer was needed to drive the learning about

the customer problems and the acceptance of proposed solutions. The original intent had

been that the Cohesive Systems group would provide this level of service; however, they

could not position these products in their customer accounts because their customers did

not want to run Windows NT firewalls. In other words, their customers were not the

target market for the software group, and a pivot was needed to align the market with the

one to which Cohesive provided access, to grow a dedicated sales team to focus on

identifying early adopters for Centri Firewall, or to push the Cohesive team to expand

their market to identify the correct segment. However, the natural conflict between

running a successful consultancy group with a loyal customer base versus developing and

selling a product was a predictable outcome once the market mismatch was identified.

For the BRSI team, it was a case of extreme entrepreneur rationalization—“Once they see

how easy it is to use, they won’t want a UNIX- or Linux-based solution. They will

happily move their company to Windows NT.”

In addition to needing a small, very focused sales team, the BRSI team also

needed to send the engineering team into customer accounts to begin to understand their

pain. This in-the-field approach would also have quickly identified the market mismatch

with the Cohesive team. While the BRSI team rapidly innovated, they did not have a

good Lean Startup model in place, which would have helped them pivot into the right

product/market fit.

56

There was an unfortunate desire for secrecy when it came to the product

development; the team should have been showing Centri Security Manager to customers

for early feedback immediately to identify what became insurmountable usability issues

(abstract concepts called Sites). And last, the natural conflict between tentative customers

who were buying the Gauntlet ported firewall rather than the custom developed product

led to a conflict in interests between acquiring customers in the short term versus

showing them the future and having them hold off on their purchase. With the desire to

avoid any potential legal issues with TIS, it made pre-selling an upgrade path between the

toolkit-based firewall and the home-grown one too risky of an option. This execution

strategy provided the team time to complete the development of the product, but it

restricted their access to potential early adopters as they were being peddled the short-

term product. Little regard was given to the customers who would be left holding the

older technology with no migration strategy to move to the new one and no concern for

the “staff development” expenses that was invested in the Gauntlet port. No plans for a

policy migration tool were ever discussed.

Likewise, the focus on building the security credibility of the BRSI team took its

toll on the completion of the FutureSource contract and delayed the development of new

products. No actual value was achieved from these credential-building exercises.

The executive staffing, while originally well timed, slipped out of alignment with

the market adoption and segment identification when the GI executive team brought on

Phil Marson, a seasoned veteran. Phil’s experience was in ramping sales for products that

were in the growth phase of the market maturity models. He came to GISG from Bay

Networks, where he led enterprise sales. As a result, the marketing and sales engine

revved up to sell a product that had yet to find a solid target market.

57

As part of this rev up, the V-ONE reseller partnership was structure, which was

also a mismatch. While a strategic partnership to bring each other into key accounts when

opportunities arose would have benefited both teams, a high-volume sales channel was a

mismatch for Centri Security Manager given the infancy of its development and the

market. As Blank explains, this mismatch results from bringing in a seasoned VP of Sales

from a large enterprise focused company who, following previous successes, immediately

mobilizes a sales force and channel partners to target high growth before the product is

even shipping. While this move would have been critical to driving growth once the

chasm had been crossed, it was premature at the time, and the pressure was driven around

the expense to income pressure, presumably driven by the venture capital firms invested

in Global Internet.Com. The focus should have been on engaging early adopters and

refining the product-to-market fit.

This split team development resulted in the GI executive leadership spending less

time with the BRSI team and created the opportunity for divisiveness, as new ideas were

shared in isolation. An attempt to consolidate the two teams under a technical marketing

leader failed, as it attempted to replace Scott as the head of engineering and was rejected

by the remaining members of the BRSI core team. However, the GI executives

recognized the value of the team’s opinion and re-instated Scott as the head of

engineering and visionary for the software group.

The GI team provided exposure to analysts, customers, and strategic partners.

They added new support staff (network administrator, marketing and sales staff, and

testing engineers) and provided the time to develop the products, even though it created a

conflict in resources from a sales perspective and divisiveness between the development

team and sites.

58

While the transition of the group and technologies into Global Internet was

smooth, the transition into Cisco had some difficulties. Cisco immediately launched and

targeted the Cisco Centri Firewall as product at enterprise customers (500 nodes and

fewer) that had, for all intents and purposes, shipped its initial release (Centri Security

Manager, Bronze Edition) only three months prior to the acquisition. Cisco did perform

some basic testing to determine the 500-node restriction, but there was no long-term burn

in of sustained traffic in a 500-node test bed, simulated or otherwise.

Table 2: reviews the recommended models relative to some of the activities

performed at Global Internet. As the company was really a startup, Moore’s portfolio

management models do not apply.

Table 2: Global Internet Software Group Summary Analysis

Table 2, cont.



Customer discovery While a new product was identified (Windows NT

firewall), the product-to-market fit was never fully

understood. As a result, the specific market was never

identified (bounced between small business and

enterprise). In the end, the team focused on the

broader enterprise market instead of a narrow market

segment to complete the customer validation stage.

Customer validation Customer validation stalled. However, the marketing

ramp up and spend associated with the customer

creation phase did occur.

59

Table 2, cont.


Customer creation Sales were limited to several hundred TIS-based

firewalls, and Centri Security Manager was only on

the market for three months before the Cisco

acquisition. By the time the product launched, a full

cadre of go to market materials and activities was

available, including press tours, sales kits, channel

partners, etc. The spending was rapid and large;

however, the market was still not ready for Windows

NT-based firewalls in the enterprise. These actions

were symptoms of premature scaling, which increased

VC pressure. However, the Cisco buyout masked the

real issues that were bound to occur due to the scaling

without completing customer validation phase.

Company building This activity was prematurely launched before the

completion of stage 2 and 3 (customer validation and

creation). There were vice presidents of sales and

marketing prior to the initial release of the Centri

Security Manager product.


Validated learning The secrecy of the team prevented any validated

learning.

Falsifiable hypothesis None.

60

Table 2, cont.



Loop

None. The feedback that was provided by the

consulting division was largely ignored, which was

“Windows NT is not the platform for Enterprises.”

Minimum viable product This model was not followed at all; in fact, the

opposite was followed, which was the most

competitively complete product possible.

MVP testing could have helped prioritize development

efforts greatly; for example, the kernel proxy scripting

language and interpreter might have greatly added

value but had no attraction due to the difficulty in

scripting your own protocol handler. However, it

might have revealed itself as something a value-added

reseller might have highly desired, which would have

driven growth, which would have change the sales

channel strategy.

Kaban The Kaban model was not followed.

Innovation accounting Funnel metrics were not collected, as far as is known.

Pivot or persevere Global Internet did pivot from the trusted systems

market to the more general market of Windows NT

firewalls. A market that was beginning to take off in

small and medium business segments because of the

overall ease of use and hardware costs and options of

61

Table 2, cont.


Windows NT relative to UNIX systems. They rightly

jettisoned the TNT product; however, they retained the

right to use the “Microsoft TCP/IP license” within the

TIS Firewall toolkit port (Centri Firewall). They

pivoted away from the Microsoft license technology to

a proprietary proxy stack developed using the Win32

Network Driver Interface Specification (NDIS)

miniport drivers.

In addition, the on-paper model for Global Internet

was own the consultants who will sell a service

provider contract and the security and services you

need to connect your business to the Internet.

However, executive management had to make several

pivots trying to find a profitable business model. The

issue that resulted was the VCs backing the company

wanted to start to see a return based on the model they

were originally pitched. Sinking money into a

software startup was not something they had agreed to,

which created conflict among the groups and with the

board.

Batch As mentioned earlier, small batch methods were not

followed. The team struggled with the large batch

62

Table 2, cont.


death spiral, both on the TIS port and the Centri

Security Manager solutions.

Pull rather than push Like Blue Ridge, GISG pushed more of the features at

customers than pulling feature requests. The issue was

more to do with the idea that small business customers

did not know what they wanted, and Enterprises

wanted features relative to the mature UNIX-based

firewall market.

Three Engines of Growth The failure to identify the correct engine of growth so

as to capture and analyze the metrics to identify

weaknesses in the business model was a failing. The

VC firms backing the company exerted too much

pressure on results, and the team did not stop to

properly tweak and validate the engine of growth.

Five Whys GISG did not use of the Five Whys or an equivalent

root cause analysis model.


Category Power

Category Maturity Life Cycle Understanding the market and category maturity could

have identified the slower adoption and need for more

support to install and manage security solutions in

small businesses. It would also have identified the

63

Table 2, cont.


mismatch in the whole offer solution and the

Enterprise customers (who were the target of the

selected channel partners).

Growth/Materiality Matrix At Global Internet, there were no alternative products.

The only growth originated from the consultant

groups, which were used to fund the software

development.

Three Horizons Model GISG was a Horizon 3 company with no Horizon 1 or

2 products to compete with.

Competitive Separation Global Internet leveraged the Microsoft source code as

a competitive differentiator; and it was, but it was not

one that the customer’s cared about. At issue was the

fact the Microsoft stack was not the best one available.

The TGV MultiNet Stack, for example, was

considered by many to be a better network stack for

the Windows platform.

Two Business Architectures High volume, medium/low margin.

Crown Jewels GISG had two crown jewels: vast network security

experience, which it leveraged in building the Centri

Security Manager, and detailed experience with the

Windows NT operating system.

64

Table 2, cont.


Market Power

Nine-Point Market Strategy Global Internet attempted to address many of the nine

points. Much of the marketing analysis and strategies

were sound, from the need (secure attachment of small

businesses), to the whole offer (bundling the DNS and

sendmail servers, which were the primary tools

required to connect small businesses to the Internet),

to an easy-to-use firewall on an easy to install and

manage platform (Windows NT); the channel partners

were not compatible with the early market adopters

that were targeted. The team took their eye off of their

original market, which was small business, and began

to target the more lucrative Enterprise market, which

had different requirements, one of which was UNIX-

based devices. This change in market was likely the

result of pressure from the VC-backed board, which

expected more rapid return of their investments than

the original market was going to allow.

Offer Power

Return on Innovation Global Internet worked hard to define neutralization

innovations (Firewall Toolkit port to Windows NT

using the Microsoft TCP/IP stack) and define

65

Table 2, cont.


completely new innovations that differentiated their

products (Centri Security Manager). The executive

management and the team both kept this focus

throughout.

Six Levers Global Internet attempted to repurpose staff, as both

on the ground consultants and software sales

personnel. Otherwise, they generally added new staff

as the company was too small to free up existing staff

from other efforts. However, the BRSI team

experienced two non-core efforts: the security

credentials building effort (MISSI) and the Toolkit-

based porting effort. These efforts failed to move the

team forward, created a competition between two

development teams (when the staff for one existed),

distracted them from developing the proprietary

technologies that were eventually acquired by Cisco,

divided the leadership, and split the sales teams focus

on understanding the pain points of the customers as

they were focused on selling the Toolkit-based

product.

Price/Benefit Sensitivity Pricing around the firewalls was difficult, as the

reference pricing of competitive offers eroded the

66

Table 2, cont.


margins artificially. The initial target segment did not

understand the need and they typically outsourced

their efforts to the service provider. Given that Global

Internet owned MIDnet (an original regional networks

on the NSFNET), this model should have been easily

identified. However, the focus was on the consultancy

group that installed and managed firewalls in

enterprise companies that were establishing websites

to remain competitive in the early stages of the

Internet boom.

Core/Context Global Internet really found that they were a

consulting team. They sold off both GISG and the

MIDnet teams to focus on their core.

Execution Power

Arc of Execution While GISG initiated the deployment phase, the team

truly never left the invention phase. The products

needed to iterate to find a better product-to-market fit

before scaling up on the big spend of the deployment

phase. In addition, the team assembled was more

appropriate for the optimization phase (e.g.,

consultants from Cohesive Systems and Forte

Computer Systems were repurposed as sales staff, who

67

Table 2, cont.


had no real vested interest in the success of the

products). At the first tipping point (from invent to

deploy), Global Internet attempted to scale to reach the

first tipping point just before the Cisco acquisition.

The execution missteps really revolved around the

conflicts that resulted in the split development teams.

The foray into the deployment phase was largely

driven by to return investment to the VCs, resulting in

premature scaling of the company and greatly

increased spending (the new team came on staff a

solid 6-8 months prior to the product being released).

Four Modes of Execution Scott’s leadership was key to the innovation phase,

and executive management tried to replace him with a

non-inventor mindset manager, the remainder of the

core team quickly rejected the change. Executive

management thoughtfully considered the change and

reversed it, leaving the visionary leadership in charge

of the team with looser oversight than the initial phase.

The result was the Centri Security Manager was

positioned to challenge all competitors in the rapidly

developing Windows NT firewall market with a highly

differentiated user interface, architecture, and

68

Table 2, cont.


reporting system.

While the team’s initial direction was determined by their work at GISG, they did

not remain focused on network security. Instead, they pivoted to network management

solutions while at Cisco. The following section describes the team’s product focus and

innovative efforts at Cisco Systems, and it details the internal organizational changes that

led to the disbanding of the team.

CISCO SYSTEMS, INC.

In June 1997, Cisco Systems, Inc. acquired Global Internet Software Group and

its 20 employees for $40.2 million. The initial strategy was to complement Cisco's

enterprise-class PIX Firewall by using Centri Security Manager to address small and

medium businesses. The longer-term vision included enhancing Centri Security Manager

to manage the PIX Firewall policies and devices, which were notoriously difficult to

create and maintain.

Working along side up and coming teams, including the PIX Firewall,

LocalDirector, MicroWebserver, and CacheEngine teams, the GISG team became

indoctrinated in Cisco process. As the press release heralded, the core team (referred to as

the BRSI team) was relocated to Champaign, Illinois as soon as the new office building

construction was complete, which occurred four months after the acquisition. Once the

building and proper network infrastructure were complete and the team moved, a Cisco

transition team descended on the team to assimilate and indoctrinate them into the Cisco

culture, including discussions about the source control management systems they would

use, benefits packages, phone system operation, and other job possibilities elsewhere in

69

Cisco. The Champaign office also became a home base for the mobile sales team

members in the area. The San Mateo team moved to the Cisco headquarters in San Jose

alongside the other IAABU teams.

As part of the acquisition, the long-time test team manager and lead and one of

the two test engineers did not transition to Cisco. This change left the team short handed

on testing resources, as they represented two-thirds of the test team, It also changed the

relationship onsite at Cisco as IAABU had a centralized test manager in a pivotal role for

the GISG team; a role that required detailed product knowledge and was highly reliant on

team intelligence. Later, Scott did hire these two team members into Cisco.

Cisco’s internal mantra of “change is constant” held true for the seven years that

the BRSI team remained largely intact. The first key change being that management,

specifically Scott Wiegel, who was the founder and key visionary of the team, was

required to move to San Jose. This move affected the team’s ability to execute. As a

result, a development manager was hired onto the Champaign team who had neither

vision and nor the ability to unite and drive the team to completion. The Champaign team

began to hire additional staff at the height of the Dot.Com market when finding a good

team fit was very difficult. The San Jose team also began to hire, as Scott wanted to drive

some changes and found the over 2,000-mile distance between himself and the BRSI

team too great to effectively manage. As it had a Global Internet, this split-team

arrangement created conflict between the two teams, who were both working on the

Cisco Centri Firewall for Windows NT (formerly referred to as the Centri Security

Manager by GISG).

The second key change was a change in direction less than two years following

the acquisition. IAABU was disbanded and the product teams were placed in different

business units within the company. The Centri team landed in the VPN and Security

70

(VSec) group. This reorganization separated the Centri team from Christine Hemrick, the

executive sponsor who had been key to the acquisition.

As the result of a post-reorganization shuffle, the Centri development team was

given to the manager of the PIX Firewall team, who stated he had no desire to manage a

remote team. Within months of the reorganization, the end-of-sale (EoS) decision for

Centri Firewall was made (August 13, 1998), ending the disruptive innovations unique to

Centri. This EoS decision came just as a 1.5-year development push on Centri Firewall

5.0 was to culminate in shipping product within a month. Centri Firewall 5.0 heralded

better integration with Cisco platforms and technologies, as well as integrated many

advanced features including PIX firewall management, distributed firewall deployments,

IPSec-based tunnels, TACACS+ and RADIUS authentication, six new proxies, advanced

reports, dynamic security polices, and an advanced content filtering engine with a

northbound application programming interface (API). Existing Centri customers were

sent a low-end PIX Firewall as a replacement at no cost.

Meanwhile in June 1998, Scott, Susan, Rick, and Blaine had transitioned into the

Chief Technology Officer’s (CTO) office under Judy Estrin, where they were to leverage

portions of the Centri frameworks to develop a centralized security policy management

application for Cisco. This reinvention of the core team created a new group called the

Internet Security Management Group (ISMG), which declared its charter as developing

an abstracted policy-based security management application for Cisco’s key security

product lines, including PIX firewall and IOS firewall feature set. The product was

initially released as Cisco Security Manager, but was renamed to Cisco Secure Policy

Manager (CSPM) after three releases. When the Centri end-of-sale announcement was

made, the Centri team transitioned to back under Scott to support the development of

CSPM.

71

The PIX firewall and the intrusion detection teams were moved under the CTO’s

office following the initial release of Cisco Security Manager in June 1999. Under the

leadership of an unseasoned director, this reorganization set the stage for a vision

leadership struggle among the engineering directors of the three product teams. Despite

the political tug-a-war, the ISMG team developed many innovations, including policy

and rule analysis tools, routing and address translation rule derivations, aggregate

reporting and normalization across platforms, firewall rule pruning on the PIX firewall,

PIX-to-IOS VPN tunnels, visualization of VPN policies, a rule table visualization of

firewall rules, and integrated intrusion detection system (IDS) device and policy

management within CSPM. The team now had three development locations, San Jose,

Champaign, and Austin, and the groups numbers swelled to over 80 developers and test

engineers.

In April 2000, Judy Estrin left Cisco and the ISMG team was handed to the

Enterprise Management Business Unit (EMBU). It is in EMBU where the remaining

disruptive technologies were abandoned in favor of incremental innovations of the long-

established single device management products. As CSPM sales began to ramp, it was

bundled with several lagging EMBU products in the CiscoWorks VPN/Security

Management Solution (VMS). This new bundle made it impossible to assess

unambiguously which products were driving the bundle sales.

And while the team fit was initially decent, eventual struggles between the head

of EMBU and Scott regarding the direction of the CSPM product led to Scott’s departure

from Cisco in the fall of 2002. Rick Wells had retired almost a year earlier in August

2001.

However, before Scott left, he guided the team through another product transition,

but did not remain for the initial release of the products. Along with parts of the former

72

ISMG development sites in San Jose and Austin, the Champaign team was directed to

design and develop the replacement product for CSPM. The Champaign team focused on

the Management Center for PIX (PIX MC) and Common Services foundation platform.

The team started working with teams in Chennai, India and Netanya, Israel to develop a

series of four separate products to replace CSPM. The ISMG Austin team was reassigned

to work on Management Center for IPS (intrusion prevention system). Within a year, the

remainder of the ISMG San Jose team, who was still working on CSPM, was informed

that development would not continue, and the CSPM end-of-sale announcement was

made on December 31, 2002.

Without direct team representation at the Cisco headquarters, the Champaign

team, which had numbered over 40 when Scott departed, began to loose steam. The team

in San Jose took over CSPM under new leadership took over because the team’s

development manager, Imin Lee, left in mid 2002 as a result of the decision to terminate

CSPM development completely. Imin and the San Jose lead architect, Partha

Bhattacharya, had petitioned the head of EMBU to transition the San Jose team and some

of the Centri/CSPM technologies into a monitoring and analysis solution (a la AMS), but

that request was denied. Imin and Partha departed Cisco to found Protego Networks in

early 2002. On December 20, 2004, Cisco agreed to buy Protego Networks for $65

million, signaling the return of Imin and Partha to Cisco with their highly successful,

industry leading monitoring and analysis tool.

In May 2004, the head of EMBU left Cisco, and the EMBU group transitioned

from the Security Technology Unit into the Network Management Technology Group

(NMTG) led by Cliff Meltzer. In June 2004, Cliff visited the Champaign to announce the

site closure as a cost savings measure. With this announcement, the core team disbanded

rather than being relocated to Austin, Texas.

73

In 2007, the end of sale of the CiscoWorks VMS bundle, complete with the

second and third generations of the firewall, IDS, and router management centers, was

announced, but not before a completely new and unified Cisco Security Manager product

had been in development for over a year to take the place of the suite of separate device

managers.

The following sections identify the key innovations developed by the core team

and analyze the effects on the team of various transitions that occurred within Cisco.

Key Innovations

The 11 patents filed over a period of five years are representative of the list of

innovations developed by the BRSI team and the team members they hired into Cisco.

The flurry of patent activity in 2001 and 2002 was the result of Cisco’s internal emphasis

on patents combined with the team’s attempt to demonstrate the CSPM’s value using a

metric other than ramping sales (now hidden in the VMS bundle). As the BRSI team was

not local to the legal department, they rarely filed patents; however, many innovations

developed by the team during that period would have been patentable.

74

Table 3: Patents Filled by Centri and CSPM Team Issued to Cisco Systems

Patent No. Title Filing Date 6131163 Network gateway mechanism having a protocol stack

proxy Feb 17, 1998

6484261 Graphical network security policy management Dec 11, 1998

7096356 Method and apparatus for negotiating Diffie-Hellman keys among multiple parties using a distributed recursion approach

Jun 27, 2001

7082531 Method and apparatus for determining enforcement security devices in a network topology

Nov 30, 2001

7636937 Method and apparatus for comparing access control lists for configuring a security policy on a network

Jan 11, 2002

7107613 Method and apparatus for reducing the number of tunnels used to implement a security policy on a network

Mar 27, 2002

7516475 Method and apparatus for managing security policies on a network

Jul 1, 2002

7007032 Method and apparatus for removing redundancies from a list of data structures

Jul 1, 2002

7036119 Method and apparatus for creating a network topograph that includes all select objects that are in a network

Jul 15, 2002

7143283 Simplifying the selection of network paths for implementing and managing security policies on a network

Jul 31, 2002

7093283 Method and apparatus for deploying configuration instructions to security devices in order to implement a security policy on a network

Feb 15, 2002

During the seven years that it remained intact at Cisco, the BRSI team was

instrumental in developing three major product lines and released over 20 versions of

those products, as well as spent over 1.5 years on Centri Firewall 5.0 and a Centri

Firewall appliance that were never released. Centri Firewall 5.0 represented a major step

forward in innovation in firewall designs and technologies.

However, many key innovations were those that were neither released nor funded

for development. While the BRSI team was not busy filling patents, they were building

off of earlier ideas and laying the conceptual foundations for a next-generation, disruptive

75

network security management infrastructure and unified policy system. Work on this next

generation user interface, known internally as the Binkie Abstraction Model (BAM)

policy construction model, to address usability issues was dropped in the shuffle from

ISMG into EMBU despite having detailed specifications and paper prototypes and

mockups. EMBU’s focus on transitioning to a Java-based thin client user interfaces

overrode any evaluation of this design. This technology, coupled with the detailed system

descriptions for Tropic database enhancements and the Cisco Unified Policy Server

(CUPS), which unified network service, security, QoS, user authorization, and event

monitoring policies in a distributed policy management and event management

monitoring system, provided the foundation to address many issues that still plague

device management today. Again, the CUPS proposal was dismissed, as the incubation

and development period was considered too long and expensive for a business unit that

needed to show minimal losses to remain funded. These technologies would have been

highly disruptive had they been in place when new platforms and technologies, such as

the Nexus switches and virtualization, were introduced across Cisco products. As they

were planned in the late 1998 and 1999 timeframes, their timing would have been ideal

relative to the similar product technology maturation, which appeared to be between 4

and 7 years for the BRSI team.

The following section highlights some key details about the internal transitions

that the core team experienced within Cisco and the effects of these transitions on the

core team.


During the seven-year period under review at Cisco, the BRSI core team

underwent eight major organizational or leadership transitions.

76

Figure 9: Major Transitions and Events During the Seven Years at Cisco

With the exception of Imin’s departure, each organizational transition changed the

leadership and direction of the BRSI core team significantly. The three most difficult

transitions were Scott’s move to San Jose, which fundamentally changed the ability of the

core team to execute quickly; the transition from IAABU to VSEC, which resulted in the

end of sale of Centri Firewall; and Scott’s leaving Cisco. However, Scott became

disenchanted shortly after the transition from ISMG to EMBU, which foreshadowed his

departure.

The organizational transitions were frequently associated with a loss of mentors

and critical support roles for a development team, such as marketing leadership and

executive sponsorship.

77

In addition to the organizational transitions, the team experienced five product

transitions, which changed the focus of the product in major ways:

1. Transition into Cisco added the goal to manage the PIX Firewall along

side Centri Firewall. In every way possible, the policies and perspective of

the network were different. This goal forced the team to cobble a legacy,

device-centric view of firewall policy onto the bleeding edge, abstract

network-level policy inherent in Centri.

2. Transition away from Centri Firewall to Cisco Security Manager. The

consistent, coherent design of Centri differed greatly from the inconsistent

features and archaic audit systems of the legacy Cisco products. As with

the integration of the PIX firewall, this change represented a step

backward at the expense of moving the policy management toward the

vision of the BRSI team.

3. The addition of IDS management to a firewall/virtual private network

management tool. The idea of a policy-based IDS interface was flawed.

The implementation was addressed by BAM and CUPS, but was targeted

at the forthcoming inline IPS technologies, not the legacy passive IDS

sensors.

4. Transition to a non-graphical policy model (CSPM 3.x). This step was a

last attempt to preserve the innovations of CSPM and to compromise with

the marketing team of EMBU around legacy implementations. However,

the team was split completely at this point, so many of the underlying

technologies, such as the routing derivations, were crippled.

5. Transition away from CSPM to Firewall MC, IDS/IPS MC, Router MC,

and Common Services. This transition was the most difficult, as it

78

abandoned all disruptive innovations and refocused the team on decade

old legacy designs and device management perspectives. This transition

ended any innovation enthusiasm by the BRSI core team.

The market transitions were not overtly obvious. The teams original target market

was the small and medium businesses that were trying to get connected during the

Internet boom. Later shifts were really set by the experiences of the marketing leadership

on the team. For example, with CSPM, the team would temporarily look for traction in

financial services, health care providers, insurance providers, university and colleges, and

then Fortune 500 enterprises. With each technology transition, market transitions

followed—a pattern that accelerated with the team’s merry-go-round of product

managers.

Other than broad definitions such as “enterprise” or “healthcare,” no clear market

segment analysis was provided nor was a breakdown of the problems to address by

market segment. Most analysis was provided by meta data providers, such as Gartner,

where the focus was on “magic quadrant.” These reports were vanity reports that rarely

correlated to competitive strength, product traction, product maturity, or technological

innovation. However, these providers of meta reports could shift the direction of the

development team within weeks of a new report being released, depending on the

strength and resolve of the marketing leadership in place at the time.

The following section analyzes the internal transition that the core team

experienced within Cisco Systems. It frames these transitions relative to the frameworks

recommended in the literature review.

79


The BRSI team, as well as the team that Scott hired in San Jose, were particularly

innovative. However, the major influencer of innovation was Scott, who was the key

visionary of the BRSI core team. His insights were, in hindsight, nearly perfectly timed to

ensure that the products would have been stable, feature appropriate, and had a good

product-to-market fit by the time broader market adoption occurred. The BRSI team

repeatedly delivered technologies that were disruptive and differentiated.

It was bringing these technologies to market where the team really struggled.

Initially, with the Trusted Network Technology DNSIX product, the market segment was

quite small. Customer identification and acquisition was expensive. The team had two or

three beachhead customers when Global Internet acquired BRSI. This approach was the

right one, and Scott’s engineering leadership focused on small incremental updates

naturally. If anything was out of synch with the literature here, it was Scott’s inability to

really define a minimum viable product—his vision for products were very feature rich,

but they also required a certain level of complexity to work and to achieve the specified

compliance ratings.

When Global Internet purchased BRSI, the team was redirected to a new

technology area. The vision developed was rich and highly innovative throughout the

system. Failures to define a MVP and identify key beachhead customers in a specific

market were two shortcomings during this period. In addition, the management pressure

from Global Internet to produce a mature and competitively comparable initial product

ended the incremental development direction that Scott had set at BRSI.

The original placement in IAABU was a good fit. The team needed incubation

time, and undoubtedly, this soft landing in terms of strong executive sponsorship

accounted for the ability of the team to survive the first transition. However, it was the

80

perception sold by Global Internet of purchasing a mature product that hindered the

immediate execution at Cisco. With the exception of the repurposed components from the

FutureSource contract, all of the key technologies in Centri Firewall were just over a year

old from inception to code. The system and its underlying technologies needed

incubation time and targeted testing for scale and stability. Instead, the demands of

customers and marketing teams were piled into detailed product requirement documents,

and the team hit the ground running. There was an initial attempt to test and stabilize the

product using a Cisco testing organization; however, they were unfamiliar with the

technologies, the system, and Microsoft Windows NT.

From the outside looking in, it is easy to see the timelines simply do not support

proper incubation from inception to first release to end of sale for each of the products

developed by the BRSI team. Success was measured not by the ability to gain customer

acceptance within a specific market segment, but by product stability and the ability to

limit the cost of customer acquisition. In other words, the ability of product sales to do

more than sustain the team through these early development stages was unnecessary. This

issue was brought into high contrast in EMBU, where relative portfolio contribution

comparisons between immature and long mature products were made regularly. Problems

with stability plagued the BRSI team, especially when the IDS systems began to use the

KRS database to store audit events generated by multiple sensor nodes. Audit streams

provided by other products, such as PIX Firewall, also presented problems as the events

were large syslog dumps and initially had little data of value unless the appliance

operated in debug mode, forcing the team to deal with many unnecessary events to

extract reports of any value to customers. Intelligent design of the events from the node to

storage was simply never performed, and pushing those changes back to the source rather

than the point of aggregation was clearly the better design. However, the PIX Firewall,

81

IOS, and IDS/IPS development teams were unwilling to reassess these decisions, and the

fact that their product roadmaps were wholly set by customers rather than share by

customers and internal product teams, such as ISMG, prevented the resolution of trivial

problems that would have profoundly changed the market.

Placing Centri under the management of the competing firewall technology group

at the same time that the PIX team was ramping its sales created a catastrophic conflict in

interests, going against the recommendations all literature on the management of

innovations. In addition to viewing Centri as a competing technology to their older

generation firewall architecture, the PIX team viewed Centri as a user interface

competing with the Java-based PIX Firewall Manager, a product the PIX team showcased

heavily within Cisco to demonstrate improved ease of management of the PIX Firewall.

With Centri 5.0 able to manage PIX Firewalls within the same user interface as its own, a

clear and demonstrable migration strategy from PIX to Centri was guaranteed, and the

feature richness of Centri’s security technologies and distributed architectures laid a

formidable justification for upgrading to the newer technology.

The organizational placement of EMBU, as a child of a security BU without no

direct revenue stream, created many difficulties. While demands for profitability were

high and the threat to shut down the Champaign office was used to routinely drive

deadlines, the inability to make key technology investments, such as new database

technologies or user interface control libraries, hindered the team’s ability to reach

stability and maturity more quickly. License fees or acquisitions of technology were

unfavorable, especially in EMBU where the requests were made (with the Internet

bubble, many technology companies valuations plummeted, and key technologies would

have represented a low-cost, high-value investment). In addition, efforts to develop the

technologies internally, such as Tropic, a follow on replacement to the KRS database

82

layer, were also defunded and out right failed. The ability to address the technology

shortcomings of innovative technologies was simply not allowed.

However, the departure of Scott drained the team of motivation. The team began

to take on more outside interests and simply “come in” to work. Following his departure,

the threats to close the Champaign office remained constant until the transition to NMTG,

when the threat was finally fulfilled. This environment proved stressful for the core team,

as well as the members of the larger excellent team that had been assembled in

Champaign. It transformed the environment from one where innovations were supported

to one of following the guidance of long-time EMBU team members and their designated

architects.

Internal to Cisco (specifically with the sales and customer support teams), the

core and surrounding team was stigmatized as a poor performing team due to product

stability issues in their immature, incubation stage products rather than acknowledged for

the disruptive innovations and technologies that they produced. It was the uptake by the

sales force, rather than gradual, targeted market adoption and a lean development model,

that had negative consequences. The sales model did not match the product development

stage, and as such, it contributed to the stigmatism that the products were “low quality.”

The constant shift in executive sponsorship and new directions provided by each

organizational transition also contributed to the inability to properly incubate the

technology. No analysis of the actual product sales attempted to identify the specific

market segment that would host the early adopters, and as such, no refinement of the

product to a specific segment ever took place. In addition, the bundling of products

prevented any real insight into which products were driving the adoption. This bundling

happened in January 1998 when Centri Firewall was bundled with the Cisco Networked

Office Stack and again in October 2001when CSPM 3.0f and 2.3i were bundled with the

83

Cisco VMS 2.0 bundle. At the time, the CSPM sales were finally achieving traction on

their own, and the independent adoption of the firewall and IPS trains was being

evaluated in the market with great success (in fact, the IPS version saw rapid uptake by

existing customers). Many team members questioned whether the EMBU executive

management was attempting to justify the investment in long-standing products with

market categories either in decline or at the end of life stage. In other words, it was an

attempt to prop up the sales of products that were no longer desired by customers by

attaching them to products on in growth categories. It is not coincidental that Scott and

Imin left at or shortly after the time of this bundling.

When analyzing Cisco relative to various recommended models (Table 4:), it is

interesting to note that Moore developed many of his models while consulting with Cisco

over the past decade, where he saw anecdotal evidence of the models’ success. A

valuable takeaway of this case study is the alignment of the executive management team

with the vision, strategy, and execution model. As Moore indicates in Escape Velocity, a

purpose of the book is to provide a team a common plan, language, and understanding for

executing. The following analysis cannot compare each of the products, transitions, or

technologies, so it highlights those where adhering to the models could have been

beneficial. Also, because Blank’s customer development model applies to startups; the

customer creation and company building phases do not directly apply.

84

Table 4: Cisco Systems Summary Analysis

Table 4, cont.



Customer discovery Cisco’s attempt to reposition Centri Security Manager

without validating the product against that scale and

the acceptance of the Windows platform as a firewall

platform led to slow traction. The sales model was not

aligned with the stage of the product development and

relative market maturity for the category. Instead of

having dedicated sales staff working closely with early

adopter customers, Cisco relied on its existing sales

field and partners to drive the sales of Centri Firewall.

However, uneducated as to the differences between

Centri and PIX Firewall, the sales channels opted for

the higher sales incentive offered with the PIX

Firewall. The push to become profitable within

months of the first release was misguided relative to

the strategic importance of the technology, the

maturity of the product, and the early phase of the

market segment life cycle.

Customer validation The CSPM-I train was the result of a pivot regarding

the CSPM product, which pulled the IDS/IPS

management and monitoring functions out of CSPM.

This product was in high demand and started driving

85

Table 4, cont.


the sales of the VMS bundle; however,

Customer creation Not applicable. Cisco needed the three horizon’s

model, where this stage maps to Horizon 2.

Company building Not applicable. Cisco needed the three horizon’s

model. No BRSI efforts ever passed the tipping point

of Horizon 2 into Horizon 1.


Validated learning The lack of validated learning resulted in much wasted

effort with the BRSI team, from distributed firewalls,

to CSPM managing the IOS Firewall Feature Set and

IPSec technologies, and combining the IDS with PIX

Firewall management were all examples of efforts that

were not validated against the engines of growth or

MVP. All might have worked well independently, but

the unified management was not something desired by

customers. In many cases, painful pivots and customer

support issues resulted from these failed efforts.

Falsifiable hypothesis While many falsifiable hypotheses were developed

around business models, features and products to

integrate, etc., no formal testing of the hypothesis took

place and therefore, decisions were biased rather than

objective.

86

Table 4, cont.



Loop

With input coming in from multiple sources, customer

support issues, and pressure to innovate and release

quickly, any learning that could have been performed

was sidelined. The learning that did occur was not

systematic or based on a specific hypothesis, and

therefore, it was typically too high level to be

actionable. For example, there were known issues with

event storage in CSPM; however, the only solutions

was to resolve the database, whereas the better answer

would have been to rethink the event message data

structures and packet transport.

Minimum viable product The concepts behind MVP could have been applied at

many points within the development of the various

products and technologies created by the BRSI core

team. Some attempts at paper prototypes and designs

were developed, but they were always subject to the

large batch death spiral or “opinion” rather than

validated learning based on customer responses.

Kaban The kaban model should have been used to define a

feature release model around a small, validated set of

features that was separate from bug fixes. The upgrade

pull through could have provided interesting metrics

87

Table 4, cont.


around specific features.

Innovation accounting No work was attempted to define the funnel metrics.

However, a number of vanity metrics were routinely

collected including units sold, overall revenue,

portfolio comparisons and relative growth rates, and

the number of bugs incoming and outgoing during the

development phases.

Pivot or persevere The BRSI team and products performed many pivots.

At times, the analysis behind the pivots was faulty,

and other times, the decision to pivot was incorrect.

What was true in multiple cases was that the issue was

a failure to persevere. Because Cisco falsely assumed

the products were Horizon 2 or Horizon 1 without a

good sales channel, the team rarely had time to

incubate and validate their products. And

unquestionably, the constant threat of closing the

office or killing the product created an environment

hostile to self-criticism and “fail fast” on specific

features or approaches.

Batch Despite following a blistering release schedule, most

new features were introduced not in small updates, but

in major releases. This delay had probable effects:

88

Table 4, cont.


delayed the learning about new features; delayed the

introduction of differentiating and/or neutralizing

innovation features; and questioning the ability to

innovate by customers and analysts. With Centri

Firewall, this delay undoubtedly resulted in its

premature demise. Customer expectations were that

Cisco would accelerate the release cycle and

innovations with additional resources and expertise,

and in fact, they slowed it to a large batch. The delay

of one feature in particular released in the large batch

death spiral.

Pull rather than push Cisco did pull features from customers; however, no

attempt was made to validate the MVP of the feature

before building it. This resulted in any number of

features and supporting tools that were used by exactly

one customer, yet added complexity and usability

problems to the products.

Three Engines of Growth Understanding the metrics around the engine of

growth could have help identify sooner that the sales

model was not a good match for the early stage

products. All of the products launched and were sold

in world wide markets with the initial release.

89

Table 4, cont.


Therefore, it was difficult to assess channel issues or

other growth problems because everything was

lumped into the vanity metrics that were collected, and

the results were not questioned—if a region did not

sell through, it was rationalized as a product issue or

failure of that market to want a Windows NT based

product.

Five Whys The Five Whys model was not used; however, it could

have provided a lot of insight and corrected many

issues along the way from bad hires, problematic

issues, and bad customer engagements. The most

valuable aspect of the Five Whys model is the

incremental adjustments at each level of investigation.

However, models such as these do not improve


Category Power

Category Maturity Life Cycle Cisco’s perspective on the Category Maturity Life

Cycle was too broad, and it considered alternate

firewall technologies together, when they really

addressed different niche market (speed vs. security

depth were the first two). The market was still in the

early stages, a perfect time to prime the innovation

90

Table 4, cont.


pipeline. The firewall market continues to evolve, and

it reached nearly $3 billion in revenue in 2009. The

market is forecasted to reach $4.6 billion in revenue by

2016. Undoubtedly, the proposed innovations of

CUPS and BAM could have strengthened Cisco’s

position in the overall network security market. In

2014, the network security market is predicted to reach

about $9.5 billion.

The still evolving SIEM market was another missed

opportunity; however, it is not missing an opportunity

so much as considering the segment maturity before

withdrawing a product line relative to vision and

understanding the investment horizon.

Growth/Materiality Matrix The category growth matrix behind products was one

well understood by Cisco. However, it was used in

isolation to and eliminated pipeline technologies

within a specific category rather than reprioritized

resources to core areas by specifically eliminating

categories in the higher-level portfolio. Usually, it was

to reduce headcount, not reprioritize more resources to

a core product or technology.

Three Horizons Model In the late 90s and early 2000s, incubation security

91

Table 4, cont.


products were spread across business units. No formal

attempt to manage the portfolio relative to three

horizons was made. In addition, what little future

planning did take place was designed to provide

incremental innovations to neutralize or slightly

differentiate the products.

Competitive Separation Cisco’s failure to drive competitive separation in the

firewall market is one centered in the PIX Firewall

technologies. “Cisco is assessed as a challenger for

enterprises because we do not see it continuously

displacing leaders based on vision or feature, but

instead through sales/channel execution or aggressive

discounting for large Cisco networks when firewall

features are not in high demand.” (Reese, 2011)

Two Business Architectures High volume, high/medium margin.

Crown Jewels IOS is the crown jewel of Cisco; however, attempts to

integrate technologies into the release trains in 1998

and 1999 were rejected as taking too long-- “one to

two year cycles are too long.” The same was true for

integrating with any of the top-flight Horizon 1

hardware platforms. Allowing the team to drive

innovations into these products could have helped

92

Table 4, cont.


drive innovation in unlikely places, such as audit

events and global policy interpretation.

Market Power

Nine-Point Market Strategy Considering Cisco Centri Firewall, the target market

expanded to all of enterprise. The whole offer was

completed initially with certified partners, but Cisco

offered no partner training and the margins on pure

software plays were something the Cisco field and

partners struggled with. Later, Centri was bundled

with the Office Stack. While the competition that

really mattered was the peer PIX Firewall, the

competition remained focused on CheckPoint

Firewall-1, which was the market leader during the

GISG period. However, product differentiation was a

weakness. While Centri’s kernel proxy architecture

was superior from a security perspective, the market

demands at the time were based on performance,

specifically traffic flow rates through the firewalls.

And though Centri also supported very fast packet

filters, the development team drove the kernel proxy

architecture as the more secure solution. The session-

aware packet filter technology of CheckPoint was

93

Table 4, cont.


much faster than a full proxy. However, relative to

other proxy firewalls, such as TIS Gauntlet and Secure

Computing’s Sidewinder, Centri performed quite well.

It was performance that drove PIX Firewall forward,

as it too provided simple packet filtering. What PIX

was able to do was rebrand its packet filters as “cut-

through” proxies, which meant packets were evaluated

against a session table and if the session was in play

(allowed), no inspection beyond the four tuple (source,

destination, protocol, port) was performed.

Centri pricing was problematic because the margins

for the sales team was less than the PIX Firewall, and

one form of differentiation between Centri and PIX

was the price point—popular with customers, but not

the sales team.

Offer Power

Return on Innovation The focus on one single mode of innovation for a

given product release was difficult at Cisco; often the

focus was on all three modes. This confusion in focus

made positioning the products more difficult as well as

kept the team spread thinly across the releases. Most

important, it caused issues with the timing of releases

94

Table 4, cont.


when waiting for differentiating innovations to

complete development. The continuous deployment

model proposed by the Lean Startup model could have

addressed conflicts that naturally and understandingly

arise between neutralization and productivity

innovations and differentiating innovations. The long-

term efforts should not delay the release of short-term,

gap closing features.

Six Levers Freeing resources to work on the core was a

shortcoming of Cisco, especially given the resources at

hand. Examples of this issue were the replacement of

the database technology, which consumes some of the

best developers for years, with an off-the-shelf

solution, as well as the focus on detailed event storage

from all devices, which was competing with long

established syslog servers without providing any

differentiation.

Price/Benefit Sensitivity Understanding how customers internalized the value

of Centri Firewall did not matter because the sales

channels in play were not aligned to the market

maturity stage of the product. Had dedicated sales

teams been calling on accounts specifically for Centri,

95

Table 4, cont.


then these models would have helped the team

understand, position, and price the product

accordingly.

Core/Context The Cisco Centri Firewall was competitively

differentiated in multiple areas: policy-based

management and the kernel proxy technologies.

However, it was the policy-based management that

was truly unique and that aspect was leveraged to

develop the Cisco Secure Policy Manager product line.

Some technologies built on this strength, such as the

policy audit and rule analysis technologies. It was

when the technologies, such as IPS policy

management, fell out of line with that key

differentiator that the team became focused on

addressing issues that were not germane to the

differentiation. In fact, those same problems has

existed for all previous implementations of the Cisco

IDS management and monitoring tools. Remaining

focused on the core versus context could have

provided a framework to avoid these costly, and

ultimately, critical missteps. It was the fragility of the

database technology resulting from the influx of IDS

96

Table 4, cont.


events that was a key concern of executive

management.

Execution Power

Arc of Execution The BRSI core team on all of the products it worked

on a Cisco never left the innovation phase; however, it

was often pushed into the deployment phase on the

initial product release. What would have helped most

with each of these products is to have followed the

customer development and MVP models to iterate to

match each of the features following the initial product

release. Instead, all of the products followed the “large

batch” model in the innovation phase.

Four Modes of Execution The team and products remained in the innovation

mode, despite the fact that EMBU management

expectations moved to deployment and then

optimization in short order. This mismatch in

execution caused numerous issues from funding

constraints to profit and product maturity expectations.

Understanding the four modes of execution and

executing to those modes relative to the

innovation/product maturity and the category/market

maturity models could have ensured that investment

97

Table 4, cont.


and expectations remained aligned until the Horizon 2

phase transitioned to Horizon 2. However, Horizon 2

expenses were too high for the EMBU team, which

was attempting to operate as a profit center.

98

Recommendations

This chapter highlights key attributes of existing models, and it presents extended

options and/or changes to the existing models and guidance highlighted in the “Literature

Review” as well as defines new models focused on retaining the core team. These new

models and guidance enhance the management toolbox in the areas of assessing an

acquisition target, defining and valuing the core team, planning the transitions,

expectations in terms of ROI, integration of the core team, execution within the existing

organizations, and customer development. While innovations can succeed both within

startups and acquiring companies, this section focuses on how to manage an acquired

core team to ensure their existing and future innovations return value to the acquiring

company.

INTRODUCTION

While the “magic” of the team is crucial in understanding how to avoid

acquisition pitfalls and to structure incentives and compensation so as to retain core team

members, we can extract much of what we need from basic research on teams and team

learning. Examples of such research findings include: teams are optimal when composed

of two or three key members, team memory and intelligence is organic and unique to a

team, the loss of core members is more disruptive to the team than completely replacing

the team, etc.

When we consider organizational models that support innovation, we find

awareness of common weaknesses in the readings by Drucker, Moore, and Christiansen.

Their prescriptions for how to organize teams (those teams working on disruptive

innovations relative to established product teams working on incremental innovations)

are targeted at avoiding natural and understandable conflicts of interest in resource

99

investment and human nature. These business thought leaders focus on the overall health

of the acquiring business, whereas the perspective of this thesis is on the health of the

acquired startup team. That said, the organizational solutions are the same, effectively

killing two birds with one stone.

The alignment of proper resources (right action, right time) is key as the duration

of investment is where we frequently fail to capitalize on acquisitions/innovations. The

goal is to avoid temporary investment in innovation, especially during the fundamental

stages of a startup. Once an acquiring business unit’s leadership changes, many long-term

strategies are defunded by the replacement. The long-term vision and investment strategy

must exist separate from any single business leader. The loss of innovation, business

intelligence, and long-term outlook can reap terrible investment returns.

Why have so many of the innovations brought to companies through early

acquisitions failed, even after these gifted teams reinvent themselves two or three times

before leaving those companies? These solutions, given the correct investment, would

have yielded handsome profits upon crossing the chasm after the product matured. It is

the long-term investment required to mature a product where companies are failing many

of the startups they acquire.

As leaders of companies, we must change how we operate and organize. If we

identify promising technology, we must fail fast if needed, but we must also have the

vision, commitment, and leadership to drive a new course and forever change markets

around those technologies and innovations. Considering past shortcomings, we can

improve our acquisition model, not by changing the types of companies we acquire, but

by changing our expectations of and investment strategy in the teams that define those

startup companies so we can preserve their innovations and their innovative capacity.

100

Fundamentally, our perspective toward acquisitions must change from “how can

we leverage a startup” to “how can a startup influence, improve upon, and innovate

across our portfolios.” These startup teams have identified chinks in our armor, and

typically, they are part of an ecosystem exploiting the same niche. If our companies had

executed flawlessly, the niche would not exist. Therefore, it makes little sense to allow

the same closed thinking to drive changes into the startup’s products.

However, it makes a great deal of sense to allow the startup teams to drive change

across the business units as the startup teams see fit. That fresh perspective can drive

more disruptive innovation and strategic value into the company’s existing products and

solutions in ways that can even benefit ecosystem partners and strategic alliances. We

must capture that unacknowledged and unrealized value of driving

innovation/intelligence back into the company’s products.

Assuming that the acquisition was valid and applicable to the long-term strategy

of the acquiring company, the responsibility for ensuring that acquired innovations

survive falls to two groups: executive management of the existing company and the core

team of the startup.

The following sections identify areas of consideration and strategies designed to

preserve the core team and their innovative thinking. Combining these ideas with those

frameworks and perspectives presented in the “Literature Review” sections, we find

ourselves with a series of complementary frameworks for driving and sustaining

innovation long-term as well as maximizing the return on investment that companies

make when acquiring startups.

The following topics are discussed:

• Purchase motivation. Before acquiring a startup, the motivation and

expectations of both the target acquisition and the acquiring company

101

must be clearly articulated. Clear communications of intentions and

expectations helps ensure that the core team understands the immediate

and longer-term future of their technologies within the company.

• Organizational placement. How the team is organized and supported by

the acquiring company is critical to retaining the key core team members.

• Core team retention. Understanding the value of, connections within, and

motivations of core team is necessary to building an organization that can

successfully integrate, retain, and meaningfully develop an acquired team.

• Team engagement. Traditional integration models are inefficient at

retaining the team and reducing conflicts with previously established

organizations within the acquiring company. A new engagement model is

proposed, the inverse effort-based engagement model, to improve

alignment with company vision and drive innovation value throughout the

company.

• Customer discovery and development. Ultimately, the product-to-market

fit determines whether the technology will succeed. Startups and

established companies often have different expectations for the target

markets, which may require pivots to close the expectation gaps. Models

recommended for startups should be applied in Horizon 3 to ensure these

gaps are closed.

• Bridge management of stakeholders. The acquired teams are also

responsible for ensuring that their vision is understood and that

expectations and progress are communicated clearly at critical junctures

during the development lifecycle.

102

• Innovation pipeline management. When managing innovative teams who

perform ideally at one horizon level or another, it is important to maintain

a backlog of desired efforts that align with the vision and strategy of the

company. This backlog allows executive management to intelligently

transition teams back to their preferred horizon to continue to populate the

innovation pipeline. This backlog also provides some flexibility in that it

transcends any one level of management so that as executive turnover

occurs, a long-term vision and plan remains in place that continues

forward progress.

• Alignment of sales model and product stage. Depending on the

development stage or horizon of the product, different sales models must

be used to ensure that the development team receives input that allows

them to properly align the product to the target market’s expectations.

Failure to do so prematurely scales the sales, which results in a poor

product-to-market fit that creates numerous customer satisfaction issues

and new feature requests.

• Initial sync with expectations. The initial sync of the acquired product

with customer expectations and aligning that effort with how and when

sales can begin is critical to ensuring that the team does not become

bogged down in firefighting predictable, expected problems that result

during the transition from a small targeted market segment focus to a

broader market backed by a different sales model.

• Timing and expectations of financial output and input. The expectations

for spending and revenue generation must be aligned with the stage in

development. Understanding how the recommended models apply to

103

financials and which models to use to avoid misinterpreting temporary

boosts in sales prevents a company from transitioning to a new horizon

prematurely.

This chapter concludes with a summary of key takeaways and identifies areas

where further study can help executives better manage an acquired team and

harness its innovative abilities to develop future disruptive innovations for the

company’s innovation pipeline.

PURCHASE MOTIVATION ALIGNMENT

An acquisition is hiring for the “whole job,” at least through Horizon 3 of the

Three Horizons and, depending on the depth of the team, part of Horizon 2. As such, the

fit between the two entities is crucial to successful perpetuation of the technologies

developed by the startup. However, many pairings are not a good fit, not because of

financial terms or similar customer segments, but due to the motivation of the acquiring

company. For long-term survival of innovations, purchase motivation must be aligned

between the acquirer and the company being acquired. The best protection against a

misaligned pairing is detailed interviewing by the startup’s core team. In this section, we

explore various motivations and their effect on survivability.

The Return on Investment model (Moore, 2005) represents a perspective that is

important to consider relative to the startup that is being acquired. Using this model, the

acquiring company can properly frame its intentions and expectations of the startup.

Three key motivations exist for acquiring a startup:

• Pursuit of a new opportunity.

• Defense of an old opportunity.

• Removal of a competitive technology from the market.

104

A primary objective of the startups’ interviewing of the acquiring company is to

ensure that this motivation is clearly articulated.

Pursuit of a New Opportunity

The pursuit of new opportunity is focused on entering a new market or driving a

new product into a market where the acquiring company has some expertise. Two

considerations on the new opportunity need to be assessed.

Do competing products or solutions (Horizon 1) exist within the acquiring

company that might overlap with the intended use of the startup? Are there any Horizon 2

products or solutions that may evolve to be direct competitors with the acquired

technologies? The match can still be applicable if the startup would be a Horizon 3 effort

that would allow the company to “replace” the identified Horizon 1 or Horizon 2

technologies and if that were the intention. Otherwise, the issue becomes one of a lack of

focus on the acquiring company’s part.

The second consideration to review is the alignment of the startup team and

technologies relative to the target market of the acquiring company. It is not enough to

want to drive a technology into a specific market, but the team must be aligned to that

segment. Otherwise, a pivot must be pursued and that expectation explained to the core

team prior to the acquisition. This concept of describing the “job as it will be” is crucial

to retaining the core innovation team.

Defense of an Old Opportunity

Acquisitions often occur in defense of an old opportunity, attempting to extend

the life or competitiveness of an existing product line. Truthfully, this approach is a

slippery slope. However, this method can succeed if key considerations are honestly

addressed:

105

• Market alignment. The alignment of the market for the acquired product is

important to understand. This understanding includes the expectations of

customer scale and quality relative to that which startup team has held. It is also

helps to understand the incubation time that will be required to retrofit a

technology to a specific market. For example, attempting to move a product

targeting the small and medium business market up to the enterprise market is

going to take much longer than simply aligning the expectations of customer scale

and quality. It may require eliminating key features and developing new ones. At

the very least, the product must return to the incubation stage until the proper

product-to-market fit is found, which requires a Horizon 3 sales team and

engineers in the field.

• Product maturity. While working to cross the chasm, the reference customers of a

startup are much more willing to accept a different level of product maturity than

the acquiring company’s existing customers. These early adopters see the

potential in the technology and enjoy being on the cutting edge. That customer

acceptance does not equate to “enterprise ready” in terms of stability, scalability,

and performance. Understanding exactly where the product is in terms of maturity

and assessing how long it will take for a focused “rework” of the existing code to

achieve a comfortable level of quality is critical to preserving any acquired

technology. Discussing this potential effort with the startup team is another way

of ensuring they understand the “day in the life” before they sign on to do that

work.

• Development methodology alignment. A divergence in development

methodology, such as agile, lean, and waterfall, between the startup team and the

established product team represents a significant risk for failure. Not only do the

106

rigors, depth, and scale of testing identify potential challenges, but integrating

efforts from teams who are used to releasing product updates daily or weekly

versus quarterly or yearly is a cultural mismatch that takes strong leadership to

synchronize.

• Timeline horizon. Relative to the three previous considerations, expectations

about readiness to integrate into the existing product line must be evaluated.

Market alignment, product maturity, and development integration must all be

aligned and given the time to work out the kinks before the team will begin to

operate effectively. Integrating two teams takes months before they can begin to

operate normally, and the overhead of being acquired completely breaks the

rhythm of a startup team.

• Futures. Startups are full of visionaries. It is critical to completely understand

where the core startup team sees the technology evolving and ensure that vision

aligns with the incumbent teams view. An irreparable cultural clash occurs when

two visions collide and no one is willing to bend. Just because a startup agrees to

change their direction in order to be acquired, it does not mean that these conflicts

will not arise. Understand them in advance before setting the tone of the acquiring

company’s expectations. True fit and alignment in this area is probably one of the

strongest indicators of whether the core team can be retained after the acquisition.

• Tie-breaker Decisions. Before an acquisition is made, the executive sponsor must

make a decision as to who will ultimately make tie-breaker decisions regarding

technology integration and future directions, and all potentially involved parties

need to openly and honestly agree to abide by that decision. As the startup has no

political clout within the established company, regardless of superior architecture

or design expertise, the incumbent team is going hold most of the power.

107

In the “defense of an old opportunity,” an intermediate alternative is to contract

the startup team to perform some integration work with the existing products. This

approach allows the teams to shift toward a more cooperative model before throwing

them together. However, as discussed in the “Organizational Placement and Stability”

and “Inverse Effort-based Engagement Model” sections, a change in the engagement

model of an acquired team might better serve the acquiring company and the startup

team’s outside-in analysis of the incumbent products might be a real eye opener and go

further toward achieving the goal of revitalizing and defending an existing product.

Denial Strategy

An alternate defense strategy is that of denial, where the acquiring company is

simply removing a competing or potentially threatening technology from the market by

buying and shelving it. It may sound unlikely, but relative to a “mind share” campaign,

development costs, and the time required for a gamble, this sure thing strategy is used by

often shrewd businesses.

The only time it makes sense to accept an offer from a company pursuing a denial

strategy is when the startup is either breaking up on its own (as an exist strategy where

the keys are being turned over and walking away) or when the technology has a short

horizon (been overcome by new innovations) and market consolidation is truly the best

method of protecting your customers. Otherwise, this motivation will not be changed

after the startup is acquired. Startup leaders must put aside visions of pitching the

technology to various business leaders in hopes of achieving stickiness once they are on

the “inside.”

108

Considerations from the Startups’ Perspective

A big part of new innovative technologies is that people and companies are not

quite ready to adopt the technology; therefore, a company that is first to market must

define and create the market. That takes a lot of money and long-term commitment. The

best way to do this is to follow the Crossing the Chasm strategy. However, duration,

persistence, and investment are the key factors here.

Startups need to perform due diligence on their acquiring companies to ensure the

success of their technologies. Unless that technology fills a clearly, admittedly missing

portion of the product portfolio, the purchase motivation and resulting organizational

placement can be true indicators of the likelihood of success. For truly disruptive

technologies, a startup team does not want to be acquired to make a languishing product

line relevant again. The proposed placement, or purchasing business unit, can indicate

whether the innovations are considered the next generation product (Horizon 2 or

Horizon 3) that will propel the company past the competitors or whether they will be

competing for resources from the product that currently yields better revenues. That

competitive scenario is a losing situation for startups. However, if the technology is an

incremental improvement to the products of the acquiring BU, the startup team must also

ensure that their innovations are not considered the next generation product. In that case,

the expectations are too high. The team must understand the relative value of their

innovations and whether their product should augment an existing one (merge into that

code base) or be a separate later generation product.

Motivation Summary

Typically, the acquisition decision is motivated by either filling a gap in

innovation or accessing a new market. Either way, the intention of the acquiring company

needs to be clear. If purchasing to address innovation needs, ensure that the plan accounts

109

for incubation time and properly isolates the startup team from competing Horizon 2 and

3 initiatives. If purchasing to move into a new market, understand clearly whether the

exiting products are suitable for that market, and explain to the startup core team that

their focus will change.

As the core team is critical for innovation, the sales and marketing teams are

critical to moving a company into a new market. Often during an acquisition, these team

members are discarded as a matter of closing or thrown in with a larger sales force and

asked to focus on this new market and to meet the sales goals of the larger sales team.

This critical flaw results in their no longer focusing on the Horizon 2 or Horizon 3

products of their acquisition. As Moore discusses with respect to Horizon 2 products and

solutions, the startup must be organized in a separately funded and isolated business unit,

protected by an executive who understands the metrics of success and upper management

who protects the company’s focus on the Horizon 2 and 3 products.

ORGANIZATIONAL PLACEMENT AND STABILITY

Startups sometimes represent emerging markets and always represent emerging

technologies. However, their vision is something that needs to be kept intact while the

progress is evaluated relative to market changes and external innovations. To enable the

survival of long-term innovation, these teams must be abstracted from the common

disruptions of established corporations—executive turnover and group reorganizations

into different business units and technology groups. After keeping the team intact, the

most critical factor is avoiding changes in short-term (1-7 year) investment priorities,

which greatly disrupt the team’s progress.

110

In Escape Velocity, Moore lays out the leadership requirements and clarity that

must drive not only the motivations behind acquisitions, but also the corporate structure

and funding models that enable the Three Horizons model.

Organize to Retain

As Moore clearly states, Horizon 2 funding and structuring the startup team must

include its own focused sales and marketing teams, preferably the teams that came with

the acquisition. When the product transitions to Horizon 1, the entire team should be

transitioned onto another Horizon 2- or 3-innovation effort. These new efforts can be

identified during the yearly re-envision effort, and there will be a backlog of new

innovations worth exploring on the corporate kaban (see “Innovation Pipeline

Management: Corporate Kaban”).

This separate organization and executive sponsorship operates as a incubator,

which is necessary for acquired startups to operate as Horizon 2 or 3 efforts, as they often

must address large gaps in the desired direction, market, and product alignment. As

Moore described, Horizon 2 teams are focused on crossing the chasm (demonstrating)

and accelerating to reach the tipping point (promoting). Horizon 3 is really is in the

earliest phases (imagining and incubating) of the technology innovation cycle—

understanding the problem, developing prototypes and demos, refining the idea for fit

with the target market, and validating the market size and potential.

Any acquisition requires the time and security to realign before the team can

perform. They need to understand how new relationships supplant those lost in the

closing, embark on the realignment in priorities and markets of the acquiring company,

assess what such changes mean in terms of effort, identify and talent gaps, and then

overlay some level of project management practices to derive new timelines that are

111

realistic. These gap analyses and timelines ultimately determine whether the team

initially operates as a Horizon 2 or a Horizon 3 effort, which in turn determines the

desired team composition.

Location Relation

To remain operationally efficient, the core team needs to retain the same location

relation. In other words, moving the primary founder and visionary 2,000 miles from the

core team can have drastic effects on the productivity and day-to-day operations of the

team. It is important to note that this same level of “removal” can occur through job

changes or poorly considered engagement models with the core team.

Logistical Considerations

When a team is acquired, their world is turned upside down. From needing to

understand health benefits, 401k, paycheck deposits, the phone system, code repository

requirements, new standards, moving locations, interfacing with a slew of new people,

etc. All integration leads to a disruption in the team’s rhythm and focus, which takes time

to regain. Considerations of a slower facility integration should be made, migrating parts

slowly. While much of this overhead is required, it is prudent to allow the team to “seep”

into the company, which will happen as they find more opportunities and teams that they

choose to integrate with and as they hire or leverage additional staff.

CORE TEAM RETENTION AND GROWTH

No other aspect of a startup speaks to innovation like the core team. Identifying

the membership of the core team is a delicate undertaking so the recommendation is

value the team as a whole. Team intelligence is an organic web drawing on a complicated

set of relationships, experiences, and knowledge. By changing the composition of any

team, we can end up with a team that is less efficient than a complete replacement.

112

While there is no recipe for retaining an innovative team, we can change the way

that we look at acquired teams so as to maximize the return on investment, bring new and

different thinking to the established company, and to drive more innovation throughout.

To do that, we must understand the team, avoid common mistakes that prune members

from the core team, focus on accelerating the growth and potential of the team, and lead

them through the transitions from startup to Horizon 3 to Horizon 2 (and in rare cases, to

Horizon 1).

The Value of Relationships

One of the secrete sauces of a successful startup is the relationships between the

core team members. Specific success factors of software startups predict much higher

success ratios, as described in Paul Graham’s interview as well as The Startup Genome

Report. These factors should be evaluated prior to acquiring a startup, as they are strong

indicators as to whether the team can successfully make transitions among horizons and

whether they can be refocused on addressing future innovations following a successful

transition. Specifically, the long-term relationships of the team members that extend

beyond just a business relationship has a higher motivation for success, especially during

the difficult times that startups face, such as pivots and acquisitions. When things go sour

in the startup, and they will, the kindred spirit, friendships, and shared experiences hold

the team together in a way that disinterested or Horizon 1 team members cannot.

People who have been friends for a while, who have worked together before, and

know each other capacities can be more important than the ideas that they are focused on.

This fact can be explained in part by the research surrounding cross-understanding

constructs of team members that can contribute to a the higher team intelligence (Huber

and Lewis, 2010) and the research concluding that disrupting the structure and role of

113

that team can have long-term ill effects (Lewis, Belliveau, Herndon, and Keller, 2007).

For example, research shows that losing a core team member can be more detrimental in

the short term than replacing the entire team. Understanding this point is key to

understanding why acquired startups innovations often fail when key members from

executive, sales, administration, and marketing depart. The crux of the matter is not the

position held at the time of an acquisition, but of the role of the person relative the core

team. At a startup, the executives, sales, marketing, engineering, test, and documentation

people are often core members, accepting any role they can perform to the benefit of the

company.

When acquiring a startup, the tendency is to evaluate team members criticality

based on business card role. In a startup, few members are limited to a single role;

however, they often pick some title to print on their business cards that reflects best

during their customer engagements. Maybe someone is Vice President of Sales; however,

he might also be in charge of inbound and outbound marketing, the sever farm

administration, and software build management.

Attempts to map startup team members into the roles and grades at an acquiring

company often cripple the network intelligence of the team and force the team members

into roles that are subsets of what they actually perform. From there, the performance

management system drives further separation into the team intelligence. This role change

is fraught with risk; instead, an acquired team should be kept wholly intact and evaluated

to understand the various roles. By allowing each team member to document and shed

responsibilities, the intelligence and competitive advantages can be retained and the

easily shed responsibilities can free them up to focus on the tasks that they enjoy most

and as such perform better.

114

The Value of the Tell

Startup teams who have rallied together bring with them a shared history, and that

history is key to retaining that unique identify that inspired and encapsulates their

struggles, loses, and victories. Internal evangelism has an enormous effect on the

effectiveness of the team. It’s the religion of the startup that inspires and builds

something beyond a working relationship. A shared history is an extremely powerful part

of a core team’s culture, and it sets them apart as a group from all others.

On the surface, it might seem contrary to a company’s interest to help the team

retain part of its identity, but it is part of the essence of the team. With its history comes

pride and a sense of belonging, and it encourages a sense of bonded individuality.

Keeping as much of the core team together as possible can greatly improve the

indoctrination of new members and their likelihood of repeating success. Most venture

capital groups look for teams who have succeeded in an earlier endeavor or gracefully

closed down a failed enterprise—core teams carry a common literacy and knowledge. If

this team can be repurposed multiple times to drive disruptive innovations back into the

company, that identity will become even stronger, and the company will become woven

into the fabric of their tell.

Avoid Entrepreneurial Erosion

When a startup is sitting inside of a huge company, literally hundreds of people

bring in product and compliance requests and ask the startup team to learn about the

adjacent products, customer segments, and processes. As a result, the team begins to

experience what the author of this thesis refers to as entrepreneurial erosion. No longer

focused on the vision and the dream, but forced to drink from Niagara Falls, the visionary

leader is dragged into meeting after meeting where the vision is eroded to a few basic

functions that the product was not initially designed to perform. These changes in vision

115

are not pivots because they do not originate from paying customers but from powerful,

established business units and leaders. The startup leader believes that if he can attach his

ship to a battle station that is a huge corporate cash cow, then his team can survive.

Nothing is further from the truth—allowing the leader and the team to engage with

external teams only when the leader considers it advantageous can keep the team focused

on their vision and any true pivots, such as aligning to a new customer segment, that are

required of them. One pivot at a time is the rule—then it is build, test, learn.

Avoid the Boxing in of Job Descriptions

Cross-boundary individuals often act as the creative spark within a group, and at a

startup, their blended strengths are capitalized on. However, standard corporate job

descriptions often limit an individual’s ability to operate across multiple roles, effectively

restricting them to one role or another—preventing these individuals from truly

accelerating and frustrating them. In addition, the grade level ceilings often force people

out of roles where they are happiest and most productive in order to continue receive

financial and recognitions rewards consummate with their expectations and contributions.

Studies of creative individuals (Fryer, 2009) find that they compulsively network

with smart people with whom they have little in common, but from whom they can learn.

They associate rapidly, creating new connections across seemingly unrelated fields and

ideas, and they experiment freely with new ideas and experiences. To flourish,

individuals who possess these characteristics need more freedom than is provided by the

standard job description and team role roster.

In Four Steps to the Epiphany, Steve Blank stresses the importance of highly

cross-boundary roles for engineering, marketing, and sales during the Horizon 3 stage.

He even advocates for different titles that prevent team members from falling back on the

116

limited scope of their “job title” for guidance during difficult times. Clearly, for Horizon

2 and 3 programs, the traditional roles must be re-evaluated to prevent stifling the most

innovative among the core team.

Avoid the Pitfalls

Avoiding common mistakes in managing the core team begins before they are

acquired. It starts with understanding where they have been, how far they have

progressed, and why their valuation is not higher. To get a great price for a startup is to

acknowledge that they have not driven their product effort to the tipping point.

The startup teams need to develop their product at the pace they can sustain it.

Too fast, and they collapse under support issues, too slow, and they lose out to

competitors. The executive sponsor must be patient and understanding that some pending

technologies may need to come into existence before huge growth can be realized.

Instead, the executive sponsor must understand how they have balanced paying

their bills (contracting, customizing software, etc.), as these efforts have taken away from

furthering the technology. He must understand their long-term vision for the technology,

in its many variations and try to pinpoint whether one of those visions would resonate

with the acquiring company’s customers. Then, the sponsor must estimate how long it

would take for the team drive to that product with the level of quality that customers

expect from the acquiring company. All of these efforts are to help gauge the horizon of

investment, or when one can reasonably expect positive returns given this simplistic

view.

If the market segment or other aspects of the long-term vision of the team do not

align very closely to the executive sponsor’s vision, then that gap must be addressed with

the team before the buyout, being clear that despite their attempts to persuade otherwise,

117

these key realignments will be required. When it comes to communicating with a startup,

the leader of the team must be identified. Successful startups have a clear, forceful leader.

If the core team is full of peers rather than having a clear leader, then no one exists to

make hard decisions and drive the others. As Paul Graham says it is imperative to

identify one who steps forward a little and stands out—a clear leader.

The leader is the one who motivates and drives the team forward, and he is the

key person to convince of the new alignments and vision for the team. That leader needs

to present the vision back to the team and sell them on it, and that expectation must be

made of him. However, the executive sponsor must provide a question and answer

session for the whole team around those realignments before moving forward with the

changes. Visionaries are a confident lot; they often believe they can convince anyone of

their vision, especially when they have a group working for them who already believes.

Leadership is required of the executive sponsor; he must recap the required realignments

to the whole team and be prepared for some tough questions. He should also take this

opportunity to explain the anticipated future transitions from Horizon 3 to 2 and Horizon

2 to 1 and clarify when the team will likely separate from their product. It is critical to

paint the picture of what their success looks like and their reward, which is to hand off

their product and change focus on the challenging work of a new innovation.

Next, the acquiring company must focus on how to keep the team together long

enough to realize the long-term visions and horizon transitions. In a startup, many of the

team members are often under paid, over worked, and resource starved. All of which

affect motivation, performance, and thoughtful analysis. As part of an investment

strategy, the company must expect to invest more before large returns are realized. The

investment does not stop with the acquisition, in fact, that should really be considered a

118

small part of the overall investment, especially if the team is a Horizon 1 or early stage

Horizon 2 investment.

As mentioned earlier, the leader of the team is key to the success of the team;

however, leaders are often founding members of the startup. Structuring incentives and

roles are critical to retention. Founders often leave after receiving a huge cash infusion,

especially if they are restructured into roles that do not suit their needs or if they are not

truly convinced of vision realignments. The executive sponsor must clearly define the

role that the he needs and discuss whether that is a role the founder wants to occupy. If

not, then the company should considering passing on the acquisition and identify a better

fit.

For the remainder of the core team, incentives must also be structured differently.

Consider options such as roles, work/life balance realignment, burnout avoidance with

more reasonable schedules, recharging with sabbaticals, offloading some of the tasks

identified in the “Growth Catalysts” section, etc. The stresses and strains of a startup are

different than a large corporation—as an example, politics are rarely an issue in a startup.

To incentivize growth, retention, and focus, Drucker and Moore both explain that

the compensation packages must differ among the horizons. Benefits can be a subset or

still unique to the team, such as profit sharing in the startup’s products. The draw of the

“next” startup includes the big payout of an IPO or an acquisition—that has to be

countered via a compensation strategy or the core team, with its shared history, may

depart to repeat their recent success, only this time they have the support of a VC

community that favors proven teams.

Additionally, the VC community from which the company selects acquisitions

can be pressured to fund only those teams that will stay together. Again, the focus should

be on the relationships among the founders, avoiding those who have come together only

119

for the purpose of this startup. The vision must be enforced by only buying those startups

that meet this criterion, which will also improve the success within Horizons 2 and 3

efforts and with retaining the startups’ core teams.

Growth Catalysts

As defined in Sir Ken Robinson’s book The Element, a team comprises

individuals in a synergistic environment, enriched by their peers, and allowed to thrive.

The separation or desecration of that environment changes how the organism grows and

can cause it to die. Removing keys components can be disastrous. There are also

fertilizers and better lighting that make this environment rich and fertile for the team.

Companies must strive to find those catalysts for the teams, while avoiding removing key

components or pruning too deeply in the tree or sterilizing the environment, not only for

ideas but for execution and natural growth.

Likewise, in Moore’s discussions of core vs. context, core refers to that which

differentiates a company relative to its competition. Context is all of that other stuff that

has to be done to stay in the game. While some context is required effort by all, much of

the context can be out-tasked relative to the core team. It is in these functions where the

acquiring company cannot only enable improved focus on the core, but it can also excel

in the execution of context through scale and focus on productivity innovations in these

areas.

Some areas and tasks are already optimized in large acquiring companies, such as

payroll and benefits, and while core team members may have been performing these

tasks, the aspects that apply to developing and evaluating metrics around disruptive

innovations can and should be kept within the team. Others are simply required to run a

company and can be safely offloaded from the core team, acting as a catalyst by returning

120

time to the members. For example, consider the following areas of high value to a startup

team where a large corporation can make a valuable impact without interfering with the

innovations:

• Accounting, payroll, benefits management

• Financial audits and oversight

• Channel management and distribution

• Component/vendor price negotiation (improved margins)

• Manufacturing expertise to improve the quality and reliability of any hardware

shipping

• Legal oversight and contract support

• Support with regulation adherence and/or avoidance

• Intellectual property and patent clearance and defense with existing portfolio

• Training and development; continuous learning support

• Initial interviewing and screening of candidates for open positions on the team

• Code and design reviews

• Core infrastructure support, such as office space, test equipment, backups,

hardware (even castoffs from other groups), carving out virtual servers in the data

center to augment testing and development efforts. The team needs to engage in

this effort, instead of being forced into it. Their coding/testing environment is an

integral part of the team, and they have ideas on how to improve it. A company

should merely provide a rich, fertile field. They’ll start sowing seeds when they

are ready.

• Product lifecycle management, including bill of materials (BOM) End of Life

(EOL), End of Sales (EOS), and End of Support.

121

• Tech support. This engagement is also a fine balance, as it is a critical customer

engagement. Considerations include quality of the shipping product, whether

market pivots are in play, the size of the old and new markets, whether the team is

maintaining legacy products, etc.

The following examples are opportunities to support and enrich the team without

drawing their focus from the targeted transition or altering the organic composition of the

team:

• Assume the role of a venture capitalist, where the executive sponsor invests in the

development of the technology with a long-term perspective on ROI, and

leverages his network to facilitate that effort.

• Establish mentoring and network connections to act as advisors, replacing the

outgoing advisor board, which is a critical component of any startup.

• Announce the team as a standalone unit so that customers know there will be no

disruption in the focus and direction of the product beyond the pivots the team

might normally make to address shifts in the market.

• Operational support. Lend credibility in new market segments, inherited from the

acquiring company, such as “piggybacking” on existing account teams to get

exploratory meetings with key customers and to learn about the target market.

Often, a key barrier to customer adoption and a consideration for being acquired

is that the startup has no credibility or long-running relationship with their target

market. They are unknowns, and in some spaces and economic environments, that

equates to gambling with resources from the customer’s perspective. Identifying

contacts, assisting with engagements, and talking to customers about the long-

term commitments that the company has to the startup team and their technologies

can open doors and accelerate learning by the team.

122

• Internal marketing support, such as an internal web presence, coaching on how to

access to better market analysis data (expensive stuff already lying around), key

engagements around the field sales teams, etc.

Leading Transitions

Accepting the role of a VC really encapsulates the mentor/advisor role that leads a

team through transitions, not only into the new company, but through each of the

horizons. Honestly is key to leadership, and the acquiring executive should facilitate the

discussions that help the team understand any anticipated pivots and foreshadow future

Horizon transitions. Next, that acquiring executive must identify a trusted executive

sponsor who can support the team, who follows up with them to understand what their

needs are, ensures clarity in the refined “joint” vision, which would be limited to market

segment and customer “expectations” for quality/performance. That sponsor should

assign trusted mentors to the team and label them with key areas of support, such as sales

engagement, go to market, manufacturing, market analysis, infrastructure support, and

customer support development.

A sustainable integration model is as important as mentoring. Letting the new

team find its own way inside of the company takes resolve (more detail in the next

section, “Inverse Effort-based Engagement Model”). Efforts should focus on keeping the

core team in place and retaining the sales team, as they are the beachhead and adjacent

market gurus (it also keeps their accounts alive and happy) as these startup engagements

often hinge on the relationship and personal connections.

In Crossing the Chasm, we find some guidance contrary to innovation and

effective teamwork (Moore, 2002, pp. 199), although it was later repositioned in Escape

Velocity. (Moore, 2011, pp. 169) Moore recommends replacing the core team after chasm

123

is crossed; he suggests a team of different abilities is better able to drive growth in

adjacent markets. It is this author’s opinion that this suggestion can create a chasm

between the company and its desired future, disruptive innovations. While replacing the

startup team may improve sales and growth around that particular technology, it

squanders the investment in the startup team, their composite intelligence, and their

aptitudes for innovation. Instead, the existing team should drive an innovation pivot back

to an appropriate horizon, while the new “team” runs with sales and maintenance. Two

teams, sustaining and innovating, can be considered given the appropriate market

maturity stage. In this way, the team can transition onto the next generation or an

alternate disruptive product focus. To do this, a sustaining team must be developed at the

next horizon to support the existing customers and product. The sales team should drive

customer requirements into both the sustaining and innovating teams to identify market

transitions early and prevent the huge gaps in satisfying customer demands that typically

occur when a product is managed to end-of-life and replaced by an immature next

generation product (for example, CSPM being replaced by the Management Centers).

INVERSE EFFORT-BASED ENGAGEMENT MODEL

To preserve the purchased innovations and extend the entrepreneurial vision of

the team to address product or technology shortcomings of the acquiring company, the

model of engagement with established product teams and businesses of the acquiring

company must be evaluated and changed.

Assuming that the startup was acquired with the correct motivational alignment,

the goal should be to see the startup team influence others in the company in a positive

manner and to increase the value of as many products in their existing portfolio as

possible. This goal requires accepting that the startup team, either through vision, focus,

124

or execution (or all three), has been able to address customer needs where the existing

lines of business have failed.

This fact must be tempered against the fact that disruptive technologies developed

by startups often fail to match the markets, channels, profit margins, and maturity

requirements of established firms. Often through the mismatch of one of these key

attributes, an acquiring company fails to successfully exploit the acquired technology.

A common issue with acquisitions is that established groups, who have failed to

adequately innovate, end up driving the direction and requirements of the newly acquired

teams. The management team and product teams with which the disruptive technology

competes often fail to support and fund the development of the technology because it is

perceived as a threat to their sustaining and currently market leading products. As a result

of this lack of support, the innovators leave the company. It should be noted that this

problem is not one solved solely by an organizational model that focuses on the Three

Horizons model.

Assuming, however, that Moore’s organization model is adhered to, then strong

leadership and management can both drive changes that can exploit such technologies in

more than a single product line. Such guidance can leverage a technology so as to enable

the development of new crown jewels and to shape the next level of competitive-

separation strategy in new or established markets for complex systems and volume

products.

This model is based on the concept that startups’ innovations and their founders

have addressed gaps in the acquiring companies product lines that other internal business

units were unable to accomplish. The successful application of the innovations and the

acquired teams is key to the successful ROI for acquiring a startup. Leadership and

125

management are critical to driving the two components of this model: the pull and push

engagements.

Pull to Align

Instead of the natural model where the business units feed requirements into the

startups product, that role should be reversed. The startup team should analyze their

requirements and put to “internal bid” the support they need from the existing product

lines, such as through an internal request for proposal (RFP). In this way, those product

teams that adapt or have existing, under used features can be brought to light more

quickly. As a result, those teams that adapt will move innovation forward much more

quickly than those who are self-focused on incremental innovations. These adaptive

teams will catch the innovation wave and encourage much faster adoption of acquired

technologies. This role reversal will also solidify the acquired technology and preserve

the structure and predicted growth of the technologies along the timeline that the team

can support. And last, pulling engagements supports a need paced integration model,

allowing the team find its own way inside of the company and supporting the team’s

organic growth.

Push to Innovate

Using the pull model alone only taps into half of the innovation potential that was

acquired. By turning the model around further, the startups can begin to feed innovations

into other products lines and business units. Innovations that often fall outside of the

target scope of the startup team. These startups exist because they identified chinks in the

company’s armor or addressed market segments where the company is either not in or

has failed to gain traction. It is often against Horizon 1 products that startups have

positioned themselves. Therefore, they can help these existing product teams improve the

126

incremental value of their product lines, shore up their defenses, and innovate in new

areas. This push brings fresh thinking to old product lines rather than having the existing

product teams push their dated thinking onto the startups.

This change in the expectations of existing product/system groups requires strong

leadership and management. To drive innovation back into the core of existing business

(Horizon 1), the leadership team must require that the other teams accept that these

startups will drive innovation into their products and that those needs must be equally

balanced against incoming customer requirements. Otherwise, the established teams will

not make great innovations and will continue to make the non-disruptive incremental

innovations. The recommendation would be for Horizon 3 teams to drive requirements

into Horizons 1 and 2 as well as for Horizon 2 teams to drive them into Horizon 1

product lines.

CUSTOMER DISCOVERY AND CUSTOMER DEVELOPMENT

Typically, when an acquisition occurs, the existing sales channels deluged the

product team with new market segments, resulting in what Moore refers to as market

segment dilution. This dilution prevents the acquired team from focusing on and refining

against the market their specific, selected target market. Therefore, they produce products

that really satisfy no one—their product becomes a poor jack-of-all-trades and master of

none. The better strategy is to build a defensible position and then move out from there

incrementally.

When a startup is acquired, they may have to change their market type and/or

their target customer. Instead of trying to re-segment an existing market, they need to

adapt to the customer base that the acquiring company wants them to target. As a result,

they will need to revalidate their feature list—it is a full pivot.

127

In this model, they may need to remove or deprioritize features that do not help

them target that new customer base. Often times, a pause and reset may be the best

approach so that the team is not bound targeting existing customers and the new

customers. Advantages of this refocused product-to-market fit are that the customer

acquisition costs are greatly reduced when the fit it strong and the timeline to reach the

tipping point in that market is accelerated.

If the company believes that a product needs to be bundled for it to gain traction,

consider it a tell-tell sign that a product-to-market fit has not been found. Newly acquired

technologies and products should not be bundled in product solutions until they have

reached a late Horizon 2 or early Horizon 1 stage. The negative effect of bundles is that it

easily hides a product-to-market mismatch. Advisors to the Horizon 2 teams can

recommend solutions that the team should consider integrating their product with, but

efforts should be taken to avoid having other teams pull them in. The product team needs

to own this type of engagement and decision. If anything, the guidance of advisors should

help them understand the implications that might result from support issues if attached to

other products in a bundle. The product-to-market fit of the bundle should also be

evaluated carefully using early Horizon 2 or late Horizon 3 techniques.

The Three Horizons and the execution models that Moore recommends in Escape

Velocity target large companies and the common hurdles they face. Jolly’s model is a

thought provoking view of the end-to-end stages in a technology’s lifecycle (Jolly, 1997).

And regardless of the model, it provides a clear grounding framework of all products and

technologies and the stages they must go through to reach maturity (Figure 10:).

128

Figure 10: Technology Commercialization Lifecycle

Copyright 1997. V.K. Jolly.

Where Blank, Reis, and Maurya differ relative to Moore and Jolly is in their focus

on execution by the startup. They assume small core teams, transitions based on

successful execution of the milestones in the models that Blank defines, and the unique

skills and focus of early stage development. However, their perspectives and models are

directly applicable to the Horizon 3 efforts in a large company, especially if a core team

has been transitioned back to a Horizon 3 effort as identified in the “Innovation Pipeline

Management: Corporate Kaban.”

If we consider Moore’s Horizon 3 or Jolly’s Imagine and Incubate phases, we see

that validating the idea of the innovation and selecting the target market segment are

inseparable tasks. While the founder’s vision provides the initial idea to vet to customers,

the flow, process, staffing requirements, and spend of the Horizon 3 innovation is

dramatically different from the other two horizons. However, so is that which can be

learned from this process. Reis and Maurya both reference Blank for guidance on

129

customer development, yet both prefer to alter Blank’s process by delaying development

as long as possible, instead they suggest refining the idea and the pitch until they get

traction (customers willing to pay for a product that does not yet exist), and they can

gauge the size of the market more accurately. Blank’s process focuses on not ramping up

to the “big spend” sales and marketing components until a sales model and pitch is

proven to be repeatedly successful within the target market. In Moore’s model, this

repeatable success would signal when management should begin to consider a transition

from Horizon 3 to Horizon 2; however, too much success too early can overwhelm the

product development team.

Instead, a recommendation at this stage is to augment the Horizon 3 team with a

Horizon 2 development and test organization before the sales and marketing engines

ramp. The technology maturity cycle must be considered and addressed during these

transition gates. The integration of new development and test team members takes

considerably longer to integrate and become productive than do sales teams. Marketing

and sales teams appear more adaptable and begin to follow common strategies to drive

the product growth. However, the fit of the marketing team members is key and new

members should support rapid growth in beachhead markets, while the original marketing

team members focus on new target markets. These hybrid teams should co-exist until the

product matures to a level expected by the customers in that market and the proper

system and process documentation is extracted from the core team members to enable

continued training of new staff. Only then can the core team be safely refocused on next

generation innovations.

Blank highlights the differences between Horizon 3 and Horizon 1 efforts as “in

big companies, the product spec is market-driven [sic]; in startups, the marketing is

product-driven [sic].” Initially, Blank focuses on validating that a market exists for the

130

product as envisioned, not gathering new requirements. He tackles the largest spend

problem, which is ramping up a sales and marketing engine to an unknown market. Reis

and Maurya focus on avoiding wasteful efforts in building a product that no one wants.

These are alternative views of the same problem, which is the absence of a viable market

of customers who are willing to pay for the product. Ries’ work builds off of Blank’s, and

so may be a better model. The one potential pitfall with this model is that it may lend

itself better to non-disruptive innovations. Alan Kay’s famous quote “The best way to

predict the future is to invent it.” illustrates the divergence of disruptive technologies and

finding ones that address known and understood problems of potential customers. It is

questionable whether millions knew that their problem was that they could not carry

1,000 songs in their pocket until Apple gave us the iPod.

BRIDGE MANAGEMENT OF STAKEHOLDERS

In analyzing the technology development lifecycle, greater emphasis must be

placed on what Jolly refers to as bridge management of stakeholders (Jolly, 1997).

Awareness of these bridges and intentional identification and management of key

stakeholders is required to successfully transition.

Bridges are transitions between specific phases and are often ignored or

overlooked; however, proper management of these bridges enables successful adoption

and prioritizes resources for the development of a technology. To falter with any of these

bridges, which manage key stakeholders critical to the transition between each phase, is

certain to delay acceptance or pre-maturely end the development effort.

These bridges exist between each horizon defined by Moore and between each

step of Blank’s Customer Development Model; however, they exist at other key junctures

as well. Jolly identifies the key bridges as follows (see Figure 10:):

131

1. mobilize interest and endorsement (imagine to incubate)

2. mobilize resources for demonstration (incubate to demonstrate)

3. mobilize market constituents (demonstrate to promote)

4. mobilize complementary assets for delivery (promote to sustain)

Jolly refers to the value of engaging peers in similar areas of invention by

espousing the ideas early and often to elicit feedback and build buy in and consensus

around the validity of the idea. However, this process must be controlled and deliberate.

The research shows that the credibility of the person and the thinking underlying the

technology, market positioning, and likely issues and their mitigation defines the success

of the technology uptake. This engagement takes skillful balance of evangelism,

persuasion, and salesmanship, especially when dealing with peers who are developing

competing ideas or technologies.

Within a larger corporate setting, secrecy can alienate technology. Therefore,

Horizon 2 and 3 teams should plan to communicate their ideas frequently—oft-

communicated ideas are the ones that stick. Besides peers, the team must identify the

stakeholders who influence and determine resource allocations that enable development

to proceed. Influencers include customers, peers, key technologists, and the leaders of

incumbent projects that receive most of the funding at that level. Peers are managed

because they add credibility to and influence other influencers, and those stakeholders

able to provide resources. Avoiding long, public debates in front of these stakeholders, as

well as helping to dispel skepticism and vetting the thinking around the ideas, is why

influencers must be managed from the outset. Managing peers and other key influencers

is an ongoing, individual engagement model. However, a more formal engagement model

can be put in place for managing the stakeholders responsible for resource allocation.

132

It is the promotion of the team’s technology and innovations that ensures

consideration during the yearly review and determines whether it is promoted from a

Horizon 3 to Horizon 2 innovation when it reaches the maturity level required by that

transition. Therefore, a quarterly update to key stakeholders is recommended. It is also

important to understand that the stakeholders at each Horizon change.

These quarterly updates need to convey what the technology is all about, its

commercial uses, how it competes with competing technologies, and the steps needed to

take it further. They should be timed so that a review falls just before the yearly

competitive separation review begins as it leads in to operational budget planning.

LEAN STARTUP MODELS CONSIDERATIONS

Ideally, any startup being acquired is at some stage of implementing The Lean

Startup models. As Eric Ries points out, Lean Startup offers no earth shattering new

ideas—they exist in other fields—but the ideas are applied specifically to the startups and

the software development lifecycle. This framework of models is key to driving Horizon

2 and 3 innovations to the tipping point, which enables the transition to a Horizon 1

product. These models rely upon and complement the customer discovery and

development models defined by Steve Blank. They intend to reduce wasted effort, avoid

building and marketing products not accepted by the target market, and avoid feature rich

complex products where most of the features are used by a fraction of the customers

(reduce overall cost). The methodologies proposed by the Lean Startup movement focus

on improving the product quality and the processes incrementally to achieve a better

quality-to-speed of development ratio.

133

Minimum Viable Product

The cost of developing, testing, and maintaining non-critical features detracts

from working on those that are critical. Find what sticks, resonates, and can be sold into

the target market consistently before embarking on product embellishment. Horizon 1 is

all about incremental innovations; save non-critical features for that Horizon. In a product

category full of competing products, this refined focus ensures that the differentiating

features receive the focus and refinement they require to distance the product from the

field of competitors.

The concept of an MVP is discussed by Blank, but Ries and Maurya describe the

critical importance of this process as finding what sticks before you launch. In some

cases, paper prototypes and mock-ups are used to vet the ideas. When applied to startups,

especially those that are acquired and expected to target a market type or market segment

different from that which they targeted as a startup, this principle becomes critically

important. The goal of any such pivots is to reduce the feature set of the base product to

the minimum set of features critical to acceptance by the customer.

Build-Measure-Learn Loop Model

The integration of marketing, sales, and engineering efforts into a co-operative

effort that keeps all team members on the same page with respect to the product, features,

and market being targeted is a difficult problem to solve. This thesis proposes the Build-

Measure-Learn Loop model to address this problem.

Based on agile and lean manufacturing processes and combined with the validated

learning in the Lean Startup model, this development model iterates customer-facing

product builds much faster than traditional models. Its intent is to provide quantitative

feedback on new features or changes in near isolation, as well as to identify those who

can provide qualitative feedback relative to the hypotheses. Work is geared toward

134

learning or proving a falsifiable hypothesis about the direction or change, it is then tested,

and the learning occurs based on interpreting the test results and interviewing or

evaluating individual behaviors (user acceptance tests).

Falsifiable Hypothesis

Understanding how to apply the scientific method to abstract product and market

concepts is prone to creating what Maurya refers to as ‘a data-driven pattern-seeking

organization that might actually be just as bad or even worse at furthering “rationalized

dogma.”’

We can borrow from the SMART (specific, measurable, actionable, reasonable,

and time bound) goal setting theories when developing the hypothesis to avoid the

problem identified by Maurya. The hypothesis must be able to be found untrue, and the

goal of the learning exercise is to make that assessment. Sometimes, as in the Centri

Security Manager case, the mainstream customers are not on the same page, and the

faster that dichotomy can be found, the sooner a pivot in either the product or market can

be made to ensure that a strong product-to-market fit is achieved. As Blank addresses,

spending a lot of money on trying to convince customers they want a product that they

don’t believe they need is a waste that sinks many startups’ ship. The goal is to

definitively prove or disprove the hypothesis, what is learned from and changed based on

that learning can be applied to different variables within the product-to-market fit

equation.

Pivots

A primary goal of the Lean Startup models is to identify when a pivot, or a

change in direction, is necessary. That change is focused on the product-to-market fit and

business model equations, whether the change is a different target market, pricing model,

135

distribution channel, sales model, product feature, or the very nature of the product itself

or business growth and revenue models.

Just as important as understanding what a pivot is and when and how to execute

one is the understanding of what is not a pivot. A pivot is not giving up on an existing

organizational structure and tossing the core team over the fence into a new organization.

The rapid retreat is a key problem with today’s acquisition management model; making it

someone else’s problem creates the instability that contradicts the primary goal of an

organizational structure—maintain the organizational, strategy, and funding stability and

visionary oversight required for success.

A type of pivot is the transition among Horizons, as defined by Moore. During

these pivots, which really address business model changes, joint leadership between the

two Horizons must first focus on stability in the organizations—the recommendation is a

hybrid team that comes together to transfer knowledge from the lower-to-higher Horizon.

From a higher executive level, funding stability in both organizations is key. Transitions,

after the successful pivot, can then involve some sort of joint handoff without ever

affecting the team as a living organism. Enough team composition changes occur in the

normal ebb and flow of employees without creating an environment that is hostile and

ultra competitive for funding based on political favors, in which the incoming team

always fairs worse than the existing ones. Consider the example where an existing

product team’s product may be replaced by the Horizon 2 or Horizon 3 product being

transitioned. The end goal is to leverage the Horizon-specific experience and skills of the

“in place” teams to ensure that the innovation pipeline drives disruptive technologies into

each Horizon according to the relevant market maturity models so optimal competitive

differentiation and product category leadership is achieved.

136

The Large-Batch Death Spiral vs. Continuous Deployment

Few of the recommendations discussed in this thesis have the potential to

accelerate learning and accelerate customer acceptance more than avoiding what Ries

refers to as the large-batch death spiral. Startups, especially those looking over their

shoulders at competitors, whether internal business units or outside of the company, tend

to plan major releases every 6 to 12 months. As a result, the large batch of features tends

to grow while waiting for the one or two critical path features. In turn, this creeping

growth leads to longer delays in the release. One problem is that no learning about the

features that are ready occurs, and each day the release delays, the more likely it is that a

competitor will release a comparable or competitive differentiating feature. The product

stales, and the sales teams have a harder and harder time convincing prospective

customer that the product is innovative or unique.

Transitioning to as close to a continuous deployment model as possible is required

for products at all three horizons. This strategy is essential for improving product-to-

market fit and identifying the need to pivot early.

Metrics and Learning

As with product features, it is invalid to use cross product and portfolio

comparisons to evaluate the success of a disruptive technology developed by a Horizon 3

or Horizon 2 team. It is also invalid to use the metrics of standard Horizon 1 products,

which are operating in very different market maturity phases, to measure the success of

Horizon 2 and Horizon 3 efforts.

After the initial sales push (relative to the startups model) within the acquiring

company, it appears that the new product staggers and falls off in value and traction,

while what it really experiences is a false boost due to alternate sales channels, multiple

new markets, and broader exposure. The product is still not mature and rather than

137

focusing on that false drop in sales, the team should learn more about specific markets

and customer needs. A fundamental problem at this stage is the ability of the team to

scale—they cannot process the customer feedback and sales information quickly enough,

especially if they do not have a good way to collect this feedback and contact the

customers. Therefore, considerations must be made about the timing of the sales initiation

so that the infrastructure system and learning is in place to enable the team to process the

results of the sales. This scale issue argues for leaving the team in place to address their

needs on their own and to focus on what the transition between horizons means relative

to changes in sales models.

However, measuring the right trends at the right time keeps the team focused on

when to pivot and when to persevere. A tenant of the Lean Startup movement is a shift

away from the cost of acquiring metrics that have no real value or meaning, what Ries

refers to as vanity metrics. Instead, the focus should be on actionable metrics.

Funnel metrics refer to the metrics that drive the engine of growth, and in this

thesis, they have been adapted from Dave McClure’s pirate metrics (ARRR!):

• Acquisition. How do customers find you?

• Activation. Do customers have a great first experience?

• Retention. Do customers come back?

• Revenue. How do you make money?

• Referral. Do customers tell others?

However, what is being measured needs to be placed in a meaningful context. To

address this problem, Ries recommends two alternative methods of analysis: cohort

analysis and A/B split-test analysis.

Cohort analysis organizes customers into a fixed acquisition period. The results

are analyzed within a cohort and across cohorts. A/B split-test analysis refers to the

138

simultaneous comparison of two versions of the pitch, paper prototype, product feature

solutions, etc. Split testing means that the customers are randomly selected to see one

version or the other. The A version is typically the control or “as is” version, and the B

version is the one that is somehow refined.

Metrics should focus on quantitatively and qualitatively measuring what is being

learned. The funnel metrics are designed to teach about the attributes that determine a

product’s success. They validate the hypothesis, whether it relates to a product or aspects

of the business model, such as the engine of growth or revenue model. Funnel metrics

also avoid issues inherent with marketing maturity, and they provide actionable data that

allows the team to determine whether to pivot or persevere.

INNOVATION PIPELINE MANAGEMENT: CORPORATE KABAN

As defined by lean manufacturing, the kaban is a process of manufacturing or

work space organization that relies upon visual signals to control inventory. Borrowing

from the Lean Startup and Agile models, we can illustrate another strategic use of kaban,

the corporate kaban. The corporate kaban organizes a backlog of promising innovations

that can be reassessed for remaining applicable value or new ideas when a Horizon 2 or 3

project transitions. It should be mapped to the applicable crown jewels it leverages, the

Horizon it is at (1-3), and its current projection for lifetime at that horizon (in its xth year

of investment of the y projected lifetime years) It is the overinvesting and spreading too

thin of resources that prevents repeated innovation and taking advantage of top,

innovative talent. Something that must be separately addressed is the change in

compensation, and the potential issues arising from a delta in compensation of Horizon 3

team members relative to Horizon 1 and 2 teams. However, compensation must reward

139

the higher risks and taking those risks at the company rather than the lucrative startup

route.

Table 5: Sample Corporate Kaban

Projected Investment

Horizon 3 Horizon 2 Horizon 1 Exit Business

3 years (2) Project P – Crown Jewel Y (1) Project Q – Crown Jewel X (3) Project R – Crown Jewel Y

(1) Project K – Crown Jewel Z

5 years (2) Project T – Crown Jewel Y

(4) Project O – Crown Jewel Y

(4) Project L – Crown Jewel Y

(n/a) Project M – Crown Jewel X

10 years (8) Project S – Crown Jewel Z

(6) Project N – Crown Jewel X

These efforts can also be charted as Gantt charts to identify potential gaps in the

support of crown jewels so that new acquisitions or research can be started in time to

prevent such gaps from losing customers and long-term competitive advantages.

140

Figure 11: Gantt Chart Example of Corporate Kaban

The corporate kaban provides several advantages:

• Helps manage the flow and focus on transitions.

• Enforces a long-term, strategic view, highlighting the need to backfill investments

in future innovations.

• Tracks progress at a high, but hands-off, level.

• Serves as a reminder of the various investments in play, allowing for quick review

as the economic, customer, or competitive environments change.

SALES MODEL ALIGNMENT WITH STAGE

Blank and Moore state that you must align your products and your sales model.

Ries recognizes this issues as so critical that it is represented by a dedicated pivot type:

channel pivot. Clearly, Horizons 1 and 2 require different sales models. As Horizon 1

moves into highly optimized, efficient sales, there is less and less customer interaction

141

around the product. Channels become involved and sales are scaled, intentionally

optimizing out the high-touch sales. The customers know the product and its virtues; the

products have passed the tipping point and pull sales with simple sales pitches. However,

key to Horizon 3 and Horizon 2 models, face-to-face sales with the customers provide the

input to development and marketing that allows the team to develop the product and

transition into the next horizon. Different levels of decisions makers must be engaged for

Horizon 2 and 3 products to ensure that the sales go through, and it is the personal

relationships between high-touch salespeople and the customers that close the deals—a

different skillset from the high-volume sales model of Horizon 1.

Considering acquisitions, the new sales channels that the acquiring company uses

may not fit the sales model required for the product. Thus, the sale teams are not educated

about how to sell the product and the incentive structures are not in place to ensure

success. The recommendation is to retain the sales team as part of the acquisition and to

ensure that Horizon 2 and 3 sales incentive plans are structured equitably but different

from the Horizon 1 models, which are based on volume. Otherwise, there is no incentive

for the sales team to remain with the product once the acquisition is complete.

The same retention and compensation rules apply to the marketing team members

from the startup. Their understanding of the specific market and the engagement model in

driving toward the tipping point is one that is different from a Horizon 1 marketing team.

With both sales and marketing, the acquired team provides detailed understanding of the

market, the customer, the product, and the valuable communication pathways between

sales, marketing, and development, which enables the product evolutions that will be

required to reach the tipping point and transition to the next horizon.

142

INITIAL SYNC WITH EXPECTATIONS

Given the maturity of the acquired product, the desired target market segment,

and customer quality and reliability expectations of the acquiring company, management

can derive portents about required stability, expected scale, and supportability. Releasing

an immature product onto an existing customer base will result in a firestorm of support

issues and leave the startup team spinning to respond to the loudest voice of the most

valued customers and account managers. In turn, these engagements lead to the

additional feature support demands that these customers have come to expect from the

company’s Horizon 1 products. Overall, premature release is a recipe for immediately

biasing the sales organizations against the product and losing face with existing

customers. For the newly acquired team, it creates a vicious juggling act among bug

fixing, new feature development, and critical customer account support. In short, it leaves

a bad impression on everyone involved.

The expectations that customers have of the acquiring company’s products differ

greatly from those that they hold for a startup. Before the acquiring company begins

selling a product under its own name, some basic work must be performed to address the

change in expectations that will result from the simple brand change. The founders of the

startup need to communicate a message to their early adopter customers that a 6-month

delay can be expected in the roadmap due to the acquisition, but that the value to them

will be a product of higher quality code, improved depth of product testing, and

additional customer support resources.

The startup team can continue designing next generation features and, depending

on the size of the team, some efforts can continue on a separate code branch. However, a

focused effort must be placed on shoring up the product. This effort includes temporarily

halting sales to any companies not in the startup’s pipeline. The assumption should be

143

that the “as bought” product is the minimum viable product and clear expectations of

passing a series of quality hurdle tests before sales resume must be communicated to the

startup team and to the sales channels of the acquiring company. If possible the

expectations should be communicated and the effort started during the closing period.

Ideally, it would be a condition to be addressed prior to closing; however, that strategy

could expose the company to some risk and would increase the startup’s valuation, a

premium its investors would demand.

This initial sync effort should bring the existing product in line with the

customer’s expectations in the lab. Quality expectations to define include product

maturity, scale, supportability, and how customers might use the product.

And just as important, the acquiring company’s sales channel and partners should

not sell the product until the quality hurdle tests pass, and any evaluations should be

limited to those initiated by the startup team and clear expectations set regarding the

current alignment effort. As an example, a networking company should test quality,

scalability, and reliability by brining a product into a central lab and test it using the

traffic profiles, device load, security penetration, static code analysis, and load test

harnesses used for mature products and solutions.

Once the MVP’s quality is aligned with your customer’s expectations in the lab,

then shipping can resume to startup’s existing pipeline. However, shipping into other

segments should remain delayed until any interoperability hurdle tests are completed. As

an example, in an acquiring networking company, customers expect at a minimum, that

the products interoperate without issue with a core set of existing devices from the same

company. Interoperate does not mean integrate with; it means to co-exist peacefully and

without issue. This effort may require support from existing product teams, and it should

be prioritized as a first example of their commitment to the newly acquired team

144

illustrating acceptance and support of new ideas by the established lines of business.

Ideally, sales should focus only on the target market segment. However, once the

interoperability hurdle tests pass, then the existing sales force and channel sales can begin

selling the product to help assess other segments where the product might fit. At this

point, the startup team can begin engaging in targeted sales to define the requirements of

any new segment.

While this quality and interoperability testing is being performed, a separate effort

should develop the sales collateral and training material. Once the hurdles are passed, an

internal launch event should take place where the product and collateral is made available

to the internal sales teams and partners. A 6-12 month product roadmap is still unlikely to

include anything beyond the startup team’s initial vision, and that line should be defended

as they begin to orient themselves within the company. Remember, they must find their

own way.

FINANCING MODEL

In Escape Velocity, Moore presents models to shift execution so as to guarantee

the funding of Horizon 2 efforts. These models require reframing the way innovation is

organized, staffed, and funded within an existing company. However, the focus of Escape

Velocity is on Horizon 2 efforts, despite providing a strong framework for Horizon 3. In

the high-tech arena, most startups are acquired in the Horizon 3 phase, relative to the

existing developments within the acquiring company.

Some startups presents new ways of addressing problems that are so radical

compared to the mainstream solutions that market timing becomes an issue. Whatever

unique challenges or opportunities the startup’s innovation may offer, executive

leadership must reframe its expectations around the horizon for ROI, understanding that

145

ROI depends greatly on team retention, corporate engagement and integration, and

commitment.

What a company acquires is a functional team, early market entrance, intellectual

property, and some beta code/hardware. It does not acquire a fully operational, mature

product that is ready to take on all of the company’s customers across all segments. It is

neither a Horizon 1 nor an early Horizon 2 effort. Therefore, the funding model must be

long term, and it must consider a realistic product maturity model relative to the acquired

team. It is an investment in the future. It is unrealistic to expect market leadership in

immature markets with immature products. The company should expect to invest for a

minimum of five to seven years so that stability can enable slowed integration and

success of the innovation.

When assessing the initial investment timeline, consider the product a minimum

viable product and what that means (see “Initial Sync with Expectations”). The company

must also consider future investments at Horizon 2, such as customer acquisition and

marketing costs, especially if the startup did not focus on the desired market segment of

the acquiring company. Consider the market type of the startup (Blank, pp. 24-26) from

both the existing segment and the target segment and the cost of repositioning it. And just

as important as product maturity is market maturity. If the company has truly acquired an

innovative technology, one can assume the market is in the early phases of adoption, not

in the mature or declining periods of growth. As such, the company should make

reasonable expectations, such as to become profitable due to support from its sales

organizations, but it should not anticipate huge returns before the market matures. The

company must continue to analyze market maturity models.

There must also be a yearly re-evaluation of the market. As Moore describes, new

competitors and technologies can obsolete Horizon 1, 2, and 3 investments overnight.

146

Portfolio management requires evaluating the competitive landscape and responses.

Retaining core startup teams will be key to rapid responses and repurposing of the

innovations or simply driving them into existing product lines as “incremental

innovation” as a response to external changes in the market. The company must analyze

the market maturity before defunding an innovation and team. If the market is mature or

other environmental changes make defunding necessary, then the strategy should be to

return to the Innovation Pipeline Management: Corporate Kaban and transition the team

to the next priority innovation effort.

Expected Spending

Moore recommends separate organizational placement and dedicated budgets,

prioritized toward Horizon 2. It represents an “all in” philosophy where management is

declaring that success is mandatory. However, when performing relative comparisons

within a portfolio, portfolio managers often loose the perspective of the investment

because of what appears to be a small return relative to the overall investment. Because

of the way companies are structured, companies often combine expensive messaging and

support cost structures, as well as capital expenditures, across the entire portfolio.

Tracking actual consumption of resources becomes difficult.

Often, large companies use internal billing to exchange money between well-

funded units. For example, support calls may cost a product team $400 per call, which is

reasonable for large, complex systems that huge revenues commensurate with market

maturity. However, it does not/should not apply to small internal startups whose typical

call is 5 minutes or passed directly to the team to address. These funny money exchanges

can quickly hide any growth in sales or potential future earnings, which can lead to

premature defunding of the innovation based on false costs. Real costs are important, and

147

support work may be better funded by the internal team and addressed using internal

teams to ensure that learning is improved rather than trying to integrate into the broader

cost structures prematurely.

Last, there is a true failure to realize the cost of work rather than the cost of labor.

How much does it cost to develop a product or technology that can generate billions of

dollars and sustain your company’s top-line growth for 10 years? The company must

consider the costs of licensing similar technology over 10 years or acquiring the current

market leader (a Horizon 1, most likely), the value it can have on profit margins, etc. The

costs of developing a technology are often down in the weeds when working on Horizon

3 efforts, and the sudden change in cost as the technology transitions to Horizon 2 is

where most efforts are halted. Staying focused on the drive to hit the tipping point and

accepting that market penetration, especially if the products are in a competitive market,

comes at an expense. The elegance of the “all in” philosophy proposed by Moore is that

the company leadership has to decide strategically where the company needs to be, agree

upon that future with the board, and then invest in getting there as though company’s

future depends on it. And it does.

False Growth

From the outset, companies must reset growth expectations around startup

technologies until they transition from Horizon 2 to Horizon 1. The hockey stick growth

from immature products is the strategy that many follow today to EOL innovative new

products within two years. Products often experience false indicators or this type of

growth when they are first acquired and dropped into the existing sales channels because

existing customers have read about the acquisition and ask questions about it. It seems

logical to ride that wave of free advertisement; however, as soon as the startup’s product

148

fails to meet the expectations of existing enterprise-class customers, the sales drop off.

This issue is addressed in “Initial Sync with Expectations.”

A combination of Moore’s Horizon 3 and Jolly’s technology development models

(Jolly, 1997), overlain by Blank and Reis models dictates slow growth (and increased

spending) until the product hits a certain level of maturity, which in this case is the

stability, scalability, feature richness, and customer awareness required to reach the

tipping point. Then, support from the Horizon 1 teams can take a transitioned product and

run with the lower customer acquisition costs and higher volume growth.

The team must remain aware of where they really are within the Jolly model.

Despite all of the other models, including the Lean Startup Model, there is a linear

progression that should be followed. All of these other models may repeat within or

improve the methods of a specific stage, but the Jolly model is the migration through the

full lifecycle. A transition from Horizon 3 to Horizon 2 and then to Horizon 1 is

predicated upon completing this cycle. Being aware of where a technology investment is

within the model’s stages helps to shape the company’s thinking, its understanding of the

next stage, and that stage’s stakeholders. It also helps to set the expectations of others,

and it should be used as a metric to illustrate the progression through product maturity

relative to market maturity.

149

Conclusions

The long-term viability of a software technology company depends on

establishing and nurturing a Three Horizon innovation pipeline that produces disruptive

innovations and enables competitive differentiation. Acquiring startups is a viable

method for seeding this pipeline, obtaining innovative teams, and bringing fresh thinking

and perspectives to the company. However, long-term success and return on investment

depends more on preserving the core teams of those startups than the technologies they

initially bring with them.

KEY TAKEAWAYS

Considering the transition of a startup into the acquiring company is as important

as the decision to buy innovation rather than develop it from within. This thesis

demonstrated how, despite great resiliency and innovativeness, a core team can wither in

an unstable organization and without strong, long-term executive sponsorship and

funding. Once a good startup-to-company fit is found and the acquisition complete, that

executive sponsor must understand the organic nature of team composition and support

an integration and engagement model that maintains the team’s internal vision and

rhythm. A stable environment that enables the stages of development and sales strategy

relative to market maturity and market stage as defined by Moore’s Three Horizon model

is key to increasing the return on the startup investment.

CONTRIBUTIONS

The following guidance and models contribute to discussion on preserving

innovative core teams inside of acquiring companies:

150

• Purchase Motivation. Both the acquiring company and startup need to

understand the motivations and intentions behind the acquisition to gauge

the startup-to-company fit.

• Core Team Growth and Retention. Understanding teams, their organic

more-than-the sum intelligence, their history, and how the satisfying roles

at startups differ from those defined inside large companies can lead to

changes that make for a soft landing inside an acquiring company for

startup teams.

• The Inverse Effort-Based Model. Today’s model, where internal teams that

failed to innovate internally are driving requirements and the direction of

new acquisitions, is fundamentally broken. Instead, executive leadership

should dictate that startups drive requirements and direction into existing

products to increase the value of those products relative to the vision and

direction of the startup’s visionary. Acquired teams should engage only

where they see value relative to their innovations and longer-term vision.

• The Three Horizon Corporate Kaban. Borrowing from lean manufacturing

and Agile development, the Corporate Kaban simplifies the management

of the innovation pipeline and clearly identifies required transitions across

all three horizons.

FURTHER AREAS OF STUDY

In the course of writing this thesis, the following areas of study were identified as

needing further research:

151

• Evolution of Valid Metrics Across the Three Horizons. Clearly defining

metrics for each horizon and how and when they transition can simplify

those stages.

• Composing Hybrid Teams that Foster Successful Horizon Transitions.

Hybrid teams, composed of members from adjacent horizons, are

necessary for smooth product transitions. Timing the integration of new

members and extraction of others should be structured according to

specific milestones in market and product maturity, as well as sales

traction.

• How Horizon-based Teams Evolve. The question of how long a team can

be repurposed at a given horizon level before (or whether) they naturally

evolve into a team that operates best at the adjacent horizon is one for

further study.

• Compensation Models for Horizon 1, 2 and 3 Teams Relative to Risk and

Market Pressures. Pay and reward of Horizon 3 and Horizon 2 teams must

be commensurate with the industry trends found in pure startups to offset

the risk, low volume of sales, and required skillset that is not found at

Horizon 1. Addressing this issue is key to ensuring that core team

members do not follow the money to Horizon 1.

In closing, the central message is that the value of an acquisition is in the core

team and its ability to innovate over and over again. An acquisition decision should focus

entirely on the team, its intelligence and dynamics, and whether it has the ability to

repeatedly innovate. Once identified, success can be measured as the acquiring

company’s ability to retain and refocus that team to keep the innovation pipeline flowing.

152

Appendices

PRESS RELEASE: CISCO SYSTEMS TO ACQUIRE GLOBAL INTERNET SOFTWARE GROUP, INVESTS IN PARENT COMPANY GLOBAL INTERNET.COM

Windows NT Firewall Expertise to Complement Cisco's PIX Firewall Offerings

SAN JOSE, Calif. June 24, 1997 Cisco Systems, Inc. today announced it has signed a definitive agreement to acquire Global Internet Software Group, a wholly owned subsidiary of Global Internet.Com Inc. based in Palo Alto, CA. Cisco is also taking an undisclosed minority equity interest in Global Internet.Com. Global Internet Software is a pioneer in the Windows NT network security marketplace.

Under the terms of the acquisition, approximately $40.25 million cash will be exchanged for all outstanding shares of Global Internet Software. In connection with the acquisition, Cisco expects a one-time charge against after-tax earnings of between 2 and 3 cents per share in the fourth fiscal quarter of 1997. The acquisition has received all required approvals from each company and is expected to be completed by late-July subject to various closing conditions including approval under the Hart Scott Rodino Antitrust Improvements act.

Cisco Now Covers Multiple Areas in the Firewall Marketplace

Firewalls are fast becoming a necessity, as growing numbers of businesses open up their networks to Internet traffic for networked commerce, training and networked information exchange. To complement Cisco’s enterprise-class PIX firewall, today's acquisition of Global Internet Software and its Centri Security Manager Windows NT firewall is designed to meet the turnkey needs of small and medium businesses who are often without security engineers to design, build and support their networks offerings.

Global Internet's Windows NT management software will allow network administrators to simply install the firewall in minutes with step-by-step instructions and help the user determine appropriate security policies. Cisco is continuing to extend its product offerings as the leading provider of networking for the Internet with a wide range of network-aware software, hardware and appliances to protect networks from unauthorized intruders.

Upon completion of this acquisition, Cisco will be able to deliver a Windows NT network firewall suite capable of examining credentials including names, applications, Internet Protocol (IP) addresses and other inquiry characteristics against access rules programmed by the systems administrator. In addition, Cisco

153

users will be able to leverage Global Internet.Com's expertise in network integration, design, security, consulting and management services. In conjunction with todays announcement, a Cisco executive will also retain a seat on Global Internet.Com's Board of Directors.

The approximately 20 employees of the Global Internet Software development team will continue to work out of two locations, the SF Bay area and a remote office in Champaign, IL. All employees will become part of the Internet Appliances and Applications Business Unit headed by Vice President and General Manager Christine Hemrick within Cisco's Small/Medium Business line of business.

About Global Internet Software Group

Global Internet Software Group specializes in security solutions for Microsoft Windows NT networks. Parent company Global Internet.Com, whose principal investor is New York-based Welsh, Carson, Anderson and Stowe, builds, manages and secures corporate networks with a focus on medium-size business. athttp://www.globalinternet.com, http://www.centri.com or by calling (800) 682-5550.

About Cisco Systems

Cisco Systems, Inc. (NASDAQ:CSCO) is the worldwide leader in networking for the Internet. at http://www.cisco.com.

154

PRESS RELEASE: GLOBAL INTERNET, V-ONE AGREE TO SHARE RESELLER CHANNELS

V-ONE selects Global Internet's Centri as Windows NT firewall of choice PALO ALTO, Calif.--(BUSINESS WIRE)--March 24, 1997--Global Internet Software Group Inc., a leader in Microsoft(R) windows NT(TM) security, today announced an agreement with V One Corp , developers of "gate" technology for secure business over open networks. The agreement allows Global Internet and V-ONE to use each other's reseller and direct sales force, increasing the channel reach of both companies. V-ONE will immediately begin selling global Internet's Centri Security Manager product line through its international direct sales force. Global Internet will offer V-ONE products including SmartGate 2.2, an intelligent software "gate" with integrated encryption and token-based authentication that will interoperate with Centri products to provide additional security, through its nationwide network of value added resellers (VARs). "Global Internet's agreement with V-ONE provides Centri customers with additional ease-of-use features, like remote user authentication and session encryption using a choice of hardware and software tokens and digital certificates," said Phil Marson, vice president of sales and marketing, Global Internet. "We broaden our line domestically, and V-ONE helps make the Centri product line more readily available in Europe and Asia." Global Internet's Centri firewall product line easily integrates with V-ONE's intelligent "gate" technology, SmartGate 2.2. V-ONE has selected the Centri product line as its Windows NT firewall of choice. "We feel that Global Internet's product line offers significant advantages over competitive products in the NT market," said James F. Chen, president and CEO, V-ONE. "With Centri's superior architecture, seamless integration on the NT platform and protection against Java and ActiveX applets, the product line was a logical choice for us to offer our customers." Centri Security Manager software makes use of Global Internet's proprietary Kernel Proxy(TM) architecture, which provides the security of an application-proxy firewall with the performance of a packet filter. For more information on Global Internet and its products, customers can call Global Internet at 800/682-5550, e-mail [email protected] or visit the World Wide Web at http://www.globalinternet.com/.

155

Global Internet Software Group specializes in security software and is a wholly owned subsidiary of Global Internet.Com Inc., a Palo Alto, Calif.-based full-service internetwork solutions company. V-ONE Corp. licenses SmartGate, an intelligent software "gate" that enables organizations to establish secure communications and transaction channels over public networks like the Internet. Major financial institutions, sensitive government agencies and large health care concerns use SmartGate for its integrated authentication, encryption and access control options. SmartGate tightly manages controlled users accessing sensitive data without changing an organization's existing firewalls, applications and network architecture. V-ONE is headquartered in Rockville, Md. Product and security information, white papers and V-ONE's latest news releases may be accessed via the company's World Wide Web site at http://www.v-one.com/. Microsoft is a registered trademark and Windows NT is a trademark of Microsoft Corp. Kernel Proxy is a trademark of Global Internet Software Group Inc. CONTACT: The Bohle Company

Wendy Allen, 310/785-0515 ext. 242 [email protected] Erik Jameson, 310/785-0515 ext. 229 [email protected]

156

PRESS RELEASE: GLOBAL INTERNET INTRODUCES WINDOWS NT FIREWALL FOR COMPANIES WHO WANT SECURITY, LACK ON-STAFF SPECIALIST; AVAILABLE THROUGH MAJOR DISTRIBUTION OUTLETS NATIONWIDE.

PALO ALTO, Calif.--(BUSINESS WIRE)--March 3, 1997--Global Internet Software Group Inc., a leader in Microsoft Windows NT security, today announced Centri Bronze, a Windows NT firewall with innovative ease-of-use features that eliminate the need for in-house security experts

Global Internet's new integrated product consists of a firewall, security manager and network monitoring system in one shrink-wrapped package available through distributor outlets and Global Internet resellers nationwide. The product provides pre-defined security policies, supports popular network applications and is available at a moderate price point: $2,995.

Centri Bronze is the perfect solution for small- and mid-sized companies, departments and branch offices.

"Most companies don't have security engineers to design, build and support their networks," Mark R. Kriss, president of Global Internet Software Group, said. "Now, with Centri Bronze, any Windows NT network administrator can easily install the product and enjoy all the benefits of a secure, high-performance firewall with automated monitoring features."

Centri Bronze was designed by Windows NT networking experts with access to key portions of the Microsoft Windows NT TCP/IP source code. Global Internet is the only firewall developer with access to this code.

A New Standard in Usability for Windows NT Firewalls

Centri Bronze's innovative ease-of-use features eliminate the need for a security expert willing to wade through long lists of arcane router rules, which is necessary with today's firewalls, including proxy firewalls, stateful inspection firewalls and firewall routers.

Centri Bronze loads in minutes and requires no special training or programming experience. Installation and security policy decisions are simplified with intuitive wizards that walk the user through the process step-by-step and help the user determine appropriate policies. The product comes with out-of-box support for common network applications and services including: Microsoft Internet Explorer, Netscape Navigator, Lotus

157

cc:Mail, Lotus Notes, RealAudio, Microsoft Exchange, VDOLive, NetMeeting, CoolTalk, FTP and Telnet.

Centri Bronze's Windows NT graphical user interface incorporates a Natural Network Viewer that makes network management as simple as Windows file management. And Centri's innovative Policy Builder presents complex security policies in an easily understood, intuitive flow-chart or decision-tree fashion. Global Internet's Policy Builder also explains policies in Secure Script, a unique policy language based on plain English.

Security policies can be easily applied in a drag-and-drop manner to any user or group within any Windows NT domain.

New Kernel Proxy Architecture for Superior Security and Performance

Centri Bronze is designed around a multi-layer "Kernel Proxy" architecture. This revolutionary new architecture combines the high-level security of an application proxy and the speed of a packet filter.

Global Internet's new Kernel Proxy architecture, which sets a standard for performance among firewalls, also makes it possible to securely run third-party applications such as Web and E-mail servers on the same PC server -- something that isn't possible with conventional firewalls. This eliminates the expense of purchasing and maintaining multiple machines for Internet and intranet gateways.

Centri Bronze also offers real-time notification of unusual network activity, scheduled or on-demand Web-based reports, high- speed Web caching, on-the-fly network address translation and URL filtering.

Availability Centri Bronze is part of Global Internet's new Centri Security Manager product line, which is designed to meet varying levels of network security needs. Each product in the line, including Centri Bronze, offers easy, one-step upgrades with a new software key to unlock more advanced features. Also, pricing is based on functionality, not network size. Now users pay only for the features they use. Centri Bronze has a suggested list price of $2,995 for unlimited users. A free demo of Centri Bronze is available on Global Internet's Web site. The product can be purchased through Ingram Micro and MicroAge distribution outlets nationwide and Global Internet Certified Resellers. A free 30-day trial is also available.

158

For more information, call Global Internet at 800/682-5550, e-mail [email protected], or visit the World Wide Web at http://www.globalinternet.com/centri . Global Internet Software Group specializes in security software for Microsoft Windows NT networks. Global Internet Software Group Inc. is a wholly owned subsidiary of Global Internet.Com Inc., a Palo Alto-based full-service internetwork solutions company. -0- Note to Editors: Centri Bronze, Centri Policy Builder, Secure Script and Kernel Proxy are trademarks of Global Internet.Com Inc. Microsoft is a registered trademark and Windows NT is a trademark of Microsoft Corp. CONTACT: The Bohle Company Taunya Terry, 310/785-0515 ext. 207 [email protected] Laura Kaempen, 310/785-0515 ext. 212 [email protected]

159

PRESS RELEASE: CISCO INTRODUCES WINDOWS-NT FIREWALL PRODUCT; EASY-TO-USE CISCO CENTRI FIREWALL TARGETS SMALL/MEDIUM BUSINESSES.

SAN JOSE, Calif.--(BUSINESS WIRE)--Aug. 26, 1997--Cisco Systems, Inc. (NASDAQ:CSCO) today announced the Centri Firewall, a security solution for small and medium-sized businesses. The Windows NT-based Centri Firewall version 4.0 -- designed to provide an affordable, secure connection to the Internet and protect organizations from increased security risks -- is easy to use and administer. "Cisco is committed to enabling small to medium businesses to take advantage of the full business potential of the Internet," said Christine Hemrick, vice president and general manager of the Internet Appliances and Applications Business Unit at Cisco Systems. "By offering the Windows NT-based Centri Firewall, Cisco is providing a powerful, yet easy-to-use security element." The Centri Firewall provides security with a user- friendly graphical user interface and can be set up and administered without an onsite security expert. An Installation Wizard walks the network administrator through the installation and initial setup within 20 minutes.

The Centri Firewall includes the Natural Network Viewer and Policy Builder features that simplify security policy setting by allowing security policies to be applied to NT domains, users, groups, individual machines, or to groups of machines residing in defined physical or logical networks.

It also comes with preconfigured support for popular network applications and services, including transparent support for all common TCP/IP applications, such as WWW, File Transfer Protocol (FTP), Telnet and Mail. In addition to these out-of-box services, the Centri Firewall allows safe and easy customized support for any network application or service, such as Web, electronic mail and DNS servers.

These applications and services can reside on the same Windows NT system, allowing a small or medium-sized business to reduce the cost of securely connecting to the Internet.

The Centri Firewall is based on the unique Kernel Proxy architecture that provides strong security and high performance by intercepting network traffic at the kernel level of the Windows NT operating system. This capability protects the firewall from vulnerabilities.

160

Additional standard features include ActiveX, Java applet, JavaScript, VBscript and URL blocking; port address translation; network address translation; proxy security services for Web, Telnet, and FTP; and support for multimedia applications including RealAudio, NetMeeting, CoolTalk, H.323 and VDOLive.

The Cisco Centri Firewall extends Cisco's firewall product line, which currently includes the Cisco PIX Firewall, a leading enterprise security solution. In the future, features of the easy-to-use Centri graphical user interface will be incorporated across the Cisco firewall product line.

Pricing and Availability

The Cisco Centri Firewall will be available September 1, 1997 through Cisco Connection Online (CCO), distributors and VARs. The Centri Firewall is sold based on the number of network users. Three user levels are available: 100, 250 and unrestricted users. For a 100-user solution, the price is $3,495; for 250 users, the price is $4,995 and for an unrestricted number of users, the price is $7,495.

The unrestricted license for the Centri Firewall is recommended for sites with up to 500 users; it is not an unlimited user license. A localized version for the Japanese market will be available in the fourth quarter of 1997.

Cisco Systems (NASDAQ:CSCO) is the worldwide leader in networking for the Internet. News and information are available at http://www.cisco.com . -0-

Note to Editors: Centri, Cisco IOS, Kernel Proxy, Natural Network Viewer, PIX and Policy Builder are trademarks, and Cisco, Cisco Systems and the Cisco Systems logo are registered trademarks of Cisco Systems, Inc. in the United States and certain other countries. All other trademarks, mentioned in this document are the property of their respective owners.

CONTACT: Cunningham Communication, Inc. (for Cisco Systems, Inc.)

Jennifer Jennings, 650/858-3778

[email protected]

161

Bibliography/References

Adams, Rob. A Good Hard Kick in the Ass: Basic Training for Entrepreneurs. New

York: Crown Business, 2002. Print. Blank, Steven Gary. The Four Steps to the Epiphany Successful Strategies for Products

That Win. S. L.: Cafepress, 2007. Print. Bryant, Martin. "The Startup Genome Report Turns Entrepreneurship into a Science."

Entrepreneur. The Next Web, 28 May 2011. Web. 19 Nov. 2011. <http://thenextweb.com/entrepreneur/2011/05/28/the-startup-genome-report-turns-entrepreneurship-into-a-science/?all=1>.

Council on Competitiveness. Competitiveness Index: Where America Stands. http://www.compete.org/ United States, 2007. PDF.

Christensen, Clayton M. The Innovator's Dilemma: When New Technologies Cause Great Firms to Fail. Boston, MA: Harvard Business School, 1997. Print.

Dodge, Don. "Acquisition Success Depends on Founders." Don Dodge on The Next Big Thing. 6 Sept. 2011. Web. 19 Nov. 2011. <http://dondodge.typepad.com/the_next_big_thing/2011/09/acquisition-success-depends-on-founders.html>.

Drucker, Peter F. Innovation and Entrepreneurship: Practice and Principles. New York: Harper & Row, 1985. Print.

Estrin, Judy. Closing the Innovation Gap: Reigniting the Spark of Creativity in a Global Economy. New York: McGraw-Hill, 2008a. Print.

Estrin, Judy. "Innovation: Crucial to Our Future." The Huffington Post. 3 Sept. 2008b. Web. 17 Nov. 2011. <http://www.huffingtonpost.com/judy-estrin/innovation-crucial-to-our_b_123556.html>.

Fisher, Lauren. "Just How Many Failed Startups Can Google Afford? – Simply Zesty - Simply Zesty." Simply Zesty. Simply Zesty, 25 June 2011. Web. 19 Nov. 2011. <http://www.simplyzesty.com/google/22176/>.

Fryer, Bronwyn. "How Do Innovators Think?" HBR Blog Network - Harvard Business Review. Harvard Business Review, 28 Sept. 2009. Web. 05 Nov. 2011. <http://blogs.hbr.org/hbr/hbreditors/2009/09/how_do_innovators_think.html>.

Gayle, Marc. "What Happens after Yahoo Acquires You - (37signals)." Signal vs. Noise. 37 Signals, 22 Feb. 2011. Web. 19 Nov. 2011. <http://37signals.com/svn/posts/2777-what-happens-after-yahoo-acquires-you>.

162

Graham, Paul and Evelyn Rusli. Y’Combinator’s Paul Graham On Changing Strategies. TechCrunchTV Interview. TechCrunch, 30 July 2010. Web. 1 June 2011. <http://www.techcrunch.tv/watch?id=Jnb3NsMTrCZA-VZmyF2TrCZiUhUyqvL9#ooid=Jnb3NsMTrCZA-VZmyF2TrCZiUhUyqvL9>

Gitelson, Gene, John W. Bing, and Lionel Laroche. "The Impact of Culture on Mergers & Acquisitions." ITAP International. ITAP International, Mar. 2001. Web. 19 Nov. 2011. <http://www.itapintl.com/facultyandresources/articlelibrarymain/the-impact-of-culture-on-mergers-a-acquisitions.html>.

Herrmann, Bjoern L. "What the Fortune 1000 Can Learn from the Startup Genome Project - Startup Genome." Startup Genome. Blackbox.vc, 15 Sept. 2011. Web. 17 Nov. 2011. <http://startupgenome.cc/what-the-fortune-1000-can-learn-from-the-star>.

Holthausen, Robert W. "Mergers and Acquisitions Program at Wharton: M&A Solutions for Successful Strategies." Executive Education Programs at Wharton: Premier Executive Education. Wharton School of Business, 2011. Web. 19 Nov. 2011. <http://executiveeducation.wharton.upenn.edu/open-enrollment/finance-programs/mergers-acquisitions-program.cfm>.

Huber, George P., and Kyle Lewis. "Cross-understanding: Implications for Group Cognition and Performance." Academy of Management Review 35.1 (2010): 6-26. Print.

Ingram, Mathew. "Why Most Startup Acquisitions Fail, and Always Will — Tech News and Analysis." GigaOM — Tech News, Analysis and Trends. GigaOM, 23 Feb. 2011. Web. 19 Nov. 2011. <http://gigaom.com/2011/02/23/why-most-startup-acquisitions-fail-and-always-will/>.

"Intercultural Synergy in Mergers and Acquisitions." Kwintessential. Kwintessential Ltd, 2011. Web. 18 Nov. 2011. <http://www.kwintessential.co.uk/cultural-services/articles/intercultural-mergers.html>.

Jolly, Vijay K. Commercializing New Technologies: Getting from Mind to Market. Boston, MA: Harvard Business School, 1997. Print.

Lewis, Kyle. "Measuring Transactive Memory Systems in the Field: Scale Development and Validation." Journal of Applied Psychology 88.4 (2003): 587-604. Print.

Lewis, Kyle, Maura Belliveau, Benjamin Herndon, and Joshua Keller. "Group Cognition, Membership Change, and Performance: Investigating the Benefits and Detriments of Collective Knowledge." Organizational Behavior and Human Decision Processes 103.2 (2007): 159-78. Print.

Marmer, Max, Bjoern L. Hermann, and Ron Berman. "Startup Genome Report 01: A New Framework for Understanding Why Startups Succeed." Startup Genome. BlackBox.vc, 28 May 2011. Web. 1 June 2011. <http://startupgenome.cc/pages/startup-genome-report-1>.

163

Maurya, Ash. Running Lean: A Systematic Process for Iterating Your Web Application from Plan A to a Plan That Works. Austin: Ash Maurya, 2010. PDF.

Moore, Geoffrey A. Crossing the Chasm: Marketing and Selling Disruptive Products to Mainstream Customers. New York, NY: HarperBusiness Essentials, 2002. Print.

Moore, Geoffrey A. Dealing with Darwin: How Great Companies Innovate at Every Phase of Their Evolution. New York: Portfolio, 2005. Print.

Moore, Geoffrey A. Escape Velocity: Free Your Company's Future from the Pull of the past. New York, NY: HarperBusiness, 2011. Print.

Moore, Geoffrey A. "To Succeed in the Long Term, Focus on the Middle Term." Harvard Business Review (2007). Print.

Moreland, R. L. (1999). Transactive memory: learning who knows what in work groups and organizations. In L. L. Thompson, J. M. Levine, & D. M. Messick (Eds.), Shared cognition in organizations: The management of knowledge (pp. 3–31). Mahwah, NJ: Erlbaum.

Moreland, R. L., & Argote, L. (2003). Transactive memory in dynamic organizations. In R. Peterson & E. Mannix (Eds.), Understanding the dynamic organization (pp. 135–162). Mahwah, NJ: Erlbaum.

Reese, Brad. "Palo Alto Networks Is the Culprit behind Cisco's -8.4% FY11 Security Sales Decline - Brad Reese." BradReese.Com. BradReese.Com, 22 Aug. 2011. Web. 21 Nov. 2011. <http://bradreese.com/blog/8-12-2011.htm>.

Ries, Eric. The Lean Startup: How Today’s Entrepreneurs Use Continues Innovation to Create a Radically Successful Business. New York: Crown Business, 2011. Print.

Robinson, Ken, and Lou Aronica. The Element: How Finding Your Passion Changes Everything. New York: Viking, 2009. Print.

Siegenthaler, Paul J. "Ten Reasons Mergers and Acquisitions Fail - Telegraph."Telegraph.co.uk. Telegraph, 3 Aug. 2010. Web. 19 Nov. 2011. <http://www.telegraph.co.uk/finance/businessclub/7924100/Ten-reasons-mergers-and-acquisitions-fail.html>.

Stuck, B., and M. Weingarten. "How Venture Capital Thwarts Innovation." IEEE Spectrum 42.4 (2005): 50-55. Print.

Wilson, Tim. "SIEM Market To Double By 2015, Report Says - Dark Reading." Dark Reading: Security. UBM TechWeb, 21 Mar. 2011. Web. 08 Nov. 2011. <http://www.darkreading.com/security-monitoring/167901086/security/security-management/229301368/siem-market-to-double-by-2015-report-says.html>.

164

Vita

Robert Blaine McNutt has worked for multiple high-tech startups and was a

member of the core team at Blue Ridge Software, Inc. and at Global Internet Software,

Inc., which was acquired by Cisco Systems, Inc. in 1997. He has worked as a writer and

manager at Cisco Systems, where he currently works as a program manager.

E-mail address: rbmcnutt [at] gmail.com

This thesis was typed by Robert Blaine McNutt.

Date post:	14-Mar-2022
Category:	Documents
Upload:	others
View:	4 times
Download:	0 times

Copyright by Robert Blaine McNutt 2011

Documents