This post was originally published on The Data Source, my monthly newsletter covering the top innovation in data infrastructure, engineering and developer-first tooling. Subscribe here and never miss an issue!
Product-led growth (PLG) as a concept and software category has exploded over recent months, with more and more companies adopting a product-led approach as part of their GTM motion. While PLG has been on the rise for the past few years, it’s definitely having its moment, with many businesses re-imagining their current process for selling B2B enterprise software by putting the customer at the forefront. Unlike traditional sales where the sales rep is the first point of contact to the customer, in product-led sales, customers can play around with the product and decide its value to them before committing to making a purchase, all without having to go through a rep.
There’s a number of product-led sales / revenue tools in the market today — which I will dive into more in a future post — stay tuned!
But specifically within the PLG motion, one infrastructure pain point I have heard come up is companies figuring out how to best capture rich data about their customers in order to get granular visibility into real-time product usage (e.g. number of new sign-ups, which features are being adopted and by who, who are the internal champions, how does user behavior evolve over time, etc.).
This article on the Snowflake blog is a terrific overview of consumption-based pricing and it’s where I see future companies trending, especially as they think about their own usage-based pricing mechanism.
The question is, what does this mean for the tech stack to support such modern pricing workflows?
Looking back to the traditional enterprise sales model, companies would typically leverage a Configure-Price-Quote (CPQ) vendor like SAP, Oracle, Conga, or even Salesforce (which acquired Steelbrick for $360M to bring CPQ internally) to offer the right pricing and quoting to the right customers at the right time. But the issue with these solutions is that they just weren’t built for B2B businesses that are generating subscription-based revenue.
With players like Zuora, Chargebee, Chargify, Recurly and more, we saw the emergence of recurring billing platforms, purpose-built for businesses that were shifting to subscription-based models. Unlike in the old days of enterprise billing where companies would typically engage in one-off sales, recurring billing solutions shifted the focus from needing to sell higher volumes of products to needing to serve higher volumes of subscribers.
Today, it’s clear that we are on the cusp of yet another shift in enterprise billing and pricing. What enterprise SaaS subscription pricing looked like 10 years ago is no longer the same. I’m finding that more and more SaaS companies are experimenting with a usage-based pricing model (aka consumption-based or pay-as-you-go) to drive revenue.
Like product-led sales, product-led billing / pricing is inherently customer-centric. Instead of charging customers a flat rate regardless of their usage, they are now charged based on their actual consumption of the product. Companies that have successfully implemented a usage-based pricing model include AWS, Azure, Snowflake, Datadog, to name a few.
Now, new cloud-metering solutions are entering the market to re-think this next evolution of the “pay-as-you-go” model. At its core, these modern tools will play a critical role in unlocking real-time data about product consumption. In return, this will enable vendors to measure how customers are interacting with the product and assess what parts of the product or features are perceived as the most valuable (and monetizable).
I’m particularly excited about functionalities such as real-time metering, usage forecasting, and billing reporting at the infrastructure layer. In addition to these, there are specific cost management functionalities that could be weaved into the product so that customers can create their own rules around overages. Here’s what OpenView’s recent report lays out as the overage model so customers can control their costs across teams:
Each of these rules would require some level of configuration and instrumentation on the back-end infrastructure. If done correctly, this could be instrumental in creating better pricing transparency (so customers know exactly what they are being billed for) and flexibility in building pricing plans tailor-made for the business’ needs.
It is still the early innings of the PLG and usage-based pricing era, but I’m excited to track this broader category of product as it evolves. I’m also continuously learning and keen to talk to people who are spending time here.
‍
