Sounds like a title of a good polar. It is how you should categorize your data points into your API products based on customers’ willingness to pay (WTP).
Leaders are data points that drive customers to buy a data offer. Customers have a high WTP.
Fillers are those of moderate importance or the so called “nice to have” data points.
Killers are data points that will blow the deal if the customers were forced to pay for them.
Here are 15 data points on the axis of the graph.
“Leaders” and “Fillers” are the data points you want to sell, not the killers. The killers should not be included in your API products but can be sold “à la carte” for a few customers. When you know how to categorize your data points, the next step is to bundle them together to create API products.
The strategy is to create 3 packaging offers: the good, the better and the best. This strategy helps to steer customers to a choice based on whether they are price conscious (good option), quality conscious (best option) or somewhere in between (better option).
The basic idea is that 30% of a defined customer segment should opt for the good option while 70% should go for the better and best. The good version has most important data points and the best option has everything except potentially the killers. Each category and the data points included inside must be properly thought out so that there is no cannibalization between the API products.
This mainly relies on the assessment of the willingness to pay that you got from your customer segments for each data point with different potential result to map out the Leaders, Fillers and Killers as proposed. Here below is an example on how to bundle the data points (from figure1) in different API products.
Capturing better the value provided means to blend subscription with alternative/dynamic pricing. To do so, you can set the price of those Good/Better/Best offers to the perceived value of data results for a specific customer segment. As an example, you can create interval conditions for numeric data where you would price differently the data results. All this is based on your first analysis on the customers’ willingness to pay. However, even if this is advantageous for data buyers to pay on performance, they might want to be able to predict their costs. Therefore, a good way to address this need is to cap the amount they would pay introducing budget pool for each subscription. This budget is going to be consumed differently based on the value and result of data.
Here is an example of how to do that based on the predefined Good/Better/Best offers without budget set up.
And here is an example of setting up a budget pool tied up to a price for those offers.
The options should not be overwhelming per customer segment. Once you go over nine benefits for four subscription options, your product configurations and bundles run the risk of exceeding psychological thresholds. Your product will start making customers heads spin and you will be heading toward producing data options shock. Therefore, when creating your API products, you need to make it simple but at the same time build clear upsell path from one API product to another one.
Once you have created your offers for your customer segments, it is not over. You need to keep an eye on how it resonates with customers over time. When subscription is involved, 70% of the revenue comes from renewals, updates, upsells, cross sells so you need to revisit your API products regularly.
You need to come back to your strategy regularly based on the company’s objectives and granular usage information of your API products. However, this is not a one size fits all strategy. Customers will have some specific requests as well asking to get specific data included in their API products.
The subscription economy triangle shows well the tradeoffs you will have to make, depending on which criteria are the most important to reach your objectives. You need to keep thinking about the three objectives (More customers/More Money/Retain customers) when building your API products and monetizing them. Your API products are not written in stone once for all. They need to adapt continuously to the needs of your customers and your company’s objectives.
On top of API products definition, business models and pricing you need to think from the start about building APIs where the path to value for your customers is fast and convenient. It means that you must have extremely well designed and documented your APIs.