Last time out I mentioned how I would discuss the topic of pricing and how it relates to startup companies. When you enter into a discussion around pricing, you are entering a very big and controversial topic about which entire edifices of theory have been constructed. Since this is a blog and not a PhD thesis on economics (thank goodness!) I will, of necessity, skip a whole lot and annoy people who know a great deal about this topic. So caveat blog-reader: this is not meant to be exhaustive, just a few specific points that I feel are valid.
I want to start the discussion not with theory but with an anecdote. Understanding full well that the plural of anecdote isn’t “data,” nevertheless I think stories can be instructive.
Back in the early 2000s I was working at StorageCo (a made-up name as the company I’m referring to still exists and I’d prefer not to mention their name). They had some truly ground-breaking software around storage management. And I mean the real deal, not some minor tweak on standard technology marketed as the next big thing. They really had some wow-ware, as in customers saying, “Wow, I can’t believe you can do that!”
But it never broke out into the market the way it might have. There are lots of reasons for that (there always are), but a very big reason was pricing. Simply put, their pricing model was terrible, both in type and in cost. The type of pricing was component and feature-based. You paid for the core software. Then you paid again for all the valuable features, more money for each. Then you paid for every client connecting to it. Then if you wanted to ship the data to another site, you paid for the software over there and paid again for every feature. Yikes. What a terrible model!
Yet this was a very common model for decades in the data protection space, and still lingers on with many users. To make it worse, the sales reps at StorageCo had a very bad habit. After wow-ing them with a product pitch, the customer naturally asked “how much is it?” The reps tended to say, “Oh it’s only $10!” (Not a real price, obviously, but the upcoming costs are accurate relative to it.) For this kind of software, $10 was perfectly reasonable. “Ok, I’ll take it!”
Well…did you want the failover feature? That’s another $10…for each server. The protection feature? Oh, that’s actually $20, more than the core software. And since you’re getting failover, it’s times two. The remote site feature? That’s $10, plus all of the above again at the remote site. Clients? Every ten clients is another $10.
There was even more, but you get the idea. So what was first presented as a $10 solution was suddenly $200 and climbing! Boy, if I only had a dollar every time I saw the shocked face of a prospect, well I could afford to buy that software (but not the remote site feature).
You can guess that this depressed sales dramatically. StorageCo didn’t win nearly as many deals as it could have given the technology on offer. That’s an obviously bad thing, but is there more to it? Yes, much more.
Here we turn to theory, specifically the notion of the Experience Curve (also referred to as the Learning Curve). The theory came out of the Boston Consulting Group in the 1960s and founder Bruce Henderson in particular.
In simple terms, the Experience Curve suggests that the costs incurred in producing any good or service will decline as you do more of it. In fact, you can even quantify this number within an industry, and it generally ran from a few percentage points up to a more typical 20 to 30 percent with every doubling of output. In other words, if you make widgets your total costs to make them will go down about 20 to 30 percent when you are making twice as many. This is because your organization accrues experience across the board and experience brings efficiency: not just in manufacturing widgets, but in selling them, marketing them, supporting them and even managing the people who do those things. This applies to pure service businesses as well as industries with little hard manufacturing costs, like software.
It took StorageCo a very long time to double its business, so that was critical experience missed. Had its pricing model been better it might have won a lot more customers sooner (even at less money per customer) and ultimately reduced its costs.
But this isn’t the most interesting insight. The key insight for startups to take from the Experience Curve is that it extends to your customers. How’s that?
Yes, a key part of your experience as a vendor is what your customers do with your product. Once they get it and start to use it, they quickly learn more about it than you know, and they find new applications and uses for it, often ones you didn’t think of yourself. In other words, your customers discover new features and markets for you. Your customers innovate for you.
Think of it as market research done by people that pay you. What a concept! But it’s intuitively true.
I think about StorageCo and how much we all would have learned if we had five times as many customers, even if we made less money from them overall upfront. The lessons would have been invaluable. To put this in simple terms, if you are just starting a business you may be much better off having 100 customers who generate a million dollars in total revenue than 20 customers who generate a total of three million. Your investors may not feel the same way, but then maybe they haven’t heard about the Experience Curve.
This is sometimes put in other terms. Companies argue internally about “do we try to maximize revenue or maximize market share?” Market share really means “number of users.” And if the Experience Curve is to be trusted, the answer to this is always “maximize market share.”
Now things change somewhat if you are already a giant and successful company, and the Experience Curve has its limits. But if you’re part of an organization struggling to enter a market, it’s worthwhile to think long and hard about the impact of your pricing decisions. Getting the price right means much more than just the dollars it puts in your pocket. It can mean the difference between succeeding and being just another failed startup.