Happy Christmas time to everyone, I’ll be off till January, but DbtLabs and their pricing changes made me drop a final issue as an “early Christmas gift”.

If you haven’t heard, DbtLabs announced three things:

doubled pricing on their “small” plans
introduced the tier segments behind their plans
why all of this plays together so well.

Well, I would like to disagree, and hopefully help you learn something about pricing along the way.

🔮🔮🔮🔮🔮🔮🔮🔮🔮🔮🔮🔮🔮🔮🔮🔮🔮

I was expecting DbtLabs to mature in their pricing as the company grows, especially with a CEO that has a great perspective on alignment with the open source project and acknowledged the importance of mechanism design inside companies as his own at least once.

But the new pricing DbtLabs just put out goes against so many things I've discussed in this newsletter, that I thought I'd pick it up and possibly help you to make better pricing decisions.

The price increase feels to obviously wrong because it is a stark contrast to other user based solutions like GitLab or GitHub, and it (still) is very intransparent and limited.

High user based prices means less users. It's that simple. But DbtLabs wants to have more analytics engineers in the world. So there is an obvious problem.

Let's dive into it in two steps:

I'll review the relevant pricing 101 theory applied to this specific context (that's a biggy, but important.)
I'll take three example problems out of their pricing theme.

The relevant pricing 101 theory

DbtLabs has a product built on top of an open source solution. They have a digital product (offering a service really), and they have a vision that emphasizes long term over short term and value creation over value capture.

This informs the basic ideas we need to understand the pricing dynamics...

In pricing theory we distinguish two types of strategies. Cost based pricing takes the cost of a product, and adds a markup (of 20-30% e.g.) to get the final selling price. In value based pricing, we guess the value the product has to the consumer, and then deduct a small margin (say 20-30%) and this is our price.
Pricing should be based on value rather than on cost, because digital products are so called "information products". Information products, e.g. like books, cost a lot to produce the unit number 1, but almost nothing to produce units 2+. The same goes for digital services, offering them has a near zero cost (compared to the costs of creation). If we would price by cost, we could effectively price at close to zero, close to compute & storage + small mark up for running a company.
Consumers of tech products are often quite heterogeneous in their preferences. They all like something a bit different. To put it into other words, given a product, consumers derive very different values from it and thus are very different in their willingness to pay.
To exploit this, tech products often use "tiers". Tiers are small variations of the product meant to address the biggest indicators for "willingness to pay". That come with both, a different variant of the product as well as a vastly different price tag / mechanism.
Products don't exist in a vacuum, they have substitutes. Substitutes are products that are somewhere on the scale of "a consumer would switch my product for product Y if the price difference is sufficiently high (even though product Y might not deliver the same value to him)". For tech companies, substitutes are all around the place, the heterogeneous market make substitutes abundant .
There are two more big substitutes to always consider: Someone else hosting the open source solution and the costumer running the open source solution himself.
=> So, a lot of substitutes! That means one thing for such products: Your price/tier set has to be a tight fit onto the market, quite flexible yet simple or you'll loose tons of value. You do that by picking your flexibility dimensions wisely (compute & storage are always a good candidate to offer as "purchase more for X$$$.” This will make your pricing infinitely more flexible.)
Product design for digital information products. The fun part about digital products is that they are so easy to customize. The fun part about information products is, that they are almost free in production (after unit 1). Bring these two fact together and you'll realize one thing: Unlike for other products, it is not obvious WHAT you actually charge for. You're basically free to charge for any specific aspect/ variation of your product (or not!), as you can easily create variations, and they are mostly free to create.
For open source companies that care about their open source project deeply, "alignment" is an important idea. The idea is simple: If you want to let your open source project thrive, your business decisions have to be aligned in a way that they always grow the business AND the open source project in the long term. No decision can diminish either side.
For the combination of open source project (Dbt) + open source project powered company (DbtLabs) this usually happens through smart mechanism design meaning the company needs to set the incentives inside the company right. Plainly said: If DbtLabs were to pay all of its PMs based on how much customers they would bring in each month, then a smart PM would try to make the OS solution as horrible as possible, thus bringing in lots of locked-in customers to the paid solution.
DbtLabs also operates inside a B2B/ enterprise sales environment. In enterprise sales the fundamental idea is that the transaction doesn't take part between two parties, but rather between the seller (DbtLabs) and a whole "buying center" on the other side, a large collection of people with different roles & different needs, different value perspective. At the very minimum, you will always need to understand that the user is someone different than the person buying the solution, and is also different from the "gatekeeper", usually the Ops & Legal departments inside the companies that also have constraints on you product.
=> The company GitLab uses a vast simplification of pricing theory that should be adopted by every tech company called buyer - based - tiering basically combining the "buying center" idea with the "tiering" mode mentioned above. https://about.gitlab.com/company/pricing/#buyer-based-tiering-clarification
The goal of pricing usually is to optimize long term profit (Revenue - Cost). However, for a company like DbtLabs it needs to incorporate the alignment aspect in a very smart way, making it much harder to move without a clear vision on how the OS <=> business works. Great open source powered companies set up a flywheel for this and communicate it. Examples are companies like GitLab or Automattic that both have figured out a great way on how when the business grows, the open source projects grows AND wise versa. I don't think Dbtlabs has this yet (but I might be wrong, I don't have any internal intel there).

