Q: As an entrepreneur starting out, is it better to overprice your product or underprice it?
I remember years ago I was at an event with the CEO of a SaaS leader. And I asked him how he came up with their freemium pricing model. A data science team? A/B Testing?
“No. I made it up on a napkin at my daughter’s bat mitzvah” he said. Well, maybe that made sense a few generations ago in SaaS :). But now that there are 1000s of SaaS apps, there’s a bit more of a science here.
For most of us, as we build up our confidence, the best initial pricing strategy to start is the Low End of Normal.
Why? It creates the least friction. And you want the least friction possible in sales when you are starting out.
What is the Low End of Normal?
- First, just look at the competition. The market leader(s) in the space, the Top 1–3 players.
- If you don’t have direct competition, look at “comps”. Comparables. Apps that provide roughly similar value. A bit more on that here. There is no commodity pricing in SaaS. But there are ranges.
- Price at 80% of that, to start. If that looks too low, raise the price a smidge.
The Low End of Normal says the right things to start for a brand new app out of nowhere — that you are feature-rich enough to command a fair price. But not so established, you aren’t adding a small incentive to try the next guy.
Other strategies include:
- Identical Pricing. This oligopical-style pricing sends a message to the market you are 100% the equal of the market leader. If you are — maybe price the same. If you really are feature-rich and as good or better than the market leader, try Identical Pricing. It sends a clear message you are as good and indeed better than they are. And it removes price as a competitive issue. Being cheaper sometimes does say you are cheaper. Being identical says “Pricing Isn’t the Issue. Pick on the Merits. And We Win on the Merits.”
- “Anchor High” Pricing. This is where you price higher than the market leader — because you are more enterprise, more feature-rich, more trustworthy, etc. This can work well in a strong enterprise play, where there is room for a safer/more secure/more enterprise/more dashboard-ed competition. But it has to be true to work.
A bit more on Anchoring High here: Anchoring High in Pricing Really Works. But Only If You Do It Really Well. | SaaStr
And a few things that generally don’t work:
- Being too cheap. This just confuses prospects and customers. If your product really is better than Dropbox or Slack or Zoom, why is it only $2 a month?
- Nonstandard models. If customers in your comparables, and/or at your competitors, like to pay per transaction … then generally, default to start there. The model your competitors have chosen may not actually be the best for your customers. But it is known. And thus, generally, creates the least friction.
- Implementation fees — in the early days. If you are truly enterprise, this can be OK. But in the early days, don’t charge extra for services or any costs related to deployment. That’s on you until you have at least a mini-brand. It’s fair to charge here, and you should later. It’s just, it will only confuse many customers in the early days. I was just asked to pay $2k in implementation fees for a $299 a month app I wanted to use. I was almost ready to sign. But that $2k sent a message to me. That it was going to be … hard.
- Being too cute. Yes, pricing matters. And optimizing pricing really matters — later. As you get to scale. But what matters in the early days is just getting happy, paying customers. It doesn’t really matter if you get pricing right on customers 1-100. What matters is pricing is fair, it scales, and it doesn’t add friction to getting going. Later, those early customers will just be a tiny, tiny fraction of your customer base. But they are your acorns. Let them grow. Keep It Simple. Keep it Fair. Try to make your pricing in the early days be Zero Questions Need Be Asked.
Remember, we’re all SaaS veterans. We’ve bought 50-100+ SaaS apps already. And we know what to expect in pricing for roughly similar apps.
Take advantage of that.
(note: an updated SaaStr Classic post)