Value pricing for Dev Tools: a strategy beneficial for both sides

I became interested in the topic of “value pricing” when we started working on a new pricing strategy for AnyCable Pro, a commercial version of our popular open source tool.

At launch, we just went with a fixed price for the sake of simplicity. But as we continued working, expanding into new frameworks, and building a SaaS (which is in beta, and not announced yet!), the need for a better pricing model was clear.

At this point, I started to notice pricing discussions all around me; both from our devtools clients, and friends building for engineers. All of them seem to be struggling with the same question and looking at the issue from different perspectives. So, I started to dig into the problem and found a fundamental solution: value pricing. This is a strategy where the price of a product is derived from the value the product creates for the customer.

Illustrating with an example

We’ll say that I’ve paid $1,000 for Figma over the course of a year, and my team of 5 uses it for our client projects. This tool improved team productivity, saving us 2 hours per week (or 100 hours per year). Now, let’s assume that one hour of work from our organization is worth $100. So, since we were able to save 100 hours that year we can calculate as follows: 100 * $100 = $10,000. We saved $10,000 and paid 10% of that amount back to Figma.

Now, let’s imagine that Figma releases an AI tool that could save the same team 5 hours per week–the value saved grows to $25,000, and we’d be more than happy to share more, say $2,500, with Figma.

At the same time, if for some reason we decide to stop actively using Figma for client projects and our value creation with it drops to 0, we’d expect to see no charges on our bank account.

If all of the above happens without renegotiations, in an organic and predictable way, that means that Figma has value pricing.

Why value pricing matters

Value pricing stands out because it can maximize an organization’s revenue since pricing can be adapted based on the peculiarities of each customer.

In terms of economic theory, different customers value products differently, and customers who value the product higher than its price are ready to purchase it.

As an example, let’s say there’s a ring in an antique shop that’s attractive to different customers for different reasons. One person wants to melt it down and they view it as a certain weight of gold, perhaps $50. Another person likes the ring’s design so much that they actually prefer and value it over some other ring which would cost them $150. And finally, you’ve just found out this is your grandmother’s family ring, and so you’re ready to pay up to $5,000 for it. Even though the ring is the same, its value varies a lot for different customers!

By definition, value pricing is offering a product to each customer at exactly the price that equals their estimated value of the product.

For professional tools, this is the value the product generates for an organization. Below, we can see the charts comparing the revenue for value pricing vs. flat pricing). Clearly, value pricing can maximize revenue, as it can fill the entire area under the demand curve.

This is so important because in the developer tool market, we can offer the same product, copied to a new customer at very low marginal cost, but within that organization, this same product can generate value that differs by many orders of magnitude. A freelance engineer can generate $100 worth of value, but an enterprise organization can see millions of dollars in cost savings or productivity improvements.

What if you could recognize this value and offer each client a unique price–one that would make all of them say “yes”, while also giving you a fair share of what you’re helping create? Doesn’t that sound amazing? Value pricing makes this possible!

Deeper into value pricing

Value pricing also does something even more important: it aligns product quality with business results. Every experienced founder knows that scaling a successful business is all about setting the incentives across the organization, not about knowing all the right answers from the get-go. And what are the right incentives for product development?

Without getting too much into theory, let me just say that quite often, our pricing models, channeled through the org structure, ultimately incentivize efforts that drive client acquisition at a disproportionate level compared to efforts growing value for existing customers.

However, when our pricing is tuned to value creation, our incentives are unbiased: if $1MM can be invested to generate $20MM by increasing the value for existing customers, but would only generate $5MM acquiring new clients, the right investment decision will be made. Don’t underestimate the need for this alignment in product organizations!

Note: we need to keep in mind that value pricing is a theoretical ideal–in practice, it cannot be achieved in full, but it can be approximated, or tracked, with different pricing models and processes–and we’ll talk about that later. But let’s start with understanding this theoretical ideal.

Are you there already?

But before we begin, you might be wondering if you already have value pricing in place.

Here’s a simple test: imagine you’ve made a break-through and now your product creates significantly more value for your customers. Will this be reflected in your billing, without renegotiations, in a predictable way?

To contrast, what if your product stops generating value for some of your clients–do you stop billing them?

If the answer to both questions is yes, then you have something that’s at least very close to value pricing.

Understanding value creation

In developer-facing products (as well as any other professional tools) value is created within a customer organization; typically this value falls within one of the following categories:

• Productivity gainers that save time, improve efficiency, eliminate wasted time, automate work, improve decision making, and so on.
• Cost savers that cut infrastructure spending, SaaS expenses, including savings potential and estimated costs and risks, including legal, and so forth.
• Revenue drivers that supply clients, increase revenue metrics (conversions, LTV, retention and others), improve sales channels, etc.

It’s easy to think about products focusing on developer and team productivity, as it seems to be the largest category of technological products overall. This makes sense: no resource in tech costs more than talent and the team’s productive time is precious indeed.

However, the resource savers category includes products like Clickhouse and Elastic. Vast majority of infosec tools would fall into this category, because they minimize potential legal and remediation expenses (in case a security breach is exploited).

