Dentists with terrible teeth

Monetising data is hard. Hard to package, hard to price, and hard to operationalise. You don’t have good visibility over what customers are using your data for. Once you provide data to a customer via an API or data feed you lose control. God knows where it is and what it’s being used for. It’s a high entropy product. Like milk mixing in your morning coffee.

Same same but different. Same data, different use cases, different value. Without setting prices that reflect what customers are actually doing with it, it’s very hard to be compensated fairly. This drives another fun challenge for data businesses - customer prices way above and below the official price list.

The Sales cowboys have arrived. And I have sympathy for their pricing creativity. Every customer situation feels like a unique snowflake. Sometimes list prices are far too high for what the customer is trying to achieve, other times too low. So Sales do their thing. Pricing to win deals, and make money. But it’s hard to work out if they are doing a good job, getting the most out of each customer, or just making it up as they go. This ‘creativity’ isn’t limited to pricing, but extends to the product itself.

Data products are malleable in a way that SaaS products aren’t. Customers often only need a specific portion of a data product. Specific fields, granularity, or time periods. But a supplier wants standardised offerings that are easy to operationalise and manage. So there is a miss-match between customer and product that needs to be resolved. As with pricing, Sales can’t help themselves but to ski off-piste, creating Frankenstein data products to meet a specific customer’s needs. This causes havoc for quote-to-cash processes: data businesses are often unable to answer even the most basic questions about their customer base. They don’t know what they’ve sold, entitled, or charged. Sounds unbelievable, but they have the worst internal data about their customers of any business type I’ve worked with. They are dentists with terrible teeth.

A better way

We can’t magic these problems away, but we can move towards a much better world. Firstly, we need to focus on customer use cases, working backwards from the customer rather than forwards from the product. Clarity over what customers use your data for, how they use it, and what value they generate puts us in a much better position to package, license, and price appropriately.

At the heart of the solution lies our ability to build fences between customer use cases, allowing customers to self-select the solution they need, and compensate us appropriately. We can leverage multiple approaches to build effective fences; the most important ones are listed below.

1. How we provide access e.g. GUI
2. What data (fields) we entitle e.g. base data or derived variables
3. What technical features or capabilities we entitle e.g. concurrency
4. What a customer is permitted to use the data for e.g. display
5. Who is permitted to use the data e.g. named users

The most obvious and powerful fence is how access is provided. There’s much less one can achieve with a GUI compared to direct access through an API. However, things fall over if data extracts are permitted out of the GUI, eating into use cases enabled by APIs. A degree of data egress may be inevitable, but allowing too much will be problematic.

Certain use cases may only be possible with specific data fields, or other technical capabilities such as API concurrency. If this is the case, we can configure different flavours of APIs, enabling different use cases, and differentiating prices accordingly. The beauty of this is that customers will self-select which API they need and pay accordingly. It won’t be possible for them to use a low value API for a high value use case as important data or technical entitlements will be missing.

The above examples rely on building physical fences through data entitlements, the access medium, technical features, and so on. It’s where we should start, but unfortunately physical differentiators won't always be available or viable. To be truly effective we need to move beyond the physical to contractual. Successful data businesses such as the LSE, NASDAQ, and LME, leverage creative licensing and the threat of audit to differentiate prices and keep customers honest. If you study these businesses amongst others you will quickly discover common approaches to their licensing, and in many cases common language. The most common license types are listed below.

1. Display license: Permits distribution to colleagues via an internal system
2. Derived data license: Permits data to be used in a formula to create derivative data
3. Distribution license: Permits distribution of data outside of the organisation
4. Non-display license: Permits the data to be used for algorithmic trading
5. Reference license: Permits data to be used as a reference in a contract

In addition to differentiating license types by use case, you will also need to license who can consume your data. Given that you cannot track who is using your data within a customer, contractual mechanisms, although by no means foolproof, are the only practical way forward. For display use cases this would require a list of named direct or indirect consumers of the data, which would then drive the total contract value.

Regardless of the fencing approaches you adopt, you will need to design your product menu thoughtfully, balancing customer requirements and your objectives. An important concept when packaging data assets is the ‘minimum sellable unit’. This is the smallest unit of data that you are willing to sell. Customers are going to push you towards a more granular minimum sellable unit so they can cherry pick exactly what they want. But this drives complexity and small deal sizes. It’s hard to give clear direction on how granular you need to be as it varies by business. Construct a menu you believe is reasonable, and then adjust based on customer feedback and your objectives. However, wherever you land, Sales have to stick to the menu and not deviate without good reason. Otherwise you’ll quickly lose control over your product, pricing, and quote-to-cash processes.

By starting with customer use cases and working backwards, building physical fences, leveraging licensing creatively, and then setting differentiated prices we can alleviate many of the challenges I highlighted at the top of this article. There will inevitably still be challenges you will continue to grapple with, but I promise you’ll be in a much more controlled and profitable place, with happier customers.