From Enterprise to SaaS: the pain and the promise

GigaOm recently published an interesting article on Oracle’s challenges of shifting towards a “metered pricing” model. From my perspective it raises a series of fundamental issues addressing how enterprises buy and consume software: 

• Is the classic enterprise software licensing model a dying vestige of a prior generation?
• Can legacy enterprise software-driven firms make the cultural transition to a more flexible, SaaS-based approach?
• Can publicly-traded firms constrained by quarterly earnings targets make the painful financial transition implied by this shift?

Oracle’s circumstance is merely a microcosm of the larger issue. As a business owner, would you rather:

• Have multiple parties from which to choose with relatively low switching costs, thereby minimizing lock-in?
• Only pay for the stuff you actually need instead of purchasing at all times for peak capacity?
• Be able to ramp up and ramp down users and usage on an a la carte basis?

The answers seem fairly clear. The “as a service” (aaS) model is, in general, preferable to enterprise-wide software licensing due to smaller upfront investments, lower switching costs and greater flexibility for managing scale. This also enables centralized software upgrades, the ability to manage either in-house or cloud deployments and yields smoother operating cash flows.

So if more and more customers want software as a service, then why is the transition by the biggest incumbents, such as Oracle, taking so long? 

Selling enterprise software is like a drug. Big ticket sizes. Hefty annual maintenance charges. Heavy switching costs. This is why big-time enterprise software sales professionals get paid massive commissions and are often the best-paid people in the company. It is hard treadmill to jump off of, however, because the cash flow dynamics of enterprise software vs. SaaS are very different, and the impact of shifting from one model to the other is dramatic. Enterprise sales are about closing the big license then moving onto the next one (until the periodic upgrade, of course!). The result is large yet choppy cash flows (as annual maintenance is a fraction of upfront license value) unless you can continue to churn out big-ticket sales year in, year out at an increasing rate. Great companies can do it for years by continuing to sell license upgrades and closing new deals in a greenfield market. However, as the market gets saturated this becomes harder and harder, and when compounded by a sea change in the way businesses actually want to buy software the forces of gravity become too strong to withstand.

So what about shifting to SaaS? Well, there is good news and bad news. The good news is that SaaS companies, such as Salesforce, have successfully built huge amounts of something called CMRR - Committed Monthly Recurring Revenue. What this means is that as they sell more seats under 1 and 2-year agreements, they are building an ever-increasing cash flow annuity that is easy to value and kicks off large amounts of free cash flow. Selling costs are far smaller than in enterprise software because the upfront commitment is measured in the hundreds or thousands of dollars, not hundreds of thousands, millions or tens of millions of dollars. Let’s just say that the CIO and CFO aren’t getting involved in the procurement decision for a long, long time. Further, there are often big up-sell opportunities within existing accounts as they often start with small numbers of seats to test out the service and then grow over time, so it is not merely a game of finding a whole new set of companies to generate top-line growth. This is all good stuff.

HOWEVER, the bad news is that those big upfront sales that the legacy enterprise software model generated? Gone. And the time it would take for high-quality, recurring monthly SaaS sales to begin to approach the lumpy but large enterprise software sales is significant. This is a level of creative destruction that is hard to see being embraced by a large software company, particularly a public company. In fact, I think it would be almost impossible without building a Saas business line along side the legacy business line and eventually selling the legacy business to private equity investors who will see it as a valuable but depleting asset (not unlike an oil well). This way, the old-line company could leverage its long-term relationships during its SaaS transition before casting off its original but antiquated business. Alternatively, Mr. Market might eventually make the decision blindly straightforward. If the service-based software model does become the format of choice for acquiring a particular set of capabilities, then enterprise software multiples will plummet and render these companies takeover targets for private equity investors, anyway. Either disrupt oneself or become forcibly disrupted. This is the feature of fast-moving, innovative and highly competitive markets. Good for customers. Good for growth.

