This is a section on pricing from the “Sales Narratives” chapter of Founding Sales. Other sections and chapters can be found on Twitter and you can sign up to be notified about them via email on the book’s website here.

Founding Sales is a book for founders and other first time sellers as they figure out the earliest stages of their go to markets - so the recommendations contained below should be consumed in that context.

Pricing is a funny thing. It could be considered part of your narrative, or it could be considered part of your sales materials. In a way, it’s the conclusion of the narrative arc for your solution: “And because of all this, you should pay us this for the right to access our solution.” While pricing is something that is likely to change—usually going up as you gain more functionality, or getting more nuanced as you segment your solution—it’s definitely something that you’ll want to have nailed down, at least in an initial version, when you start having sales conversations.

First, I think it’s important to charge, even at the outset. If you don’t, people won’t take you seriously or think hard about whether your solution provides them value. They also likely won’t use the solution. It’s no skin off their backs, so why should they invest time in it? You don’t have to charge an arm and a leg, and you can still play with freemium approaches or engage “lighthouse customers” early on that pay for their license fees with engaged, ongoing feedback. But you definitely should charge for your solution. Founders frequently kick the can down the road on this issue because they don’t want to hear someone say no. But you’re not doing yourself a favor by avoiding that moment. Your solution provides real value to the customer (if it doesn’t, bigger problem), and your engineers need to eat. So charge.

I like to take an iterative approach to pricing, biasing toward giving away more value than is captured—at least to start. Early on, you want to get customers in the product, using it and testing your value promises; if your solution is priced to perfection, it will likely hurt your close rates. This doesn’t mean that you’ll stick with lowish pricing forever. With each incremental conversation, you’ll be getting more information about how the market reacts to your pricing. If you present your product for $100 per seat per month and no one bats an eye, well, maybe next time make it $150!

Once you start to raise prices, don’t worry about those early customers that you have at 20% or 50% of your eventual pricing; there are tens of thousands of other customers that will pay full price. Just grandfather those existing folks in and thank them for their early votes of confidence. In fact, this can be a means by which to get people to jump and buy now: “Well, it’s five hundred a month right now, but as we add functionality, that may go up. Of course, if you buy now, you would be grandfathered in at that price.”

Approaches to Pricing: There are a couple of ways to think about early pricing. It’s more art than science to start, and you’ll typically blend a number of data points together. But these approaches can help you get started:

Existing Solution Comparisons: Since your solution likely addresses an existing pain point in the market, look to existing products for guideposts on pricing and a sense for what the market is used to paying for a set amount of “value.”

When TalentBin started out, for example, a seat of LinkedIn Recruiter was ~$8,000 a year for a technical recruiter focused on engineering hiring; the product gave a certain amount of search recall for certain types of talent (e.g., “Ruby engineer in Dallas, Texas” might bring back four thousand results) and allowed one hundred InMail outreach messages a month. TalentBin, on the other hand, would give a recruiter between 2–5x the search recall, including candidates’ direct email addresses, and unlimited outreach volume. So one could argue that TalentBin might be worth much more than LinkedIn Recruiter. Our pricing ended up being $6,000 per seat per year for most of the time before we were acquired. In this case, the goal was to engender in the prospect’s thinking, “Wow, this smokes LinkedIn Recruiter for tech hiring, and it’s twenty-five percent cheaper? I’ll give it a shot.”

Another compelling reason to look at how existing solutions are priced is that there is probably a rationale behind those pricing decisions, which you may not have figured out yet. Your solution is likely a better way of doing things via some sort of technical innovation; trying to do pricing innovation at the same time is often a distraction. One innovation at a time, please.

ROI and Value Pricing: Another, more advanced, way to do pricing is known as “ROI pricing.” That is, determining the amount of value you expect to provide for the prospect and setting your price to capture some of that value. That’s not to say that pricing would change on a customer-by-customer basis necessarily (that adds unnecessary complication). But it means that you would be aiming to provide a certain amount of value above and beyond the cost of your solution.

