Product-Led Growth with Usage-Based Pricing Drives Complexity

PART 1

PLG+UBP: The Need for Data, and the Cost of Finding It

A wise man once said: PLG + UBP = NRR*. Well, he posted it on LinkedIn, which is close enough. And it’s empirically true that SaaS businesses deploying these models in tandem grow faster and better than those that don’t.

With Product-Led Growth (PLG) the goal is to build products that sell themselves to their end-users - easy accessibility, great usability, clear benefits, and limited/no sales intervention required to enable adoption or expansion. You have to deliver value quickly, and leverage product usage data to fine-tune product development.

Usage-based pricing (UBP) turbo-charges the PLG motion by further lowering the financial barriers to customer acquisition, and removing more friction from expansion in usage (customers just pay more as they use more).  It requires smart design because the value a customer derives from usage must be closely correlated with the cost of that usage - you need to choose the right value metric.

Get it right and you have effective pricing and a positive feedback loop - because customers will only consistently use what they value, you get immediate insights into your ongoing product fit, allowing you to fine-tune product and pricing forever (sorry… pricing is never finished, it’s a journey).

Product-Led Growth + Usage-Based Pricing = 🚀🚀🚀

The two approaches reinforce each other and help create an equilibrium between what customers value + what they use, and what you build + what you charge for it.

But there’s no such thing as a free lunch (except if you were a guest at Googleplex campus circa 2010 when they still promised not to be evil, and gave you great free sushi). Making use of all this goodness is predicated on visibility of what is going on, and a sophisticated toolset to fine-tune your business in almost real-time based on that data.

The Need for Data, and Costs of Getting It

PLG+UBP requires access to a wealth of data to power that tooling. That means building usage data infrastructure from scratch, which is daunting -  and distracting to do instead of working on your core product. Your platform typically throws off all sorts of useful events, but has nowhere to put them because no data infrastructure exists to cater for ingesting, transforming and aggregating usage, cost and price data in one place.

Very quickly there is a new mountain to climb just to bill customers accurately, let alone see what’s going on in your business, and to create the levers that would let you adjust course through pricing changes and product insight.

Most businesses start by stitching their product platform to whatever tooling they can find already in place, often their invoicing and payments platform, to at least bill their usage-based customers. Often this results in manual processes, spreadsheets and jury-rigged databases or BI tools that were never designed to deal with cloud-scale usage and cost data. This leads to a host of problems that expand with growth: delays in closing the books, overbilling (and loss of customer trust), revenue leakage and a lack of pricing flexibility. Above all it consumes the time of typically high value people.

Half of all businesses in this position surveyed in 2021 tried to build a solution internally, with the other half repurposing / augmenting existing tooling with manual processes (spreadsheets and FTE!). For those that did build in-house cost ranges in the chart below. The average was 1000-2000 FTE hours to build - the equivalent of 3 FTE to maintain.

$500k to Build, $300k p.a. to Maintain

With costs like these the case for building your own is hard to justify - especially compared to the price of buying. Even factoring in any cost of initial implementation and onboarding, the payback for using m3ter is just a few months compared with building your own - with actually increased flexibility. Because that is the biggest problem of self-build: not the cost, the distraction, or the waste of resources better spent on your core product - but that you inevitably build a point-solution, not configurable tooling, so the outcome is ‘brittle’ and won’t grow with you.

More on that in Part 2 when we discuss that happens when you add a Sales-led motion into the mix, and look beyond just ‘fixing the plumbing’ causing you billing ops pain.

*Which are VIP TLAs in SaaS ;-)

Todd Gardner LinkedIn post "SaaSmetrics UBP PLG"

Todd Gardner LinkedIn post "UBP SaaSmetrics Venture Capital"

Follow us on LinkedIn to be the first to see Part 2.