I personally saw this painful transition in one of my angel investments, a company called Global Bay Mobile Technologies. They have a great mobile data collection product that was initially sold into Government agencies. These deals were sold either direct or as a packaged solution through systems integrators. The sales cycles were painfully long. The working capital required to fund the business was significant. But when these licenses were sold, they were very profitable. However, the company saw uses for its technology that extended far beyond Government, into retail for inspections, “line busting,” and other store-based applications. Companies wanted to buy their software in small bites, testing it across a small number of stores before expanding across an entire geography or chain. In short, a SaaS sale. So the company made the tough decision not to sell any more enterprise licenses and to bet its future on SaaS. Revenues initially fell. Cash flow fell, too, as software needed to be re-tooled to function as a SaaS platform. But what resulted was a stream of consistently rising CMRR resulting from a great product, a low-cost initial sale and myriad up-sell opportunities within existing accounts. Eventually, the company caught the eye of VeriFone who purchased Global Bay in Q4 2011. It was a happy ending, but one that took a ton of work, wrecked the financials for 18 months and thankfully happened away from the peering eyes of the public markets. 

How enterprise software companies manage this competitive imperative will be fascinating to behold. But rest assured, this transition, be it going private or trying to make this shift in the public arena, will provide fodder for many case studies for years to come.

Tweet

Data Entrepreneurship

I have been thinking a lot about what a data scientist really is and how we, as academic and business communities, can help more people develop important data-driven skill sets. But every time I use the term “data scientist” to describe what I’m seeking something doesn’t feel right. Probably because “scientist” to me implies something being done in a lab, not in the external world. Perhaps it’s because when I think of data scientists I am thinking about people who pursue Ph.Ds and focus on research, while what I’m really talking about is something entirely different. What then?

The Data Entrepreneur. This is related but different field of study, one that is laser-focused on application versus research. It is a broad-based interdisciplinary program that integrates topics such as software development, data architecture, algorithmic development, database management, machine learning, statistics, optimization, user experience and web design, with classes in entrepreneurship, finance, management and leadership, marketing, data hacking (taught by people from start-ups) and extensive field work. Essentially, taking classic informatics that blend CS/Engineering and Math/Stats and melding it with Entrepreneurship, business foundations and workplace experience. These people will be equipped to both solve hard applied data problems and start companies. By having the knowledge of how to manipulate data and the empathy and experience of leveraging data for the benefit of the enterprise (social or commercial), these are people who will have the skills and perspectives to change the world.

This is a work in progress, but as data sits teetering between opportunity and crisis we need people who can shift the scales and transform data into real assets. And the conclusion I’ve come to is my attempt to re-define the Data Scientist is the wrong approach. I’m talking about a whole new class of people: the Data Entrepreneurs.

Tweet

The data scientist v2.0

I’ve been thinking deeply about the need for more people facile with extracting meaning from data - or a “data scientist” for lack of a better term. My friend and colleague Drew Conway developed a useful model for thinking about the attributes of a data scientist. He essentially views this individual as sitting at the intersection of three spheres of a Venn diagram - Hacker/coder, Math/stats and Domain Experience. The data scientist, therefore, has the coding tools and analytical rigor that when applied to a specific domain can yield valuable insights.

I love Drew’s framework because it gets to the single biggest issue I’ve seen lacking in many brilliant Ph.D’s who have “data scientist” written all over them yet fail to translate knowledge into production code - applied knowledge. In fact, Drew is a very accomplished data scientist in his own right yet achieved this standing with only an undergraduate degree (and not from Stanford, Caltech or MIT, mind you). My point is this: the ivory tower notion of a data scientist is total bullshit. Can a Ph.D play the game? Sure. But does one need a Ph.D to be a successful data scientist? No way. 

I can easily see a cross-disciplinary undergraduate degree in Data Science conferred by the schools of engineering, information sciences or business. It would be a mix of classroom, lab and field work, with fundamentals of coding, CS and user experience, mathematics and statistics and marketing and strategy. For those wishing to delve more deeply into one of these areas, an optional fifth-year Masters degree could be offered. And yes, there will be those for whom a Ph.D is the goal either because of a desire to enter academia or to perform original research. This is perfectly awesome as well. But becoming a skilled data scientist focused on application versus theory does not, in my experience, substantially benefit from a Ph.D. In fact, it may do the opposite. 

