Design choices when pricing the platform with extensions pattern
Steven Forth is a Managing Partner at Ibbaka. See his Skill Profile on Ibbaka Talio.
Most SaaS applications start life as one big package. Everything is included in a big package and there are usually only one or two pricing metrics: a subscription metric and a usage metric. Over time, more functionality is added and new use cases are addressed. The solution evolves and gets split into two or more modules. This is when the first choice occurs. Split the functionality into two independent modules or into a platform with extensions.
What is the difference?
With independent modules, the buyer can buy one or the other independently.
With a platform with extensions, the buyer must buy the platform, but modules are optional.
Over time, additional extensions (modules) are added as existing modules are split or completely new functionality (like a Generative Content AI) get layered in.
The platform plus extensions packaging pattern comes from with some key pricing choices.
Ibbaka recently worked through these choices with two of our customers and came to very different designs for each company.
For one company, a cybersecurity company with a mature offer, the platform subscription was set relatively low with most of the revenue being driven from the modules. The usage-based pricing factor was set for the modules, and not for the platform.
For the other company, an Industrial Internet of Things (IIoT) platform, the platform subscription was set higher than the module subscriptions and the usage component was put at the platform level.
Let’s explore the design options in a bit more detail and then look at how decisions were made for each of these companies.
Key pricing decisions in the platform with extensions packaging pattern
The key decisions are:
Relative weight of platform revenue vs. module revenue
Location of the usage-based pricing component
Relative weight of usage based pricing vs. subscription
These decisions lead very different revenue mixes, and will deliver different levels of growth and Net Revenue Retention in different market conditions.
Revenue in each of these four above scenarios is the same, by design, but this can diverge quickly under different subscriber and usage assumptions. Below is one of many possible cases where the distribution of users across modules changed and the usage went up slightly.
Let’s look at two scenarios that Ibbaka priced recently and then see if there are some general heuristics we can use in designing pricking for this packaging pattern.
How Ibbaka derives pricing from value models
Ibbaka derives pricing from the value model. The process is simple.
Select the value drivers that are generally applicable and that are driven by variables that are easy to define and track, ideally the variables used in pricing should be tracked by the platform itself.
Calculate the economic value across a range of plausible customer scenarios.
Choose the variables that satisfy point one (easy to define and track) and that account for the largest amount possible of the variation in economic value.
Set a target value ratio
Write an equation so that the variables generate a price that generates the target value ratio across the plausible customer scenarios
If necessary, layer in a scaling algorithm
Case 1: Mature Cybersecurity Company
Our first case study is a cybersecurity company that has a standard platform with modules for specific use cases.
As we worked through our process we realized that a bit more nuance was needed.
The value drivers could be easily divided into two groups, those associated with the platform and those associated with the usage of a specific module (this sort of clean mapping is not always possible)
The value drivers for the platform accounted for only about 20% of the value in most scenarios, but they were much more accepted by buyers
The value drivers for module usage accounted for about 80% of the value in most scenarios but were not as well validated or accepted
We accounted for this in 4 ways:
We set the target value ratio for the platform at 20%
We set the target value for the modules at 10%
We used only subscription pricing for the platform, no usage-based pricing
We used only usage-based pricing for the modules, no subscriptions
This design has several advantages:
Buyers accept the pricing structure as it aligns with their perception of risk and value
It is easy to adjust as one gains a better understanding of the market or as enhancements make it possible to create more value
As value becomes better documented the target value ratio can be increased
A value model is a system of equations that estimates the economic value of a solution for a customer or customer segment
A value driver is one of the equations in the value model, there are 6 types: revenue, cost, operating capital, capital expenditure, risk, optionality
The value ratio is Price/Value
Case 2: Emerging IIoT Platform
Different pricing design choices were made for the IIoT solution. In this case most of the value was delivered through the platform with the modules being used to implement specific use cases (not a bad way to organize a design). The grunt work of processing connections and data is common across all modules (with one exception). The same value drivers apply at the platform and module levels, although the specifics of the equations and the variables differ.
Given this,
The pricing is weighted toward the platform, with the platform subscription being 2X to 4X more than the subscription for a module
The usage pricing is at the platform level, there are no additional usage fees for modules
The module with the additional value drivers offers IIoT monetization. One of the most common pricing mechanisms for monetization software is some form of transaction fee, which is what we recommended here.
Some heuristics for pricing the platform with extensions pattern
The key design decisions when pricing the platform with extensions are:
The balance between the platform price or the module prices
Whether usage-based pricing should apply to the platform or to each module
If the same pricing metrics should be used for the platform and modules and between modules
There are a series of standard questions you can ask help you answer these questions:
Are the value drivers the same for the platform and modules or do the modules introduce new valuer drivers?
If the value drivers for the solution are consistent across platform and modules, and the models provide incremental value, pricing is relatively easy. Just align price and value and add up the total.
If there are different value drivers for the platform and different modules pricing becomes more complex. Design pricing that reflects the value of different combinations of the platform and modules.How does value to customer (V2C) change with scale and use case?
If value changes linearly with scale and is not dependent on the use case of modules being used, then usage-based pricing should be applied to the platform.If value to customer to the customer does not increase linearly with scale consider a scaling function that reflects this. The scaling function can be different between the platform and each module (this is being seen quite a bit in 2023 for new generative AI modules).
How much of the value to customer (V2C) is delivered by the platform?
How much value to customer (V2C) is delivered by the modules?
The pricing balance between the platform and modules should reflect the value provided by the platform vs. that provided by the modules.
Strategic positioning as a platform company vs. a product company can also be considered, and when the platform is more strategically important consider capturing more of the value at the platform level.
The platform with extensions pattern is a powerful way to build a business based on a central technical innovation with multiple applications. It makes it easy to introduce new modules to add new use cases and expand the market. Pricing needs to support the platform goals and the ways the platform and modules work together to deliver value.
