THE PRODUCT

Key decisions

The earlier pricing strategy and monetisation is discussed, the better. Your pricing and monetisation strategy is particularly relevant to two key product development decisions:

deciding which features should be built, and
deciding how to package/configure those features for your customer segments.

Feature prioritisation

The features you build should ideally contribute to profitable growth. In Gibson Biddle’s DHM model of product strategy, he advocates for product leaders to ask “How will your product delight customers, in hard-to-copy, margin-enhancing ways?”. Product managers should be thinking through whether the features they build are margin-enhancing. If not, then engineering time might be better spent elsewhere.

Where investment decisions are not binary, it’s necessary to balance different levels of investment with the expected outcomes. You will always have competing demands on your product budget, so each improvement should be assessed on the basis of how much customer satisfaction (improved NPS, signups to extra services, recommendations and good reviews etc.) it will achieve for each unit of investment committed. This is particularly true because a customer’s willingness to pay will not increase linearly or forever in response to improvements in a particular dimension. For example, customers are willing to pay more for a larger TV, but there is a limit after which larger TVs become impractical, attract only a niche set of customers and the cost of production increases exponentially beyond what customers are willing to pay.
‍

Product packaging

SaaS businesses have tremendous flexibility in how they configure and package their propositions for customers. It costs nothing to switch features on or off depending on what customers need, therefore it is possible to configure the proposition to meet the needs of different segments very efficiently.

There are two major tasks when designing suitable packaging:

deciding on the packaging strategy, and
deciding how to allocate features across packages.
‍

Packaging strategy

There are a finite number of packaging approaches a SaaS business can pursue which we’ve outlined below. In principle, a business should pursue a packaging approach which allows it to best meet the needs of its customers, reflecting segments as defined by the customer segmentation model. There should be a natural alignment between customer segments and packages.
‍

All-inclusive: There is just one package version where all customers get access to everything. Here, there is no differentiation between customer segments and no opportunity for up-sell or cross-sell.

An all-inclusive approach may be appropriate if you are very early in the product life cycle e.g. when trying to find product-market-fit for a very narrow subset of customers. It will, however, make it very difficult to de-bundle functionality in future for existing customers who thought they were getting everything for a fixed price.

Good-better-best: Multiple package versions where you create an objective and unambiguous ranking of the packages based on the value offered. Typically, features build on one another, where each package offers all the features of lower-ranking packages, plus a set of desirable further benefits.

GBB is the most widely and frequently used approach, due to its versatility. It works especially well where customers are similar in the problems they are trying to solve and are willing to pay more for additional capabilities.

It’s also instinctively easy for the customer to understand a proposition when the product itself is what differentiates price points and thus their willingness to pay.

A good example with which we are all familiar is the business class plane ticket vs. an economy class ticket. Fundamentally, both tickets get us from A to B, but there are many more benefits bundled with the business class ticket, which in turn justifies the higher price tag and margins.

Use case/persona: Here, there are multiple package versions where each is designed to solve a specific set of problems or meet a particular set of needs. You can think of this as ‘offering the right tool for the right job’. In this structure, packages could not be force-ranked even if they have wildly different prices – because the value of each package is defined by its target audience.

This approach is especially well suited to scenarios where needs between segments vary considerably. For example, the administrator version of a SaaS platform may have very different features when compared to those required by standard users. It would be inappropriate for an administrative user to use the standard version and vice versa.

Functional/modular: The proposition is organised into functional modules that serve a specific purpose. This differs subtly from the use case approach in that instead of aiming packages at personas, packages are organised around desired functionalities and workflows. In the use case scenario, one package has been targeted at the user (because you will have done a great job of segmentation!) and so they will purchase that one package. In the functional/modular scenario, any number of modules may meet a user’s needs.

That’s because this approach works well where your solution offers an end-to-end workflow, but where customers may want to pick and choose which aspects of their existing workflow they would like to replace with your solution. You would not want to force a customer to replace an aspect of their workflow they want to keep (or to change their entire process in a painful ‘big bang’ refresh) as it would likely be a big enough hurdle to kill the deal.

Build your own: As you would expect, here customers can customise their package based on what they need up-front. This approach may be relevant where:

customer needs vary significantly,
there are few key patterns as to how customers consume features,
there are cost implications to many of the features
the product is especially complex and/or the buyer is especially technical.

This is not an approach seen often, because it’s complex to execute; for customers it is pretty hard to justify and communicate differentials in price; and it is generally suboptimal for most businesses.

Consumption: This approach may be thought of as a “platform plus additional features and services” which can be consumed and paid for at the point of need.

It differs from the all-inclusive approach in that the customer is not required to make an upfront commitment but simply uses what they need, when they need it, and pays for it accordingly. It’s an approach we expect to see more of as customer success organisations continue to mature, and as consumption-based charging models become better understood.

There are, of course, further emerging hybrid models where customers pay a core SaaS/subscription fee for basic functionality plus pay-as-you-go for extras.

This approach is particularly appropriate for businesses with strong customer success organisations and complex propositions where users need to be guided to the right feature and up-sold it at the point of need. It’s also well suited to a “land and expand” approach where you intend to demonstrably link revenue growth to customer outcomes.

Add-ons: Add-ons sit outside the core packaging structure, and work well with any of the approaches discussed above. They allow buyers to customise aspects of their purchase (and in so doing, increase engagement with the product and commitment). This works very well for niche, high-value features which don’t obviously fit into any of the defined packages.

One strategy used very effectively by the automotive industry is to launch and monetise newly developed features as add-ons, before rolling them into the base models over time. This provides up-sell opportunities for novel features in the short term, whilst keeping the portfolio simple as new features are released.

Remember: It's key to work backwards from the customer, selecting an approach which is appropriate for your customer base, your business's commercial objectives, go-to-market strategy and product maturity. These decisions are also not static and should be reviewed and adjusted over time as you release new features; and as customer and competitive dynamics evolve.

Feature allocation

Once you have decided on your overall package approach, it’s time to allocate features across package versions, and/or indeed to position some features as add-ons.

Two simple profiling exercises will support these decisions. Both can be done internally and then validated through customer research. In both cases, you will need to collate a comprehensive list of all product and service features (and consult your ongoing development roadmap, too).

Must-have/like-to-have/don’t want
Profile each feature based on whether it is a must-have feature, a feature which customers would like but could live without, or whether it's a feature they do not want. This can be repeated for each customer segment to produce a fully segmented view if required.

Adoption and willingness to pay
A more powerful approach is to profile each feature based on the expected adoption of the feature and customers’ willingness to pay for it. This profiling can then be plotted on a graph and simple heuristics applied to give you an instinctive go/no-go on each feature.
‍

High adoption and low willingness-to-pay features should be included in all packages as standard. This would also have been reflected in the must-have profiling.
High adoption and high willingness-to-pay features should be included in premium versions of the product. They may also be included as standard in order to support a higher-priced customer entry point.
Low adoption and low willingness-to-pay features could be prime candidates for rationalisation. If we apply the DHM model referenced earlier, there could be a strong argument for sunsetting the feature as it neither delights customers nor is margin enhancing.
Low adoption and high willingness-to-pay features may be ideal add-ons. Equally, it may be appropriate to include them in a premium version of the product. If adoption is focused on a particular segment, including it in a package aimed at that segment may be the answer.

References
Gibson Biddle: How to define your product strategy