The data scientist v2.0 will be out in the world applying their skills to real-world problems, not toiling away in a lab, in solitude. The will get better and better by having more of these real-world experiences from which to hone their hypotheses and glean their insights. And yes, collaborating with a larger pool of data scientists about better techniques for achieving these insights will help as well. Perhaps the Academy will not appreciate my perspective on this matter. But I am not of the Academy. I respect and value the Academy but believe there is much to be learned - that must be learned - on the outside. And this will be part of the fiber of our next generation of data scientists: of the people, by the people, for the people.  

Tweet

Thoughts from Ann Arbor

Last week I spent two glorious days deeply engaging with my alma mater, the University of Michigan, and the Ann Arbor tech community. I had the privilege of presenting at the Ann Arbor New Tech Meetup (thanks, Dug!), exchanging ideas with the Wolverine Venture Fund, and spending lots of time with professors and heads of different programs and institutes such as the Zell Lurie Institute, the Center for Enterpreneurship and the School of Information. I also got to see Ann Arbor’s take on the collaborative start-up model, Tech Brewery, which houses some very cool companies. My 48 hours in Ann Arbor were a whirlwind that left me both amazed at the progress the University and the community have made towards fostering entrepreneurship while keenly aware of how much more there is to be done. It also reinforced my already-existant mission of wanting to re-think exactly what a data scientist is and, in its wake, how we help create more of these people towards building a better future. 

One thing I noticed at Michigan is how developed and entrepreneurial its Office of Technology Transfer is relative to many of its peers. My sense is that because of Ann Arbor’s physical location (a land-locked jewel of innovation), it has had to be incredibly scrappy and experimental in order to achieve its goals. There simply aren’t the deep network effects that exist in San Francisco/Silicon Valley, New York/Silicon Alley or Boston/Cambridge. And while it is still early in the game, they have done a great job cultivating relationships across the University and working closely with the departments to get technology successfully spun-out from the School (kudos to Wes Huffstutter for greasing the wheels of cross-institutional progress). But the fact that “tech transfer” at Michigan doesn’t conjure up thoughts of the usual hard-to-work-with, inflexible bureaucracy is a tribute to what they’ve accomplished in the past decade. Other schools have much to learn from Michigan’s progress.

I was also impressed with the pockets of entrepreneurship across the schools of Business, Engineering/CS and Information. Yes, these efforts are still way too concentrated within the programs as opposed to truly horizontal across the University, but these efforts give me hope that collaboration-as-necessity will eventually break down these artificial boundaries over time. But the energy an enthusiasm from the program heads, mentors and entrepreneurs themselves is palpable. It is hard not to get caught up in the excitement of what is going on and how much more could be going on, and better, too.

What Ann Arbor currently lacks is a bunch of successful exits where the entrepreneurs re-invest back into the Michigan ecosystem. Firms like Google, Facebook, Twitter and IBM descend upon Ann Arbor to hire the best and brightest, and several tech firms are establishing local presences. However, for the flywheel of entrepreneurship to take hold companies need to be be invented and built in Ann Arbor, with founders coming back and seeding businesses locally after they’ve had an exit. They also need to start new companies as experienced entrepreneurs in order to deepen the management talent that is sorely lacking. A local start-up will get funded but then relocate to Silicon Valley or New York, and this has to be ok. But it is important for people to remember where they came from and got their break. Ann Arbor needs this kind of memory to keep the Michigan diaspora engaged and invested in the University and Ann Arbor ecosystems.

Also, my sense is also that there is not yet a robust software-knowledgable base of angels around town. Life sciences has historically been very strong as well as businesses related to the auto industry, but pure software does not have the same shape as these legacy businesses. Start-ups in general, and software start-ups in particular, can look really ugly. A few coders in a little crappy office or shared work space is what a software start-up almost always looks like. Yes, they might be building a profound product but it doesn’t look like a “real” company to inexperienced eyes. More experienced angel eyes are needed in A2 to help nascent companies move beyond Friends & Family and get to a real seed round.

While I’ll deal with my view of the next generation of data scientists in a subsequent post, I am incredibly interested in helping to build a dedicated program towards this end at Michigan. All the pieces are there. It just requires some cross-departmental cooperation in order to bring it to life. This is one of my missions for my alma mater: help to pull together a data science program that empowers student/practitioners to solve tomorrow’s problems today. It can be done. It must be done. It will be done.

Tweet