Creating Categories and Buying Software

Ask most new enterprise software companies about what they’re trying to do and you’re likely to hear the words “category creation”. Categories, for the uninitiated, are a way to group companies that are solving a similar problem. Toothpaste is a category, as is laundry detergent, and in the world of software, you’re probably familiar with acronyms like CRM (customer relationship platforms) and ERP (enterprise resource planning). The logic of building a large-scale enterprise software company for the last two decades was that you had to build, and ultimately own, a category to be truly successful. 

But enterprise SaaS meant something fundamentally different twenty years ago when Salesforce was first introduced then it does today. So the question is whether our thinking about building categories needs to change with it? 

To answer that question we’ve got to examine a few areas: 

1. Where do enterprise software categories come from? 
2. Are categories still the best way to think about enterprise software as the go-to-market model of SaaS makes a shift towards transactional/bottom’s up?

Where do enterprise software categories come from? 

"We invest in category creators.” Or at least that’s the goal of every venture capital firm with money in enterprise software. The logic make sense: When you look at the math behind who wins in most categories of goods there’s a leader, an alternative, and everyone else (the graph from the book, The Evolution of New Markets above, personifies that). The company that tops the list is often the one that helped to define the space they exist in. Think Amazon in eCommerce or Okta in Cloud Identity. The economics of software, as in many things, is winner-take-nearly-all. And the model has worked well, in the enterprise alone, entrepreneurs and investors have built a $200B cloud software market in the last twenty years on the back of a category creation strategy.

Entrepreneurs and investors aren’t alone in shaping the category landscape. Analyst firms like Gartner and Forrester are also in the business of defining categories as a way to help their customers make better technology decisions. This is driven by both their own business model and the challenge or lack of transparency that has traditionally existed in the SaaS market. 

With the two large machines (vendors, analysts) focused on category creation, where do software buyers fit in? Unfortunately for them, for some time the answer has been stuck in the middle. The average enterprise now has 91 SaaS apps running in the marketing department alone. Is this number right? Or wrong? I’m not sure but we do know that Digital Transformations are failing at an epic rate. This begs the question of how the buying process should work in the modern day if software is going to continue to scale within the enterprise. Categories help us build mental models or shortcuts to solutions that might be needed but who should be part of the buying process has shifted and we should explore that. 

Are categories still the best way to think about enterprise software as the go-to-market model of SaaS makes a shift towards transactional/bottom’s up?

To go back to our first section, if the incentives for category creation has the entrepreneur and analyst aligned, who is aligned with the enterprise buyer? Increasingly, it seems like the answer is users, aka employees. One way the problem is working itself out is through the new way companies are buying software: The much-hyped “bottoms-up” model, allowing employees to vote with their clicks on what software they want to use. This evolution can be well summarized in this graph from Blake Bartlett at OpenView Partners:

The category creation model thrived in a world where products were locked up behind a long-term software contract and information was disseminated via sales teams and verified by analyst research. This model can be well personified by the Oracle column. It got slightly better with the shift to the Salesforce, where buyers could potentially trial software. But even there, much of the functionality was predicated on a longer-term contract and implementation process and the enterprise buyer still often relied on analysts telling them what the best solution was for them. 

The Slack column is where the game has changed. This is the place where enterprise users seek out solutions and buyers play a fundamentally different role than before. Instead of waiting for analysts to tell them what categories they should be looking into, the new job is to aggregate demand and decipher the data on what is special about these products and how you can get the most out of them. The movement Slack represents has come to be known as Product Led Growth: A model where the product, first sold to teams within the company, is the primary driver of sales and expansion as opposed to the more tops-down approach historically associated with the industry. 

Good Buying Loop / Bad Buying Loop

It is worth taking a moment to also speak to this idea of validating user data and how that creates a better buying loop. One of the challenges of the traditional buying model was how your buying loop was created. All too often a vendor or analyst would identify a new category. While buyers could still do research, the natural buying loop was thrown off by the idea that demand was often created by the market machine (new category!) vs understanding and validating a challenge that came up internally. Often times, you would identify the need from the market and then work back in to justifying the purchase given the lack of data and potentially the need to showcase to the CFO that you ran an ROI analysis of how this new category would help the business. Who often would help you put those ROI models together? Analysts have a whole business doing this for the enterprise and when you didn’t have an analyst do it, the vendor was more than happy to build you an ROI calculator. It is easy to see, biases abound in either situation. 

Here is an example of what I would deem a bad buying loop. 

How do you build a good buying loop? 

First, I think you must strike justifying from your purchase model, it is too easy to “blue sky” a ROI calc and too easy to be supplied with it from the analyst or vendor. This creates bad behavior and leads to bad outcomes, even when it sounds right to “justify a purchase with a ROI model”. 

What you are looking for in a buying loop is to understand what your users need and then validate those needs with data. Here is what this looks like in practice. 

With the new way of buying software is it is much easier to understand, you watch what users are picking up themselves. As you understand this behavior, you can quickly move your mental resources to validating that behavior. Is this good for the user? Could this be good for the enterprise? Are there economies we could take advantage of at the user/team/organization level if everyone was using this? This where you can marry the best of bottoms up (users identifying pain and validating with data) and tops down (a view in to how this could be orchestrated across the enterprise). 

What’s great about the new paradigm of buying is you can answer these questions through trial and measure value without crazy upfront costs. The goal in all of this is ideally to find ways to leverage software to make our jobs better and find ways to allow people to feel mastery over their tools and in the flow of how they want to work. Categories can still be great for categorization and to rally an organization around a movement, the key is in how that category makes it way to you and you in turn move it through the organization. 

What do you think? I’d welcome your thoughts and critiques on the way buying software is changing.