Monetization: What SaaS platform builders need to know to prepare for growth, Part 2

When developing a SaaS product plan, it’s important to recognize two foundational principles. First, SaaS is a business strategy, not a technology strategy. Second, there is no one-size-fits-all SaaS architecture (the second principle is a corollary of the first). The challenge is to build common ground between business and architecture so as to translate business assumptions into critical technical solution inputs.

We begin by taking the measure of three foundational dimensions: (1) User Model, (2) Monetization, and (3) Measurement. In this blog series, we explore how these three dimensions figure into key technical recommendations which enable scale in pursuit of SaaS business growth.

Part 2: Monetization

Saying “SaaS = monetization” is redundant. So why put it on our shortlist? It’s easy to get lost in the noise of “SaaS monetization makes the world go round,” “Subscriptions mean printing money,” and other hype. Nonetheless, building a SaaS product platform is a special case of the old adage that time is money.

Feature value: a function of time investment of users and customers

The set of problems that your SaaS solves won’t survive long in the digital age if all it does is cut prices. Solving each customer problem as a function of how much time is saved by a particular feature? It is a necessary prerequisite for selecting the “threshold of value” you commit to building out in your platform architecture.

By focusing on how long it takes for each of the various user types in your user model to reach their goals, you can begin to quantify the gap between the distance between your features and their benefits. It’s OK not to know the answer about the size of the gap between the feature and the benefit, for at least two reasons.

• Cost to serve a customer-facing feature is money that comes out of your pocket, and goes straight into the cloud provider’s pocket. It‘s almost always a function of time. When you want to procure more cloud resources faster, cloud providers make it easiest to buy speed, whether or not that pays off for you in the long run.
• There is a non-zero cost to learning about the size of the gap between features and benefits. It’s almost never a good idea to assume there is nothing left to learn about what works best for all customers and users.

The more you can learn what value these features deliver to your customers at a lower cost? The more money you will have left to add more customers, get them committed to subscriptions, and keep them away from your competitors.

Optimize cloud economics and drive Business Goals.Proven best practices that help both finance & engineering teams

Of course, not all customers want to pay for all the features. If you’re lucky, there are just a couple of features that really set you apart (the SaaS industry is full of war stories on this). Grouping your feature sets into tiers is a great way to learn about what customers will and will not pay for. More on that below.

Cost of discovery from the customer’s perspective.

You understand you need to set aside some money to experiment with closing the gap between your cost of cloud services and how quickly customers realize time-to-value. But your customers also need time to discover the value of your service.

There are three constraints to solve for here: (1) which benefits you deliver as free features, (2) which you charge for, and (3) when you ask customers to decide. We have found it handy to divide between customers based on the nature of the problem your platform solves.

• When customers are familiar with the problem and your solution: discovery is less ambiguous, which means you can get them to make a decision sooner about the value.
• When you are solving a relatively new problem for your particular set of customers: the time required to make a decision about subscribing to your platform may be longer. This has consequences both for the cost of onboarding a customer, as well as the cost of maintaining the customer during the discovery period.

Think beyond the cloud about what other resources you need to invest in making customers successful with your platform. “Feature-led discovery” or “product-led discovery” belongs on center stage as part of your monetization strategy.  (For the definitive explanation of product-led discovery, see this article by Dan Schoenbaum).

Customer discovery is not a one-way, one-time process. The nature of a subscription is that the customer may reach a point where the value your platform delivers isn’t worth what you’re charging. It would of course be ideal that every customer you acquire subscribes forever, but it’s important to be realistic. Unsubscribers, known as churn, also factor into your monetization equation.

Billing events and unit metrics

The variable cost model of cloud platforms has forever changed how compute resources are bought and paid for and consumed. From the perspective of cloud architecture, the variable cost model means translating an incremental unit of cloud resources into an incremental unit of customer value. This is known as a unit metric.

• Every time your customer gives you a dollar for solving some fraction of a problem and it costs you less than a dollar, that’s profit. Reverse those, and it’s the opposite of profit.

• The power of the cloud platform is that there are virtually unlimited ways to execute on solving a customer problem.
• The power of well-architected cloud is in picking which of those ways does the most to keep you in business and growing.

The key economic touchstone in monetization is settling on a unit metric driven by value from the customer’s perspective.

