Monday Price Point:​
I was emailing back and forth with a product leader inside a Fortune 100 company when she mentioned that 'SKU Spaghetti' was an issue.

I loved this term (I used to call it 'SKU creep', but 'SKU Spaghetti' is just a better term. You know who you are - thank you!).
​
Basically it goes like this:
1) You have great packaging.
2) Product ships a lot of features
3) 'The Business' wants to monetize those features.
4) Features are spun out as new add-ons, modules etc (= SKUs).
​
So far so good. What's the harm in that?
​
Well, this:
5) Sales has to spend CAC pushing the new SKUs to the customer base.
6) No SKU gets 0% or 100% attach rate
7) = Product & Dev have to manage the configuration option of a customer solution having - or not having - said SKU.
8) As customer solutions get more complex and with larger variance it produces more errors - both bugs and human / UI errors.
9) CS teams handle more errors AND spend more time understanding each error.
​
And then, when you hit Maximum SKU Spaghetti after about 8-12 years of fast paced feature shipping:
10) Monetisation drops, as customers are under-solutioned as Sales can only talk about so many SKUs
11) Technical and Commercial debt weighs down both Product, Dev, Sales and CS to the point where a newer and sexier product starts eating market share.
​
So: lower ACV, higher CAC, higher technical debt, higher operational load of handling existing customers.
​
All of this is seriously bad and slows down growth - both on new logos and on expansion.
​
Product can be complex enough in itself - that is not the issue here.
​
The issue is the specific act of wanting to sell a feature/bundle of features as a standalone piece of packaging that leads to SKU Spaghetti.
​
It's a commercial problem (monetization) that is solved with adding packaging complexity.
​
And it arises when the accumulation of small local decisions ('we want to monetise this feature!') leads to an overall global imbalance ('SKU Spaghetti').
​
How to do it:
If you want to avoid SKU Spaghetti, you have to get these two things right simultaneously:
​
1) Outcome Based Packaging:
Have each SKU represent a clear outcome or Job To Be Done for the customer.
​
Then: when Product brings a new feature you ask: "Does this new feature support an Outcome for which we already have a SKU?"
​
If the answer is yes: the new feature is simply added into an existing SKU.
​
If the answer is no: you have a net-new innovation and you can go ahead and create a new SKU to sell.
​
But in 98% of cases a new features is supporting an existing outcome and should simply be included into something already sold.
​
Which leads us to the second thing you must get right
​
2) Flexible Contracts:
If you are taking 98% of new features and stuffing them into existing products (e.g. making existing products better as opposed to creating new ones) then the only way you can monetize is by...
​
You guessed it: raising prices.
​
Which is hard if your contracts don't allow that change or make it dependent on customer approval.
​
Good SaaS contracts allow you to change prices as you see fit at each renewal and without any other consent by the customer than the customer not cancelling their contract.
​
This is tough, but here is the language and framing I use:
​
You: "You want us to keep improving the product, right?"
​
Customer: "Of course".
​
You: "OK, great. Us too. So, that also means that it will change over time. And hopefully by a lot as we add more value and tech overall changes, right?".
​
Customer: "Sure..".
​
You: "OK, so that means that even though we sign an auto-renew contract today - I really don't know what I will sell you three years from now. And you don't really know what product you are buying from me".
​
Customer: " I guess so"
​
You: "Right. And since I don't know what I'll be selling you and you don't know what you'll be buying - I don't really think it makes sense for us to try and agree on a price today for something 3 years into the future."
​
Customer: "Hmm, okay - what do you suggest instead?"
​
You: "I suggest we simply move forward one year at a time. We will constantly change prices and - if we can sell at these prices in the market to new customers - we will also apply these prices to you".
​
Customer: "I don't like that".
​
You: "I get it, but there really is no alternative. You can see it with your other vendors: you lock in a 5% annual price increase and what do they do? When they invent something that would make your solution better they can't make any money off of it, so your contract forces them to spin this new thing out as an add-on and try and sell it to you. Over time time this adds complexity and technical debt. And after 5-10 years their rate of innovation slows down. The tech becomes stale and value disappears.
​
We want to charge a fair price that the market can bear and use our ressources on making a better product and shipping that to you without constantly harassing you for cross sales. In return we always give you the power to leave."
​
​
If the above narrative is not enough - lead with a 3 or even 5-year fixed price term and then roll it into an annual renewing schedule with flexible pricing. This can be good for RFPs and similar.
​
I've had success landing the above narrative with almost any type of client imaginable - from government to Fortune 500 clients.
​
Not easy - but possible.
​
So to avoid SKU Spaghetti you need BOTH the outcome based packaging as an overall product structure to keep all the features aligned with market demand AND the underlying contract framework in place to continually reprice that product structure to match the value delivered.
​
​
​As promised: a point about pricing, every Monday.
​
PS: if you want to talk about how we can help you clean up your pricing and SKU spaghetti - simply respond to this email.

‍