Design your pricing and tools so you can adapt them later(arnon.dk)
arnon.dk
Design your pricing and tools so you can adapt them later
https://arnon.dk/design-your-pricing-and-tools-so-you-can-adapt-it-later/
29 comments
This seems like a nightmare for the financing department. Not to mention, it really complicates (even tarnishes) the simplicity of the product for consumers. They should be able to infer how much a product costs without any mathematics or memorization
Aws would like a word
I once worked to automate billing for a on-prem-ported-to-"SaaS" product, and though it had a seemingly simple billing model ("pay $ per thing monitored per month", with $ negotiated per-customer) the reality turned out to be we had about distinct 80 SKUs. This was one of those products where the pricing page said just "$call_us".
All of this was being handled by the billing dept using a combination of the accounting software, spreadsheets, and manual effort (ie: insane). No one actually realized we had this many SKUs until we started technical requirements gathering.
What was happening was sales had some freedom to write terms, and so write terms they did. Things like "price per month is $x as long as there are y things after 6 months, otherwise the price is $z", "$x for the first 1000 things, $z for the next 5000, etc" or "$x per quarter in advance with a minimum of $y", exactly as stated in the post above. Billing in advance was one of the worst: it required manual adjustment afterwards to reconcile with reality, while dealing with minimums and date-limited exceptions.
On top of that, there were 6 different ways of even counting "things monitored" since it could vary, including: peak distinct per month, peak concurrent per month, # at the end of billing cycle (sometimes calendar month, sometimes anniversary day). And for very old plans, it could just be a fixed # written in the contract (which was also a max enforced in software).
Any one or two of these isn't a huge deal, but it was the combinations that was killer, especially since it was very much a long-tail: most of the SKUs only had a small number of customers, and many had 1 (though some of these were the biggest customers). To automate billing, we'd have to implement and test each, of course.
Billing found this tedious but just accepted this as the way things were. Sales just did what they'd always done. C-suite was happy we were growing. The meeting where we presented the 80 SKUs to the CEO and CFO was definitely an interesting one - they were ultimately responsible for approving all the deals that caused this mess, but were also who asked us to automate billing. The entire project was put on hold to first migrate down to a much smaller number of plans, and that's when my involvement stopped (It was deemed more cost effective to continue billing manually than to divert the dev team to spend the time on this). I don't know how far along they got.
My take-away was to at least think about automating billing early, just to avoid this explosion of SKUs problem.
All of this was being handled by the billing dept using a combination of the accounting software, spreadsheets, and manual effort (ie: insane). No one actually realized we had this many SKUs until we started technical requirements gathering.
What was happening was sales had some freedom to write terms, and so write terms they did. Things like "price per month is $x as long as there are y things after 6 months, otherwise the price is $z", "$x for the first 1000 things, $z for the next 5000, etc" or "$x per quarter in advance with a minimum of $y", exactly as stated in the post above. Billing in advance was one of the worst: it required manual adjustment afterwards to reconcile with reality, while dealing with minimums and date-limited exceptions.
On top of that, there were 6 different ways of even counting "things monitored" since it could vary, including: peak distinct per month, peak concurrent per month, # at the end of billing cycle (sometimes calendar month, sometimes anniversary day). And for very old plans, it could just be a fixed # written in the contract (which was also a max enforced in software).
Any one or two of these isn't a huge deal, but it was the combinations that was killer, especially since it was very much a long-tail: most of the SKUs only had a small number of customers, and many had 1 (though some of these were the biggest customers). To automate billing, we'd have to implement and test each, of course.
Billing found this tedious but just accepted this as the way things were. Sales just did what they'd always done. C-suite was happy we were growing. The meeting where we presented the 80 SKUs to the CEO and CFO was definitely an interesting one - they were ultimately responsible for approving all the deals that caused this mess, but were also who asked us to automate billing. The entire project was put on hold to first migrate down to a much smaller number of plans, and that's when my involvement stopped (It was deemed more cost effective to continue billing manually than to divert the dev team to spend the time on this). I don't know how far along they got.
My take-away was to at least think about automating billing early, just to avoid this explosion of SKUs problem.
One solution to this is "monthly bill amount = {per-client python program}".
When a customer comes along that needs really bespoke billing, you go write a few lines of python to implement it. "bill us only on the full moon" becomes very possible.
Make a few library functions for common plans/special offers, and the maintenance burden becomes manageable.
When a customer comes along that needs really bespoke billing, you go write a few lines of python to implement it. "bill us only on the full moon" becomes very possible.
Make a few library functions for common plans/special offers, and the maintenance burden becomes manageable.
> My take-away was to at least think about automating billing early, just to avoid this explosion of SKUs problem.
Agreed that you should be thinking about this, though it might be fine not to do anything about it. I think this is analogous to tech debt (at risk of opening another can of worms).
If you don’t know you have debt, you are doing something very wrong. On the other hand, if you consciously decide that short-term growth is what you need, some debt can be appropriate; just don’t forget to pay it down before it compounds out of control.
Agreed that you should be thinking about this, though it might be fine not to do anything about it. I think this is analogous to tech debt (at risk of opening another can of worms).
If you don’t know you have debt, you are doing something very wrong. On the other hand, if you consciously decide that short-term growth is what you need, some debt can be appropriate; just don’t forget to pay it down before it compounds out of control.
I agree the scheme seem too rigid.
When I'm helping someone with their pricing structure, I look for two things:
- is it structured to find the ceiling (the maximum any individual customer will pay)
- is it structured to find the right price for each individual customer
We might settle on a fixed price for any number of reasons, but we shouldn't start there, and turning every combination of customer and price into a SKU is usually unnecessary.
When I'm helping someone with their pricing structure, I look for two things:
- is it structured to find the ceiling (the maximum any individual customer will pay)
- is it structured to find the right price for each individual customer
We might settle on a fixed price for any number of reasons, but we shouldn't start there, and turning every combination of customer and price into a SKU is usually unnecessary.
Could have a SKU for an "ad-hoc" or flexible price
This approach has a lot of similarities to PriceOps [1] in terms of goals.
I don't see why you want to avoid grandparenting. If the pricing model [2] is versioned and immutable, then keeping customers on their existing Customer Schedule [3] and then using specific migrations to move customers to new schedules makes sense and is easier than either not doing anything, or trying to track customer specific discounts and the accounting related to that.
1: https://priceops.org/
2: https://priceops.org/1-model
3: https://priceops.org/2-schedule
I don't see why you want to avoid grandparenting. If the pricing model [2] is versioned and immutable, then keeping customers on their existing Customer Schedule [3] and then using specific migrations to move customers to new schedules makes sense and is easier than either not doing anything, or trying to track customer specific discounts and the accounting related to that.
1: https://priceops.org/
2: https://priceops.org/1-model
3: https://priceops.org/2-schedule
Ooh I didn't know about this. There's quite a bit of overlap!
> It’s very probable that you will need to change your pricing and feature packaging.
Citation needed? In my experience it's very probable your startup goes out of business before this is ever a concern.
Building around future pricing seems like premature optimization for me.
Citation needed? In my experience it's very probable your startup goes out of business before this is ever a concern.
Building around future pricing seems like premature optimization for me.
The problem is that it's very chicken and egg. You want to build enough flexibility into the system to support the next step you are looking to take while not introducing so much complexity that you end up not doing the things that deliver value to the customer.
That said, I've been in the situation where there were 50+ "billing plans" and who knows how many custom plans in order to support some lighthouse customers... It was not a fun experience and the move to an entitlements system was painful. If you start from the idea of entitlements/feature flags/etc separate from the billing logic, you can save yourself a ton of heartache later.
That said, I've been in the situation where there were 50+ "billing plans" and who knows how many custom plans in order to support some lighthouse customers... It was not a fun experience and the move to an entitlements system was painful. If you start from the idea of entitlements/feature flags/etc separate from the billing logic, you can save yourself a ton of heartache later.
That is exactly my experience, but we stopped it before it became a problem. We only had 5 plans and we didn't do too many "custom plans" until we had the system in place.
Once it was in place, we moved everyone into normal, supported situations.
Once it was in place, we moved everyone into normal, supported situations.
Startups often underprice their products/services. They discover pricing improvements through experiments, experience and willingness-to-pay surveys. Some try advanced techniques like bundling products.
All of the above benefits from flexibility.
One could argue the opposite of your assertion: startups may fail because they dont change their pricing and packages.
Here’s a citation on underpricing: https://www.ycombinator.com/library/7M-most-startups-are-und...
One could argue the opposite of your assertion: startups may fail because they dont change their pricing and packages.
Here’s a citation on underpricing: https://www.ycombinator.com/library/7M-most-startups-are-und...
Yes, I know a startup where the difference between failure and becoming a multimillion dollar company was just in the pricing model alone. Their initial pricing put off most customers, then they changed it and kept the product the same and they got the usual hockey stick growth.
Before it goes out of business, you will spend some frustrating amount of time playing with pricing or giving discounts to customers when you will wish desperately that you had a simpler (more structured) way of dealing with pricing than just going into various parts of the code all the time.
Many startups will go out of business because they don't address this concern.
Startups have extremely little information to guide their pricing and packaging decisions, and often find right away that they've just picked the wrong way to monetize.
An optimal solution makes it easy to build a flexible system, so that it can change rapidly as new information becomes available.
Startups have extremely little information to guide their pricing and packaging decisions, and often find right away that they've just picked the wrong way to monetize.
An optimal solution makes it easy to build a flexible system, so that it can change rapidly as new information becomes available.
But the point of pricing flexibility is that you want to get your MVP out as soon as possible. How are you supposed to do that if it is difficult to change your pricing in the future? If you commit yourself to a price you are going to have to price it as a finished product and then add discounts for early adopters.
I've advocated this practice for most of this century. The only place it didn't fit was a global behemoth who (for the areas where I was involved) had consolidated all the billing/entitlements/etc into one bucket. They sold one thing, priced in one way, end of discussion, across many hundreds/thousands of product areas.
It didn't seem to fit as well with smaller businesses and startups for whatever reason.
The global behemoth is vast and authoritarian, so the model was simply not up for discussion and customers largely didn't have alternatives. The smaller companies were constantly discussing ("negotiating") models, and customers had alternatives, but would a "This is what we sell, this is how it's priced" model have worked if anyone had committed to it? We never found out.
It didn't seem to fit as well with smaller businesses and startups for whatever reason.
The global behemoth is vast and authoritarian, so the model was simply not up for discussion and customers largely didn't have alternatives. The smaller companies were constantly discussing ("negotiating") models, and customers had alternatives, but would a "This is what we sell, this is how it's priced" model have worked if anyone had committed to it? We never found out.
This article seems to apply to countries without inflation. In countries with inflation you don't grandfather any customers at all. You increase the prices to keep with inflation: sometimes you give them two-months notices (one month notice is required by law here), but if you don't plan carefully, the price may be outdated after two months and you need to increase again.
You can do that by replacing the price object 1:1 with a new price and perform a mass migration.
The core concept still works :)
The core concept still works :)
[deleted]
[deleted]
Thanks arnon.
This makes lots of sense for software. Did you change SKUs based on changing pricing for hardware? If so, did this confuse or annoy 3rd party logistics providers who were asked to change labelling on boxes and have different SKUs for the same product?
We never needed SKUs for our "hard products" that we sent out so we never encountered this...
I’m not persuaded this approach makes sense. When you don’t grandfather early adopters but instead migrate them to a new SKU with a discount you’ll inevitably make billing mistakes, but also, you’ll confuse people when their invoice changes from month to month even when the total charged is the same.
If you just keep your initial billing logic very simple you can change it when needed as you discover what direction you want to take your business into. Having customers on legacy SKUs is only mildly annoying, and it’s not hard to segment all accounts on creation date, for instance, if you want different billing logic for legacy accounts. But you can do that after you’ve figured out what works with some experiments.
If you just keep your initial billing logic very simple you can change it when needed as you discover what direction you want to take your business into. Having customers on legacy SKUs is only mildly annoying, and it’s not hard to segment all accounts on creation date, for instance, if you want different billing logic for legacy accounts. But you can do that after you’ve figured out what works with some experiments.
Separating entitlements from SKUs makes a lot of sense and definitely saves a lot of engineering edge case nightmares around renewals.
It also gets super messy after a couple years of pricing iterations. Eventually your plan distribution doesn’t reflect feature access which doesn’t necessarily reflect feature usage. Future changes to optimize packaging only have limited impact because it’s so hard to tie back who has each entitlement and why.
IMO it’s super important to document the WHY every time a customer’s entitlements are separated from their plan (especially if an account mgr will ever be involved in a renewal). Also periodically undoing extra unused entitlements helps to keeping things clean.
It also gets super messy after a couple years of pricing iterations. Eventually your plan distribution doesn’t reflect feature access which doesn’t necessarily reflect feature usage. Future changes to optimize packaging only have limited impact because it’s so hard to tie back who has each entitlement and why.
IMO it’s super important to document the WHY every time a customer’s entitlements are separated from their plan (especially if an account mgr will ever be involved in a renewal). Also periodically undoing extra unused entitlements helps to keeping things clean.
In the system we built, we had a "reason" field, and we would regularly audit these and clean up old rules.
Great stuff! Wish I knew about this before spending a year building a billing system.
Any idea that the CEO/business folk come up with should be implementable. You never want your tech limitations to be stopping you implementing a pricing scheme.
In that light, you want to be able to set any product to any price any time. You might want to let existing customers keep the old price. You want to be able to give existing customers one-off credits or charges, or discounts for a given number of months.
You want to be able to do the same for other features. For example, credit a customer a certain number of gb's or minutes. Or a group of customers.
You need to be able to do 'if then' pricing. eg. If you have more than 8 synced devices, you automatically get 99 more gb's.
You need to be able to do pricing depending on other customers. Eg. "if you refer 3 friends, and they all verify their account, you get a credit of $10, but it must be spent within 3 months"
You need to be able to 'undo' mistakes (ie. retract an invoice), but you also need to be able to re-issue a now-corrected invoice. The rebilling might need to use the pricing/discount structure present at the time of the original invoice, or it might need to use the current pricing structure.
There is no simple way to achieve all of this. You will end up with a mess. Just embrace it and move on.