My job at Amplify is working with technical founders on finding and closing their early customers. One of my more misunderstood areas of focus is pricing: specifically, how and when to price your product with early design partners. My (perhaps controversial) point of view is that early stage companies should avoid concrete pricing for as long as possible. In this post I’ll try to explain why you should do this, and how to actually figure out what you should charge in the first place.
What we’re talking about when we talk about pricing
Technical founders tend to go right into engineering mode when they think about pricing. The focus is on technical details: Are we charging by seat? Are we charging by user? How often? If you’re trying to build a PLG company[1], sure, these might be the right questions. But if you’re trying to make an enterprise sale, this is a completely incorrect framing and has nothing to do with where the leverage from pricing really comes from.
In enterprise sales, customers will pay a price that reflects their perception of the value that your product offers to their organization. If they think your tool is saving them $1M a year in engineering time, or reducing their downtime exposure by $1M a year, they’ll be willing to pay some fraction of that to you. Maybe it’s $100K, maybe it’s $500K. Let’s call this “what you’re worth.” It’s the concrete, monetary value that your product provides in the minds of your customers.
Your goal with early customers is to figure out what you’re worth. With every POC, you need to be working towards a mutual understanding with your customer of what amount of monetary value you’ve provided them. Some common measures of value among technical tools:
- Engineering time saved
- Cost saved (usually in an infrastructure context)
- Product brought to market faster
- Downtime prevented
- Conversion increased (usually in a performance context)
This is obviously not a scientific process. You will need to estimate, and like your teachers told you in high school, your thought process and logic for how you get your answer is sometimes more important than the answer itself. If you’re paying attention to what issues your customer has and how their team is structured, you should be able to find the value from the list above (or not from it) that gets them jazzed.
Here’s a practical example from an observability company that I worked with recently. They had a bunch of POCs going on with larger companies. We saw that they were providing two streams of value for customers: reducing their existing observability bill, and enabling them to get a deeper, more comprehensive look into their mobile fleet. The former is easy to quantify. The latter, we needed to discuss what it’s worth to a company to catch bugs quicker.
We combined these two things together, and worked backwards to land on a pricing model (charging per GB ingested) that would put the final yearly cost at around 10% of the perceived value. The usage-based pricing model wasn’t the point; it was just a convenient way to back into the number that we wanted to end up at. This is the crux of what I’m trying to say: pricing is not about logistics. It’s about perceived value, and charging a fraction of that value.
This, by the way, is one of the reasons[2] I always recommend against charging for POCs. The point is to figure out how much value you provide, then price. Run the POC, agree on what value it provided to the customer, then back out how much they’re willing to pay for that value. When they ask about approximate pricing before you’re ready to give them a number, equivocate and say things to dismiss the question:
“Here’s the list pricing, but it depends on many factors”
“There’s a wide range of what our existing customers pay”
“Until we scope your use case we can’t know”
And so on and so forth. The gist should be: don’t worry, right now it’s more important to us that we find the right customers and the right use cases than we make a lot of money.
Make sure you and your customer are on the same page
You might know what you’re worth. And as is often the case with technical founders, you might know exactly how much your product would have been worth at your previous company, where your team was facing the same problem you’re out to solve now (you may have even been the buyer for it). But none of this matters if the customers you’re working with don’t see it the same way.
You need to be focused not just on providing value, but making sure your customers are aware of that value and thinking about it in the same way you are. You need to be marketing yourself! There are two things I usually work on with founders here.
The first is that from day 1 – literally the first conversation that you have with a prospect – you need to be anchoring the discussion in the value that you think you’re going to provide them. If your product is going to save them engineering time, you:
- Lead with this when you describe your product,
- Continue to mention it in every conversation,
- Write it down concretely in your POC docs, and
- regularly check in to make sure it’s actually happening
Then, when it comes time to make the case that you’re worth $X,000 a year because of how much engineering time you’ve saved your customer, everyone will be on the same page. Speaking of which…
The second is learning how to build a data-driven, reasonably believable case that you have provided, and will continue to provide, that specific value. When the POC is up and it comes time to price, you’ll need to produce a document (or slide, whatever) that argues for how much monetary value you’re providing. This doc should reflect everything you’ve learned about their business, and how you’re saving them 10 engineering hires worth $300K each, so you’re worth $3M, but of course you’ll only charge them a small fraction of that every year. There will usually be a bit of quibbling on the numbers, but at that point, you’ve already won.
Pricing is an art, not a science. The right way to price is to figure out a concrete measure of how much value you’re providing your customers, align with them on that value, and charge them a fraction of that every year. Hold back from deciding on a pricing model and publishing it until you’re absolutely sure you’ve got this down to a repeatable process.
- You probably shouldn’t build a PLG company. But that’s a topic for another time.
- The other reason, in case you’re curious, is a lot more straightforward: a large, established company is already taking a risk on a completely unproven technology and team. Don’t make them get procurement (yet another team) involved.