• There’s a simple reason: money comes from the customers. Establishing a unit metric that’s visible to all the stakeholders in your organization drives alignment across the many choices to be made in building the software that delivers on customer value (rather than secondary internal KPIs).
• Applying a unit metric over time also provides an important baseline. When you think about how to change your features to solve customer problems, you can compare among the alternatives to make those changes add up.

In fact, the ability to accommodate changes at minimum cost is one of the characteristics that sets an optimal cloud architecture apart. When thinking about billing events, the challenge is to construct a set of value events that provides your customers a choice of price points.

• Your pricing strategy is an expression of the arithmetic that rolls up the value of your product in a way that makes it straightforward and transparent enough for a customer to buy a subscription.
• Whatever pricing model makes the most sense for the range of customers you are pursuing (examples here and here; there are many more), the job of your SaaS platform is to capture, track, and tabulate the cloud service platform events that make up what you are billing.
• Aligning the prices of any cloud service you purchase to the services you sell makes it easier to tie the value your product delivers to the price customers pay on a recurring basis.

There are two important caveats about how to make the best use of platform and billing events as part of your monetization strategy.

• “Real time” is not a technical requirement. More often than not, it’s a casual expression for “When can I have it?”  For purposes of your monetization strategy,  the overwhelming majority of data that you need can be captured hourly and rolled up once a day, prior to export into graphs for exploration and analysis.  
• Automation offers a very useful learning curve in iterating between “good enough” and “perfect”.  There are plenty of benefits that do not require omniscient anticipation of every change and fluctuation of system resources and user behavior.

I’ll touch on measurement in more detail in the next post. For purposes of monetization, there is plenty of leverage from aligning your feature sets with unit metrics at a “Goldilocks” level.

• As you iterate feature changes, allowing some reserve capacity gives end-users time to learn what’s new in your product.
• A tight closed-loop between unit metrics and monetization (especially when you and your users are learning how to leverage new features) can backfire. Giving customers some breathing room works better as an upsell opportunity than penalties and limits.

Cloud cost optimization and technical debt

The speed and versatility of the SaaS model are a two-edged sword. The pace of trial and error can create technical debt at a faster pace.

• Part of that technical debt is in what are known as non-functional requirements (how a system will perform). What’s the cost of that performance?
• A key virtue of establishing unit metrics is that you can use them to make comparisons of the cost of your SaaS platform over time (more on in the third post in this series, Measurement).

In fact, monitoring unforeseen changes in your cloud spend can be a direct indicator of how well your architecture delivers the features it was built for (see “Run cost as architecture fitness function”, November 2020 Thoughtworks technology radar). The variable cost model of the cloud doesn’t just mean that you can buy services at various price points. It also means that the price points change with time, and it is critical to the success of your platform to stay well attuned to those changes. This divergence between feature implementation and the cost of services is captured in an essential new discipline called FinOps.

Not all SaaS platforms have the freedom to start fresh with cloud-native constructs like containers,  serverless, and microservices.

• It’s often the case that an application stack derives from an existing set of platform components that are “lifted and shifted” into a cloud.
• The economics of such a migration can cut some costs, such as reduced platform licensing for RDS Aurora Database instead of proprietary DBMS storage, or rethinking tiered storage options using S3 object storage.
• Lift and shift changes can also introduce costs around spiky network traffic or data egress/ingress charges across secure VPCs or Availability Zones.
• Proper monitoring via a comprehensive tagging strategy delivers 360-degree visibility to all your cloud resources, so you can track and report interactions in between the different parts of your stack. There are tools, but it can be really hard to add well after launch.

As it turns out, cost observability is a core element of SaaS economics, as well as one of the essential types of observability at the core of your SaaS measurement strategy. That’s the subject of the next post in this series.

The more we understand your user model and your monetization approach, the better we can recommend which architectural options best support your business strategy.

Aligning your SaaS business strategy with SaaS technical architecture is critical to SaaS success. See more about all 3 M’s in these two companion blog posts Part 1: User Model and Part 3: Measurement. For a thorough assessment of options for a SaaS business model, download the AWS SaaS Journey Framework whitepaper, and/or take a technical deep dive into the SaaS Lens for the AWS Well-Architected Framework.