copyright by robert blaine mcnutt 2011
TRANSCRIPT
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
Innovation Restrained: Unlocking the Innovation of Acquired Software Startups
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
Innovation Restrained: Unlocking the Innovation of Acquired Software Startups
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.
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.
Applicable Stage or Model Activity
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.
Applicable Stage or Model Activity
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.
Applicable Stage or Model Activity
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.
Applicable Stage or Model Activity
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.
Applicable Stage or Model Activity
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.
Applicable Stage or Model Activity
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.
Applicable Stage or Model Activity
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.
Transition Highlights
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
Analysis of Transitions and Issues
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.
Applicable Stage or Model Activity
Customer Development Framework (Blank)
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.
Applicable Stage or Model Activity
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.
Lean Startup Framework (Ries)
Validated learning The secrecy of the team prevented any validated
learning.
Falsifiable hypothesis None.
60
Table 2, cont.
Applicable Stage or Model Activity
Build-Measure-Learn Feedback
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.
Applicable Stage or Model Activity
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.
Applicable Stage or Model Activity
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.
Hierarchy of Powers Framework (Moore)
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.
Applicable Stage or Model Activity
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.
Applicable Stage or Model Activity
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.
Applicable Stage or Model Activity
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.
Applicable Stage or Model Activity
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.
Applicable Stage or Model Activity
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.
Applicable Stage or Model Activity
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.
Transition Highlights
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
Analysis of Transitions and Issues
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.
Applicable Stage or Model Activity
Customer Development Framework (Blank)
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.
Applicable Stage or Model Activity
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.
Lean Startup Framework (Ries)
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.
Applicable Stage or Model Activity
Build-Measure-Learn Feedback
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.
Applicable Stage or Model Activity
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.
Applicable Stage or Model Activity
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.
Applicable Stage or Model Activity
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
Hierarchy of Powers Framework (Moore)
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.
Applicable Stage or Model Activity
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.
Applicable Stage or Model Activity
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.
Applicable Stage or Model Activity
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.
Applicable Stage or Model Activity
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.
Applicable Stage or Model Activity
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.
Applicable Stage or Model Activity
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.
Applicable Stage or Model Activity
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.
Applicable Stage or Model Activity
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
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.