This is a lot of basic theory right? But it's essential to get it right.

Where the Dbt Pricing Model falls short

(1) No buyer based tiering.

From the framing of the pricing tiers, I suspect the DbtLabs team hasn't yet internalized the idea of buyer based tiering. If you look at the three tiers, the target attributes are way off. The pricing page highlights benefits for data/analytics engineers.

The problem with this? The analytics engineers & data engineers don’t actually buy the product, they don’t make purchasing decisions inside companies. This is a classic mistake of focusing on end user benefits where these should play no role at all in your decision to cut tier.

Dear DbtLabs: Rethink your tiers, find the buying persona for each, and remove these banners please. Don't call them "developer, team and enterprise" that's not aligned with your buying personas. Call them "Free" (buying persona: individual developers), "Plus" (buying persona: team lead/head of analytics) and "Supercharged" (buying persona: Executive - CTO/CIO/Head of Analytics,...)

The benefits you want to highlight for the "free" are exactly what you have. But for the "Plus" plan they are not. The team lead wants to enhance productivity, and he might care about cross departmental work, but not about collaboration (a means for greater productivity, but not the only one). The benefits for the "Supercharged" tier are department wide (or even department spanning, if analytics + business is collaborating here) security and compliance, possibly organization. Not control, control might be a mean to achieve these, but not an end.

And while we're at it: Please put a price tag on your "Supercharged" tier. Not having one suggests you're trying to derive 99% of your profits from it, that should already be an indicator your pricing tiers are way off.

(2) Cost based pricing

As discussed above, you can price for whatever you want. You want to value price, not cost price. But DbtLabs sneaks cost-based pricing into the tiering, limiting the team plan to "2 concurrently running jobs". And I have no idea why.

If the compute costs are a true problem, they need to take that out of the equation like everyone else does by providing a smart limit and a way to purchase additional concurrencies (for whatever price).

In the current implementation, they are limiting the abilities of any single data team company to provide fast analytics, and I have no idea why someone would do that. That is the opposite of "value creation over value capture". (In all fairness, I think DbtLabs justifies this with the idea that "single data team companies don't need more speed". That I do think is simply wrong and a complete misjudgement of the degree of heterogeneity of the market).

Dear DbtLabs: I prefer bulk pricing, but if you have to put a limit on it, use compute minutes and let people parallelize the XXX out of their models if they want to. Also add an option to purchase additional minutes of compute for price X (compute price + margin 50%). If your assumption is right, they won't do it anyways. If you're wrong, you capture more value.

(3) Feature scoping gone wrong. Pricing for degree of complexity.

Sadly I feel the mistake (1) goes quite deep. Dbt decided to cut the tiers to "complexity levels" that go (as they say) hand in hand with data maturity. What I think they wanted to say is "there is a correlation between data maturity and complexity", and there is a crucial difference here.

If there is a correlation, you cannot price for it, as customers will be "spread all around it", not nicely aligned (thanks to causation). Using buyer based tiering would already go a long way for this but there are some (selected) obvious things that stand out to me:

DbtLabs decides to put a "one project limit" cap on free & "team" plans. Looking through a buyer based tier you should realize: Buyers are not going to care about how a data team organizes its work. They would like them to be productive, and a method for being productive is cutting your work into as many projects as you like, not just one. DbtLabs thinking falls into a trap because they think that all two-pizza-size data teams only need one project, and that is likely very wrong.
DbtLabs supports GitHub, GitLabs and Azure DevOps only on enterprise plans. Using any of these is a huge productivity boost even for individuals, and it's a great way of getting started with DbtLabs. Even more important: No buyer cares about these features, only about distant possible implications (faster productivity, better data quality through nicely integrated testing,...).
DbtLabs doesn't offer SLAs for the two common tiers, so basically, for a a two-pizza-sized data team, the usual data team in your mid-sized company (with a couple of hundred million in revenue and 200-1000 employees), it's not important whether your dbt runs or not? That strikes me as obviously wrong.

Dear DbtLabs: Please at the very least, take a buyer based tiering approach and rework these features. It's going to bring you more money, more customers and more alignment (IMH prediction).

What did you think of this edition?

-🐰🐰🐰🐰🐰 I love it, will forward!

-🐰🐰🐰 Average newsletter...

-🐰 It is terrible

Want to recommend this or have this post public?

This newsletter isn’t a secret society, it’s just in private mode… You may still recommend & forward it to others. Just send me their email, ping me on Twitter/LinkedIn and I’ll add them to the list.

If you really want to share one post in the open, again, just poke me and I’ll likely publish it on medium as well so you can share it with the world.

Three Data Point Thursday

Thoughtful Tuesday #23: DbtLabs need to grow…