Creator-User-Buyer Is a Mouthful. It’s also the Biggest Trend in Enterprise Software.

If you want to see the future of software, watch what product teams are buying or building.

Developers buying software is the most important trend in software today. SaaS is well understood and priced. AI may in time be bigger, but it’s unclear just how big or how far the tech can take us. From my vantage point as an enterprise software investor at Scale, the most important trend to watch is what is happening with developers buying their own software. Let’s call them creator-user-buyers. 

To understand why I say this, we need to look at how software procurement has evolved over the past 30 years. I’d argue that the reason SaaS was such a significant development wasn’t the deployment model but the buying model. Pre-SaaS, IT owned software procurement. They were the buyers but, importantly, not the users. It allowed for a lot of misaligned incentives around external software. While there was plenty of money to be made by software companies, inside the enterprise the IT incentive problem led to sub-optimal software. 

SaaS and the User-Buyer

Then in 1999, Benioff launched Salesforce, ushering in the era of the SaaS deployment model and the new buying model that came with it. For the first time, business leaders bought their own software. Because IT didn’t operate the software, they had less influence over the procurement process. 

This had two important implications. It (1) made for more valuable companies because subscription revenue was more predictable, sales cycles were shorter, and customer long-term value was higher. This is often where people stop in explaining the value of SaaS. And while important, it is not as important as the fact that (2) it led to better software. The economic virtues of SaaS (point #1) have been well documented. The user experience virtues of SaaS (point #2) are critical to understanding how this impacts developers. 

Enterprise software had historically been bad (difficult to use and bloated with discontinuous features) because buyers were not users. IT and procurement organizations did their best, but they didn’t or couldn’t know what users really wanted. They could compare feature lists, which is what an RFP/Q experience excels at, and thus bias buying decisions towards more documented features and more IT control/customizability. 

This was more optimal for IT and less optimal for users. Thus, when business leaders and eventually users started to buy their own software, they voted with their dollars and said, “Actually, I want this user experience and I don’t need all the bloat.” This created a tighter feedback loop between creators and users.

Rise of the Developer

Meanwhile, developers, like business users before them, were also unempowered. They were handed their tools by IT until, a decade after Salesforce, AWS completed its IaaS platform with the launch of RDS, and with it a new buying model. Developers no longer had to ask IT permission to get resources, and soon started buying their own software and tools.

Just as significant as IaaS/PaaS to this trend is the increasing prominence of developers inside an organization. Once seen as fungible resources to build what sales-driven CEOs wanted to sell, developers, led by the young founders of internet startups like Google and Facebook, became the new captains of industry. At these companies, engineering is the primary decision-making function. Like finance or sales is in other industries, or was in earlier times, developers became expensive and their productivity became paramount.

Both of these groups, first the empowered business users and then the empowered engineering users, adopted similar grassroots buying models. Business users in the 2000s sought out their own software solutions and then tried them out themselves. Content marketing efforts steered them to landing pages where they reached out to inside sales teams, a novel sales motion for the time. 

More recently, engineers (with business users following their lead) took this “bottom-up” adoption to a new level by shunning salespeople entirely. They wanted frictionless access to try and buy. This approach is what’s come to be called “product-led” growth, popularized by the developer tooling company Atlassian.

Product-led growth has mostly been engineering-led growth, meaning it is the product teams, the software creators, that are the early adopters and trend setters.

Creator-User-Buyers

Slack, Trello, Airtable, and Notion were all built by product teams (engineers and designers) for product teams before spreading to other parts of the organization. It turns out that the only thing that produces better, more usable software than user-buyers (SaaS) is creator-user-buyers. With SaaS, if sales teams wanted a better CRM, they could ask IT and get Seibel or shop themselves and get Salesforce. Today, if a developer wants a better way to track customers, she just makes it or asks friends what they are making.

Creator-users have communities of early adopters borrowing ideas from one another to rapidly iterate on the future. They are solving user needs far faster than non-user teams are even aware of them. When something is so good that these creator-users stick with it (rather than build their own slightly improved version), it spreads like wildfire inside and outside of the community--as we saw with chat, kanban, database, and wiki tools.

The creator-user-buyer is a big deal because of its sheer explosion in size. Growth in the number of developers is outpacing any other function. In order to keep up with demand, creators are coming out of the woodwork. Whether training in “bootcamps” or self-taught, creating software is no longer limited to formally trained professionals and academics. 

Looking Ahead

Software has evolved from professional buyers (IT) to user-buyers (SaaS) to today’s emerging creator-user-buyers. If a need exists for a new software application, and those that can build it are well acquainted with it, they will be the first to build/discover it. Given developers’ prominence as influencers in business organizations today, this holds true for all horizontal business software. You’d expect it to emerge from early adopter product communities. (As an aside, this also implies that vertical, field, or non-office software still requires product teams to innovate on behalf of customers. Those are still in the realm of user-buyers.)

If you want to see the future of software, watch what product teams are buying or building. They are the new enterprise trendsetters. This narrative also suggests that this is the endgame for digital businesses. There’s no room for another *aaS revolution because you can’t get closer to the inspiration center than creator-user-buyer communities.