Finally, revenue drivers are platforms (Shopify), marketplaces, payments providers (Stripe), CRMs, analytics tools, and any products that at the end of the day help drive customer’s own revenue.

Observing and measuring value creation

Now that we understand how value can be created, let’s try to observe and measure it, so we can feed this information into our pricing model. In most cases, we cannot measure this directly, but we can estimate value creation. How?

Start by talking to your loyal customers with the goal of learning enough about their business to understand how your product creates value within their organization.

Then, ask how they would estimate this value themselves. To illustrate, we once had an enterprise customer that was looking for a CI speedup project. Together, we came up with a thorough analysis of value creation, or, in common business terms, an ROI.

Here’s how we got that: the client had a ballpark idea about the cost of an hour of engineer’s time. Using a cautious estimate for the percentage speedup we could expect from this sprint, we arrived at the number of hours saved for the whole team over the course of a year. Then, multiplying by the cost of the hour, we arrived at the savings amount in dollars. Dividing this by the amount of investment into the project, we got the ROI.

For us, this was a valuable real-life example on how a company might view our work in terms of value creation. Importantly, CI speedup work also saves compute resources, i.e. the cost of CI itself, but these savings are orders of magnitude lower than a team’s precious time.

Note: be ethical and openly state your intentions; value pricing is beneficial for both sides.

Once you have an idea of how to estimate the value your product creates from the perspective of a customer’s business, you can determine how you and your customer can both track this data. What metrics are missing from your product to estimate value creation, however roughly that might be? It can be the case that, by redesigning the product, its delivery mechanism, or its operational mode, you can greatly improve observability of value creation.

For example, perhaps your product is generating a ton of value by, say, increasing developer productivity in certain scenarios. However, because it’s a tool being run locally by each engineer, no one can collect or access any data indicating productivity gains.

In that case, the observability of value creation is an issue that could be solved by building a cloud version of the product, or even an “admin” dashboard dedicated to tracking productivity and other useful metrics for company-level decision makers.

Note that for every product, certain data is available almost organically–but this doesn’t mean this data is the best source for value approximation. For instance, if you’re building a payments SaaS, you naturally have transaction data and, thus, revenue data. But if this product is actually built to improve the productivity of accountants, rather than drive revenue, that data will not help much in terms of value pricing.

Finally, it may be that for different customer segments, data creation falls into a different category and needs different observability metrics. For example, startups and SMBs may see productivity gains from a tool, while larger enterprises achieve huge resource savings from the same product. Likewise, in this case, we should apply different observability metrics and pricing models to different segments of customers.

Pricing models

Now, speaking of pricing models, let’s consider the practical categories of pricing models and the cases where they can work to approximate value pricing.

1. Fixed price: fixed price per month or per year is the most simple model to kickstart your sales with. Hardly anything is worse in terms of value pricing, but it works well at the beginning while you still know little to nothing about value creation in your customer organizations. (There are also some new ideas in this space worth looking at, like the recently launched Once from 37signals.)

2. Per seat: this model can be a really good approximator for value pricing of productivity gainers, because an increase in productivity will normally happen for each active team member. Understanding the nuances of value creation will help you design this pricing model correctly, to include only active users, downgrade them automatically, and care about only charging when value gets created. It’s also worth mentioning that this is currently the go-to pricing model for most SaaS.

3. Usage-based: resource savers can track their value creation, which comes in the form of cost savings, with usage-based metrics, like the total number of assets or requests processed, concurrent and peak connections, server instances, and so on.

4. Revenue-based fee: if the product directly contributes revenue or profit generation, i.e. if it is a revenue driver, then it’s best to price it as a % fee from that revenue or profit. The big problem is that only certain products will be able to observe revenue created with the help of the product, but I want to argue that this model is underutilized for tools like CRMs, for analytics and marketing products.

5. Pricing tiers: finally, tiers often separate types of customers with different value creation models. For example, enterprise customers have an entire layer of value creation related to security (SSO/SAML support, audit trails, external integrations, custom security procedures, and so on). The value is in saving on any future cost of mitigating incidents, data leaks, legal cases, etc. The size of this risk is often linked to the number of people in the organization that have access to sensitive resources, and so per-seat model will likely fit best here. But I encourage you to do your research and understand how value gets created for each segment of customers in your particular case.

Any pricing model is good only to a certain extent, within a certain context, and by a certain degree.

In addition to a pricing model, you also need to have a value discovery process in place, where you continue to investigate and observe value creation in customer organizations, and make adjustments to your models and metrics as appropriate.
In light of the current pace of industry changes, from AI to the entire ecosystem of professional tools, you may want to check and re-adjust your understanding of value creation not once, but several times per year.

Setting new pricing

Now, you’ve done a great job and got the shining new pricing model in your hands. What else can we say? Well, this is just the beginning! Rolling out a new pricing is risky, as we know from examples across the ecosystem (think Docker) and in the wild. Luckily, we’ve got an article that can guide you around major pitfalls, so give it a read next!