My previous post in the corporate venture capital (CVC) series provided a broad historical perspective on the sector. In this post I review important lessons learned by CVCs that have been operating for many years and several economic cycles and best practices being used by newer CVCs. The lessons in this post would be of value to CVCs looking for best practices and corporate leaders whose companies have already established venture organizations or are considering doing so as part of enabling innovation.
In the previous post I introduced a five-dimensional framework to employ while setting up a corporate venture group and discussed in detail two of its dimensions: strategy and people. The corporation must establish a long-term strategy for its venture group. As part of this strategy it must create a set of objectives, formulate an investment thesis, decide on the stage of the target investments, the life of each fund, and the amount per investment. Recognizing that venture investing is a peoples business, the CVC must pay particular attention in hiring well. A CVC group may have up to six different teams depending on the scope of its activities and overall strategy. Next I will present the three additional dimensions: the incentives to offer to the members of the corporate venture group, generating the right deal flow to achieve the group’s strategy and satisfy its investment theses, and guidelines for the CVC group’s governance.
In the first part of the series on corporate venture capital I explored how the disruption of institutional VCs (IVCs) and the imperative for corporations to innovate provide an opportunity to corporate VCs (CVCs) to make their mark in the startup ecosystem and be viewed as viable and valuable financing sources to private companies. In the second part I provided more context on CVCs by presenting a brief history of corporate venture capital, and detailing the characteristics of CVCs during the dot-com period and today. In this blog I discuss when corporations should be establishing venture funds, I introduce a framework for creating venture funds and discuss two of the dimensions in this framework.
I started writing these posts with the hypothesis that in their effort to innovate, corporations must re-invent the traditional R&D model with one that augments the R&D efforts with venture investments, acquisitions, strategic partnerships and startup incubation. Corporate VCs (CVCs) are expected to play a big role in this innovation quest. It is assumed that a CVC can move faster, more flexibly, and more cheaply than traditional R&D to help a corporation respond to changes in technologies and business models. With that in mind corporations are establishing such groups in record numbers, including corporations from industries that have not traditionally worked with venture capital. Corporations have been providing their venture organizations with significant size funds to manage, and expect them to invest in companies of various stages and geographies. Today’s CVC prominence can result in many advantages for entrepreneurs and co-investment partners but also carries risks, many of which are due to the way CVCs are set up and operate within the broader corporate structure. In the last blog I examined how the disruption of institutional VCs (IVCs) can impact corporate VCs. In this blog I start taking an in-depth look of corporate VCs. I will examine the different types of corporate VCs, compare the characteristics of today’s corporate venture groups to the characteristics such groups had in the late ‘90s, and describe the areas where CVCs must focus on in order to succeed. In the next blog I will provide some ideas on how to best set up a CVC organization based on my work with such organizations to date.
In my last post I wrote about corporate incubation/acceleration models, presenting four distinct ones, discussed how to start one of these organizations, and how to increase the value derived from them. In this blog I provide additional details on the topic by:
- Presenting the criteria and guidelines a corporation should use to start an incubator or accelerator. This is particularly appropriate for corporations that are thinking about starting an incubator or accelerator, or have just started one,
- Discussing what the corporation could do with successfully incubated projects, e.g., whether to integrate them to a business unit, or let them operate independently. This is particularly appropriate for corporations that have started an incubator or accelerator and now considering how to be utilize the incubated efforts.
This is a long post, not unlike the previous one. I felt that it was important to provide a comprehensive view on corporate incubators and accelerators with two posts rather than creating a longer series, even though I recognize that the approach may tax at least some of the readers. For this I apologize in advance.
Corporations are establishing incubators, e.g., Samsung, and accelerators, e.g., Orange, in order to advance their disruptive innovation initiatives. They are doing so on their own, e.g., Samsung, Swisscom, or in partnership with independent accelerators, e.g., Disney, Microsoft, and Barclays have partnered with Techstars. The terms “incubator” and “accelerator” are frequently used interchangeably to denote an organization that aims at helping very early stage startups, or even just teams in the process of considering the creation of a startup, get off the ground successfully. They do that typically in exchange for a small equity percentage in each startup. This blog addresses the role of corporate incubators and accelerators in disruptive innovation, rather than the general topic of startup incubation that has been covered extensively elsewhere. It presents:
- Four different corporate incubation/acceleration models.
- The steps necessary for establishing and maintaining one of these organizations.
- A process to help corporations increase the value and success rate they derive from their incubation/acceleration initiatives.
In 2001 Apple introduced iTunes based on the IP of a company it had acquired in 2000. By 2003, after the introduction of the iPod and of the iTunes Store, iTunes had become the de facto disruptive innovator of digital music. More recently Apple itself started being disrupted by Pandora and Spotify. Streaming music companies have been growing and taking market share away from iTunes because of their business model and technological innovations. For example, the data they collect about subscriber music libraries and listening habits can provide unique customer insights that can lead to better monetization of the service, as well as improved personalization of the service’s user experience. Apple’s internal efforts to develop a streaming music offering have been unsuccessful. In May, Apple paid $3B to acquire Beats, for its streaming music service this time in order to defend its turf and not be disrupted. Apple’s 2000 acquisition shows that disruptive innovation can be acquired in addition to being created. Even companies with strong innovation DNA, such as Apple, Google, Facebook, and 3M, frequently acquire innovation for a variety of reasons, as we will see later on. To access disruptive innovation corporations may acquire early stage startups as Apple did in 1999, or later stage private companies, as Google did more recently with the acquisition of Nest. In this post I try to make three points:
- Innovation can be acquired, as much as it can be created within a corporation.
- Lack of growth in large corporations, combined with the accelerating innovation pace, are causing corporations to increase their innovation-driven acquisitions, particularly of earlier stage companies.
- Corporations must first identify the goal driving each innovation-driven acquisition and utilize five important dimensions with their associated actions during the acquisition and subsequent integration process.
Since 1999 we have been investing in companies that develop SaaS applications targeting the mid-upper and global enterprise. Through these investments and the hundreds of other SaaS companies, targeting these and other segments, we have considered during this period, we have started to notice a transition in the way companies utilize cloud computing infrastructures platforms to develop, test and deploy their applications. In the last 5 years SaaS companies, particularly the earlier stage ones, have started to transition from exclusively building and deploying their applications on custom developed infrastructures, to utilizing third-party infrastructures and platforms for these tasks. Third party infrastructures come in two flavors: Infrastructure as a Service (IaaS), e.g., Rackspace, VCE, or Amazon’s AWS, and Platform as a Service (PaaS), e.g., Salesforce’s Heroku, or Microsoft’s Azure. During this period we have seen SaaS companies for which developing and deploying on a public infrastructure was absolutely the right decision, e.g., Dropbox developed and continues to deploy on AWS, and others which had to switch to a private infrastructure after having initially developed their application on a public one.
The decision to employ a custom/private infrastructure for a SaaS application, or, alternatively, the decision to switch from a public to a private infrastructure to develop and deploy such an application are expensive propositions for a SaaS company of any size. Using a private infrastructure means that the SaaS company has full control of its infrastructure but also that a meaningful percentage of its capital is spent for the development, maintenance and upgrading of this private infrastructure. Switching from a public infrastructure to a private one, or even switching among public infrastructures, done without proper planning leads to delays in product release schedules, increased downtime and low customer satisfaction.
SaaS entrepreneurs and management teams are asking two questions regarding the platforms and infrastructures used for their applications so that they can accomplish their development, testing and deployment goals while building profitable companies, maintaining their customers trust and expectations:
- What factors should I consider as I try to determine whether to use a third party/public cloud computing infrastructure?
- When should I move from exclusively using a public cloud computing infrastructure, even in a single-tenant mode, to using a private/custom infrastructure or to using a hybrid approach?
We see entrepreneurs selecting a third party platform to start developing their SaaS applications because they instinctively believe that the associated costs, for both development and initial deployment, will low. They are often right about the startup phase of their business. However, the decision for the long term use of such infrastructures is not as simple as it first appears because several interdependent factors need to be considered. They include:
- The economics associated with the company’s business model. For example, a SaaS application that will be monetized using an advertising or a freemium model has very different economics than one that will be sold and monetized through a direct inside sales model. The paying users of the application’s premium version must subsidize the usage of a very large number of users that utilize the application’s free version. Therefore, the company’s operating model must take into account the costs of running the infrastructure used to develop and deploy such an application. One can then determine if the company can create a profitable model using a third party infrastructure or roll out its own private infrastructure.
- The SLAs the SaaS application will need to meet in order to satisfy its customers. These SLAs can range from uptime to response time, from backup time to failover time, etc. SLAs are themselves a complex factor. They are dictated by the type of target user, e.g., consumer vs corporation, the number of users, e.g., hundreds for a specialized corporate application, to millions for a typical successful consumer application, the application company’s stage, e.g., the SLAs for an application that is entering its initial deployment phase are oftentimes different from the SLAs of a fully deployed application, the geographies where the application will need to operate, e.g., data storage and retention regulations in one geography may be different than in another. Each SLA has an associated cost. For example, if it is necessary for a SaaS application to run on multiple geographies from the time it is initially deployed, the use of a third party public infrastructure will enable the company to meet this requirement at a lower cost than having to build its own data centers. Certain application types, e.g., entertainment applications such as Flixster, general utilities such as Wunderlist or Open Table, etc., that are targeting particular market segments, e.g., consumer, SOHO, or applications targeting specific segments of the broader SMB market, e.g., Square, LevelUP, Milyoni, can be developed and deployed on third party infrastructures and never need to migrate to private ones. This is because the SLAs associated with such applications are more flexible and the third party infrastructures can easily accommodate them. Moreover, the scalability and capabilities of these infrastructures are constantly improving so keeping up with the applications’ growth is possible. SaaS applications such as Evernote, or Carbonite that have more stringent SLAs and, in addition to consumer and SMB segments, target the enterprise, run on proprietary infrastructures because third party infrastructures cannot meet their SLAs at acceptable economics.
- The regulations governing the industry targeted by the application. For example, the data privacy regulations governing applications targeting the health care and financial services industries often necessitate the use of private cloud infrastructures by companies developing application for this industry.
- The available in-house expertise and the importance of having such expertise. The company must determine whether it has the in-house expertise to build and maintain a custom cloud infrastructure to support application development and deployment, particularly as the company grows, whether acquiring such expertise provides it with a competitive advantage, and whether it is willing to continue incurring the costs associated with the building, maintaining and upgrading the required infrastructure and the associated expertise.
- The company’s stage. Early stage companies have different priorities, e.g., time to market, than later stage ones, e.g., sustaining growth at a reasonable cost.
Based on the factors above,
- Early stage SaaS companies use public cloud infrastructures to:
- Accelerate product development by focusing on the business logic and taking advantage of the ecosystem that is typically built around the third party platform to provide faster a more feature-rich application.
- Improve time to market by quickly onboarding customers.
- Address lack of expertise in building and effectively managing cloud infrastructures.
- Growth stage companies use public cloud infrastructures to:
- Reduce product development costs while enabling collaboration among distributed development teams.
- Reduce the cost and time to customer on-boarding.
- Utilize the elastic supply of computation and storage provided by the public infrastructures in order to easily grow their customers while meeting SLAs and regulations (geography-specific and/or industry-specific regulations).
- Achieve their growth goals while controlling capital and operating costs.
SaaS companies start using public cloud infrastructures and remain in such infrastructures if they target consumer and SMB market segments under business models that allow them to make money using such infrastructures, and can satisfy the SLAs of their target segments. Companies start with public cloud infrastructures and completely migrate to custom/private ones when they want to target mid-upper and global enterprises. If they target both the SMB and the large enterprise segments then they can use a hybrid approach remaining on public infrastructures to address the needs of the SMB segment and using their own private infrastructure to address the large enterprise segment, as Workday does which runs its application on both its own infrastructure, as well as in AWS. In all of these cases when a migration from a public to a private cloud infrastructure is contemplated I advise the companies to build their application assuming a multi-cloud strategy. This means that the application can simultaneously utilize several public cloud infrastructures, or that can it easily migrate from one public infrastructure to another, in this way also avoiding vendor lock-in. A multi-cloud strategy allows the company to avoid cloud vendor lock-in, effectively deal with SLAs and regulations (as described above), and better address demand elasticity (again, as described above). The problem with hybrid environments is that you have to keep track of multiple different security platforms and ensure that all aspects of your business can communicate with each other. Finally, if a company develops a SaaS application targeting a regulated industry such as health care or financial services then it needs to build and deploy its application on its own private infrastructure.
Determining the infrastructure and platform on top of which to develop and deploy a SaaS application is not as easy as it may initially appear particularly if the company is thinking long term. The factors I provided above which have been derived from my years of experience in investing in SaaS application companies will hopefully help entrepreneurs and management teams put some structure around this decision.
On July 15 IBM and Apple announced an exclusive partnership. There are several components to this partnership that have been addressed elsewhere (here and here) but of most interest was the commitment to develop 100 industry-specific mobile analytic applications for the enterprise. As I had written, the broad adoption of smartphones and tablets by employees, customers and partners, combined with a BYOD strategy, is driving corporations to rethink their enterprise application strategies. They are starting to mobilize existing applications and embrace a mobile-first approach for the new applications they are licensing or developing internally. Analytics-based insight-generation applications represent a major category of these new applications. Recognizing this trend, I and many other venture investors, have been aggressively funding startups that develop mobile enterprise applications.