Pricing and Package Design - Two packaging patterns
Steven Forth is a Managing Partner at Ibbaka. See his Skill Profile on Ibbaka Talent.
Pricing and packaging go together. In most of Ibbaka’s work we are asked to design pricing for a packaging architecture and we often get involved in the design of the packaging as well.
The reason for this is that pricing and packaging both turn around value and are based on market segmentation. One designs packages and pricing for a target market segment.
Some definitions used in pricing and packaging
In pricing and packaging there is a lot of terminological vagueness and positioning. Here is what we mean by certain terms at Ibbaka.
Module: An interconnected set of functions to which the six modular operators can be applied; packages can be built up
Package: A set of functionality that is sold together and has a pricing metric and pricing level applied
Bundle: A set of packages and other services that are sold together, often with more than one pricing metric
Platform: An underlying set of functionality that packages requires, multiple packages can be built on one platform
Value Metric: The unit of consumption by which a user gets value.
Value Driver: An equation quantifying one aspect of the economic value of a solution
Value Path: A series of actions taken by a user that results in something of value. Value path completion can be connected to one or more value drivers and is often a good value metric.
Value Model: A system of equations organized using value drivers that estimates the value of a solution for a customer or well defined customer segment
Pricing Metric: The unit of consumption for which a buyer pays
Pricing Model: Pricing Metrics, Pricing Algorithms, Pricing Levels applied to packages, bundles, platforms or modules
Fence: A way to differentiate one package or bundle from another and to guide buyers to a specific package. In many cases value metrics not used as pricing metrics can be used as fences.
Modular Operators: The seven operations one can take on modules to change the modular architecture of a system
Two standard approaches to packaging and how they impact pricing
One of the first questions we ask when working on a pricing and packaging project is
Is there a platform or are modules independent of each other?
This is important to understand as it takes one down different design and pricing paths.
Platform with Extensions
There are two different reasons one may go to a platform with extensions architecture.
Technical reasons, the extensions require functionality or data provided by the platform in order to function
Value reasons, the extensions require functionality or data provided by the platform in order to deliver value
Think of a data-driven application that delivers insights from data. The data then becomes part of the platform and the platform and its extensions provide no value without the data. There are three ways to think about this.
If one began with data and then built a platform (or perhaps an AI model) one has the pattern on the left. If one began with the platform and used in to generate data one has the middle pattern. In either case, the platform and data must be bought together. If the platform and data are independent of each other, and could be sold independently, one has the pattern on the right.
Pricing the Platform and Extensions Model
When dealing with a platform and extension model the first question is whether to price the platform explicitly.
Many companies chose to price the platform. They do this by having a ‘platform fee’ as an annual extension and then additional fees, sometimes subscriptions and sometimes usage based, for the extensions. Or one could reverse this, and have a usage fee for the platform (perhaps metered by calls or service executions) and then subscriptions for the extensions. It is worth exploring both approaches before settling on one.
Other companies bury the platform and only price the extensions. This can simplify value positioning and go-to-market messaging.
Which is the right approach to pricing or not pricing the platform?
Price the platform if and only if
The platform will be sold independent of the extensions
You want to draw attention to the value of the platform
You want to have usage-based pricing for overall usage and not for any one extension
In early stage markets one often prices the platform and offers multiple extensions for free or at nominal prices in order to explore and encourage different use cases for the platform.
As the market matures and extensions are developed for specific industries and use cases pricing often shifts to the extensions. This is often because the platform, any platform, is eventually commoditized.
For an example of this think of databases. Once upon a time the database business was huge and we paid a lot of money for databases. Today most database functionality is a commodity and is available open source. It is mostly paid for through infrastructure services from Amazon Web Services or Microsoft Azure. We now buy various business systems that run on databases.
AI is currently at the early stage of the cycle and the AI systems (platforms) are being priced. In a decade we will not be paying for AI platforms, just the applications running on them. See How to price AI.
Should the platform fee be subscription or usage based?
Usage based if
You can connect usage at the platform level to the value delivered - the value model will help you determine this, are the variables in the value model at the platform level or specific to each extension?
You need a way to capture scaling costs
A subscription if
The pricing of the extensions is usage based (one generally wants a hybrid pricing model that combines subscription and usage)
The value of the platform is relatively stable over time and easy to communicate
Pricing modular applications
With modular applications there is no underlying platform and each module can in theory be priced and sold independently. Modules are generally combined into packages to create offers that provide compelling value.
The basic approach here is to begin by mapping the value paths to models and then building a value model for each module. See what variables show up in the value drivers for each module. Check and see if there are common variables and if there are consider using these as pricing metrics. The advantage of using the same pricing metric across modules is that it makes it easier to construct and price bundles. Most buyers prefer to buy offer with one price metric that is easily summed rather than a complex mix of pricing metrics.
This is not always possible though. Sometimes the modules create value in very different ways and need to be priced differently. In pricing there are always tradeoffs to be managed. The ideal pricing for the module may make bundling more difficult.
From “How to organize an economic value model for use in pricing” by Steven Forth
For example, let’s say I am pricing a cybersecurity application suite that has two modules. One simplifies the administration of email security. The other protects all of the points at which the e-mail server is connected to other applications. These are two quite different value propositions. The first is an operating cost reduction value driver. The second is a risk reduction value driver. They will normally be priced differently. The best practice would be to price the first module through an estimate on cost savings and the second based on the value of risk reduction. These are very different approaches and buyers responsive to cost reduction value drivers are usually numb to risk reduction and vice versa.
But let’s say the two modules are very often sold together to the same buyer. The two different pricing metrics and the different buying and evaluation processes will make this difficult to price. In reality, one value proposition will overwhelm the other and if this is not carefully understood and managed the pricing metric that gives the lower price will be used. In most cases, this will be the cost value driver. The bundle will be perceived to be worth less than the sum of its parts. Solving for this is a key challenge in bundle and pricing design.
Principle: Create packages from modules that leverage value drivers in the same value driver category.
A more hopeful case is when the value drivers for each module are from the same category. Let’s say one is designing pricing and packaging for a marketing automation company. One module optimizes content to bring in new traffic. The other optimizes content across the pipeline, increasing conversion rates. In other words, module 1 helps to fill the funnel, module 2 helps to convert opportunities in the funnel. This is much easier to package. The buyer is likely responsive to both value drivers and one could even create a pricing metric for the bundle that combines the two, such as ‘value of leads converted into Sales Qualified Leads.’
Pricing design should be extensible
At Ibbaka, a good pricing design has the following characteristics. It is
Connected to value
Scalable
Observable
Fair
Extensible
You can learn more here: 5 Characteristics of a Superior Pricing Model
Packaging is especially concerned with pricing that is extensible.
The power of the SaaS model is one of continuous innovation. New functionality, reports, integrations are added at a regular pace. In some cases these are important enough to warrant a rethink of the pricing model. Pricing adaptation should be designed in from the start, but how to do this?
One approach is to think of the pricing model itself as a modular system.
A helpful thought experiment is to ask
What is the smallest piece of functionality that creates value for a user?
What is the smallest piece of functionality I could price.
In general, this maps pretty well to value paths. The most granular pricing one can execute on is completion of a single value path. A value path being a series of actions that results in something of value to a user. Value paths can be combined to create larger networks of value, or perhaps value routes.
An example, I recently helped my wife create a new website for her art and design work. There were many steps in this, but the first value path was completed when I hit ‘publish’ and the website became available. Now there are many paths to take from here. There is content to add, a better information architecture to develop, Search Engine Optimization to implement and perhaps even an eCommerce system. Each of these is a different value path.
Pricing is made extensible through modularization
Modular pricing is an emergent approach to pricing model design that will become increasingly important as we move towards solutions that are configured (often by an AI) to optimize value to customer. These emergent solutions are value-based CPQ and are different from legacy CPQ systems in that they begin with optimizing for value to the customer (V2C).
The roots of the modules pricing approach are in Baldwin and Clark’s classic book Design Rules: The Power of Modularity. In this book they consider six modular operators that are used to move from monolithic systems (and pricing) to modular systems. These rules apply to pricing in two ways.
Pricing models should be open so that as modular operators are applied to a system the pricing can adapt.
Pricing itself can be modular and the seven modular operators can be applied to the pricing model.
Before we go into the modularization of pricing, let’s walk through the seven modular operators.
Seven Modular Operators
We have found the following seven modular operators useful in software packaging and pricing work. Note that this is an extension of the six operators found in Baldwin and Clark.
Create - One has to start somewhere, create a first module and make sure it covers one value path.
Spawn - Each module can be the parent of one or more child models. Going back to out initial question of platforms with extensions vs. modules, the platform can spawn extensions that make specialize the first module. Parent-Child relationships are an important part of software design and carry over into product and pricing.
Delete - Modules can proliferate over time, at some point you need to prune them.
Replace - sometimes there is a better alternative and one wants to simply swap out one module for another.
Split - As modules evolve and more functionality is added one often wants to split an existing module into two or more modules.
Combine - Two or more modules can be combined into one module. This often happens as the value paths are better understood and one realizes that a value path has somehow been split across two or more modules. When this is the case it can make sense combine modules to unite the value path.
Invert - We often assume that parent child relationships, or platform extension relationships are given and cannot be changed. In software this is generally not the case. As a platform evolves it can make sense to change what is seen as the platform. For example, in the past communications was seen as central and applications were built on top on the communications infrastructure. Today, the data, data relationships and data services are often central with communications being an extension or separate module, often provided by a third party.
Key questions for pricing and package design
With each of the seven modular operators come some standard pricing actions.
Create - Defining value for the user and designing the pricing should be part of module creation. This means developing value drivers that can be later quantified and tested. Do not try to choose price metrics until you have developed most of the modules you will have for the initial launch.
Spawn - Ask if the same value drivers are at work in both parent and child modules. This is often but not always the case.
Delete - Note what value drivers disappear when deleting a modules. Check (i) if other modules depended on the deleted module to deliver value (there are often hidden dependencies) (ii) if the value drivers were unique to the module.
Replace - It is often assumed that the new module has the same value drivers as the one that it replaces. Make sure this is the case.
Split - There are two common approaches. Some value drivers go to one module, some to the other. This is the case when one is splitting a modules because it has too many value paths. Another reason to split is to specialize a module, to support different industry verticals for example. In this case the same value drivers will apply to both modules, bu they may get quantified differently (have a different level of impact).
Combine - The default is to combine the value drivers as well. This sometimes works, but in some cases there is a partial overlap and the value drivers will also need to be combined and simplified. In the best cases, the combined module enables new value paths and can add new value drivers.
Invert - When inverting modules in a product packaging architecture one is inverting the platform to extension relationship. The rules for pricing platforms and extensions apply. This operation will generally trigger a major overhaul of the pricing model.
Identify the value drivers as you create or evolve ach module. Wait until you have most of the models before identifying the pricing metrics and designing pricing. The order of operations is as follows:
Map the value paths
Develop the value drivers for each value path
Assign value maps to modules
each module must cover at least one and no more than three value paths
Modules should combines value paths with value drivers in the same value driver category (revenue enhancement, cost reduction, operating capital reduction, capital investment reduction or deferral, risk reduction, increased optionality)
Find a pricing metric for each module
Choose a pricing metric that tracks value metrics (the pricing metrics should use variables in the value model)
Keep to one pricing metric per module
Combine modules into packages for target market segments
Have no more than three pricing metrics per package, one is best
If necessary combine module pricing into a compound pricing metric for the package
Make sure that these metrics track value across scale, graph the value curve and price curve across scale at the component level
Design is exploration
As you plan module and package design explore different configurations. There is almost always more than one way to organize value paths, modules and packages and how to estimate the value at each level. There is a combinatorial explosion of possible models. One cannot explore them all (at least not yet, AI will change that) but one needs to explore more than one. Failing to do this will trap your pricing into a frozen accident.
Modules, packaging and pricing will all evolve over time. Make sure that your approach is open and adaptive.