A great example of this is HIRABL, a company that makes recruiting agency revenue-acceleration tools. One of the things they do is help recruiting agencies identity “missed fees,” where a client does not report that they hired a candidate submitted by the agency. At 10%–25% of a candidate’s first-year salary, agency fees can be between $10,000 and $30,000. HIRABL knows that there’s typically one recoverable missed fee per five hundred candidate submissions. Because of this, they are able to price their solution based on the number of submissions that they will be monitoring for a recruiting agency, using an average fee of $15,000 and that 1 in 500 ratio, and have a very high confidence that their customers will get a 10x return on their investment. That is, if HIRABL is charging $20,000 to a recruiting agency for a year of monitoring, they know that the agency will recover around $200,000 of fees over the term of the contract.

You might be wondering, “Well, if you’re going to do pricing directionally based on value capture, why not charge specifically based on the actual value captured?” In the case of HIRABL, for example, why not charge a percentage of actually recovered fees? While compelling in principle, the challenge there comes in reporting—that is, in instrumenting the actual value that was captured. And while you can architect your product to record ROI signifiers (e.g., marking a fee as “recovered”), this creates a situation where not only is the onus of usage taken off the shoulders of the customer, but there is also an incentive to hide captured value. Better to keep it simple and charge a known price, based on a defensible ROI model.

This sort of pricing can be challenging if you’re too early to have a solid ROI case. Still, you should think about how you can prove your ROI case, even conducting your own experiments at scale. You might even use those results as part of a mix of pricing approaches—like blending pricing from existing solutions and your ROI proof understanding. For instance, if you know that your job-posting solution doubles the number of qualified applicants that show up for an engineering role based on your own experiments, maybe you charge 150% of the price of that other solution.

Value Alignment and Thresholding: Another approach to pricing is an extension of this ROI-based mindset—that is, aligning your pricing to the value provided to the prospect. For instance, this might be something like the model that Dropbox or Box use, where the more storage you use, the more it costs. Or you might approach it like Marketo, Eloqua, Act-On, or HubSpot, where the more contacts you are drip marketing to, the more the solution costs. This structure has the advantage of allowing a customer to “start small” (either with a small portion of their total demand, or because their total demand just isn’t that large), and then grow—ensuring that the price you capture from them grows in step with the value they’re deriving from the solution.

This is especially important if you’re using a “trial” or freemium approach to selling your solution. You want to make sure that you can turn on the pricing at the point that the customer has gotten definite value. For instance, Yesware offers a free version of their product that allows users to track outbound emails. If you track above a certain number, though, they prevent you from tracking more that month. LinkedIn does something similar; if you use your free account to do more than a certain number of searches or view more than a certain number of profiles, they will prompt you to pay.

Related to this is the notion of “thresholding” of pricing. That is, can your intended user just decide to purchase your solution within their budgetary constraints? (This isn’t necessarily applicable to all solutions; it’s hard to have a single team using an HR system designed for a whole organization, for example.) If it’s an individual, can they just buy it themselves (Yesware)? If it’s a team or a manager, is it under the threshold of their corporate purchasing card (Box, Slack)? If it’s a department in an organization, is it under the amount of money they may have in their discretionary budget? If you are mindful of these natural pricing breakpoints, you can help ease your entry into an account by slipping in under one of these thresholds.

Pricing to Perfection: We touched on this above, but you want to be careful about “pricing to perfection.” That is, watch out for charging such a high price that all the stars have to align for the prospect to be satisfied with the value he gets from your solution—or, before then, to even believe that he could get the requisite value. You don’t want to give your product away, but pricing too high will work against you in a number of ways. First, it will hurt your win rates. A prospect can totally believe that you will solve the business pain for them, but if you are charging so much that they don’t believe it’s worth it, they won’t buy. Second, it will hurt your churn rate. If customers aren’t getting sufficient value from your solution compared to the price, they simply won’t renew.

Segmenting: There’s an impulse to index off of Box’s, Slack’s, or Salesforce’s pricing pages. You see that they all have three options—and one marked “Most Popular!”—and feel that you need to have that too. Resist the urge. They’ve been doing this for years. They know which segments of customers care about which features and usage volumes. And they likely have a number of customer segments. You, on the other hand, probably don’t have either. Even if you knew the features and usage patterns that could be used to price discriminate, you should be focusing only on your ideal customer profile to start. Segmenting your solution can be a great approach later, but early on, it’s usually a distraction.