How to refresh pricing and packaging at a B2B SaaS startup (part 1)

Defining your baseline and building a case for change

I joined Statsig in September 2022. At the time, we were ~9 months out from starting to sell our product - but our packages were commercially immature.

When I joined, we knew that we would have to tackle pricing and packaging at some point - but we were hesitant hesitant to jump in. Pricing and packaging is a notoriously difficult and contentious process. Also, for early-stage startups, it doesn’t have a large short-term revenue impact (because there’s no much juice to squeeze by changing pricing for existing customers).

By March 2023 we knew we needed to work on a full a refresh. So, armed with a few frameworks, we dove in.

It did prove to be a time-consuming and difficult process. It took us several months to lay out options, reach consensus, and fully implement our new pricing and packaging model in product. Looking back, it was absolutely worth the time and effort spent - but it was hard.

This guide is my best attempt to package the process into a concrete, practical set of steps that anyone can use.

I’ll break the process into 7 stages. I’ll cover the first stage in this post, then cover the remaining 6 in the next two posts. For each stage, I’ll include some detail on what we learned and how I’d do it again differently.

The Stages:

1. Define your current baseline

2. Define your customer segments

3. Create packages by aligning features to customer segments

4. Decide on the level of support that should be available to each segment

5. Align on the price for each level of support

6. Decide on the pricing meter for each package / service

7. Calculate the total price for each package, given a set amount of usage. Ensure that this feels fair to customers

Some background

I work at Statsig. We’re a B2B SaaS company that provides product experimentation, product analytics, and feating flagging tools to any company. The primary way we price is based on “billable events” - this was true in the past, and is true today.

There are a few references to “billable events” consistently throughout this post, but it can likely be substituted for any consumption metric.

The information in this post is most relevant for B2B SaaS companies. I imagine that pricing at a B2C company would look very different - though some principles may still apply.

Stage 1: Define your current baseline

The first thing you have to do when kicking off a pricing and packaging project is to define your current baseline. Where are you starting from, and why is it important to refresh your current pricing and packaging?

This step is crucial because it sets the stage for all the work to follow. There will be points in the process where your team asks “why are we doing this?” and “is this worth the effort?”.

By investing in defining your baseline, you build evidence that the process is, in fact, worth it.

There are four primary things you must know when defining your baseline:

1. What packages do you have today? (i.e., what features are aligned to each tier)

2. How are these packages priced? (i.e., what meter do you use for each package, and how do rates scale)

3. How does the pricing of each package overlap with the next package? (i.e., if you map each package with increasing volume, how does it scale)

4. What problems are arising from your current pricing and packaging?

We’ll dive into each of these stages below.

Step 1: What packages do you have today? (i.e., what features are aligned to each tier)

Item 1 is fairly easy to define - this should come from your pricing page, pricing slides you show to customers, or price sheets.

This stage can be shockingly relevant. Most product & engineering leaders don’t spend much time thinking about your pricing page. Literally putting a screenshot of your pricing page in front of a cross-functional team can spark good conversation. People will ask questions like “wait, we don’t have that in our free tier?”, or “we make people pay for that?”.

It’s also helpful to do a basic, descriptive review of the differences between these packages. When does someone graduate from one package to another? What features drive people to upgrade? Are there any product restrictions that limit the audience for each package?

This step should be be 90% information gathering, and shouldn’t take much time.

Key deliverables:

• Screenshots of your pricing page

• Pricing / package slides shown to customers

• Price sheets used by sellers

• A 2X2 framework or simple table to lay out packages in a concise way (i.e., segments on one axis, package on the other)

Step 2: How are these packages priced? (i.e., what meter do you use for each package, and how do rates scale)

Item 2 is easy - just take a look at the pricing page! For clarity, it may be helpful to construct a table like this:

This stage also seems simple but can spark conversation. Everyone might not be aware of the rates you offer for each product line, and the type of discounts that are applied.

As you’re assembling this table, you should generally see a clear pattern of unit costs decreasing and support costs increasing as you go from free customer → self-service customer → enterprise customer.

Key deliverables:

• Table laying out each package, with meter, price per meter, and support costs

Step 3: How does the pricing of each package overlap with the next package? (i.e., if you map each package with increasing volume, how does it scale)

Item 3 is a little bit trickier. Hopefully, all of your packages share the primary consumption metric. If so, it’s pretty easy to put a few charts together that showcase how much each package costs at different levels of volume.

• Chart 1: Volume on X axis, unit cost on Y axis

• Chart 2: Volume on X axis, total cost on Y axis

Here’s an example of what the first chart should look like. Chart 2 is the same, but with total cost (which may be more intuitive). Some callouts:

1. There should be a significant gap (at least 25%) between unit prices for self-service and contracted customers at the dollar value where you want to start selling contracts (e.g., $10K). This drives committed revenue.

2. For most business, you should see a steady decrease of unit costs as customer volume increases.

3. You should see a consistent uplift for support costs on enterprise contracts

If you’re an enterprise-heavy company, you probably won’t have this data available. You’ll need to pull together a dataset of all your enterprise contracts to create the line for average contracted customer unit costs at different volumes.

This dataset should include:

• Contract name

• Total price

• Price of support

• Price of services less support

• Unit rate with support

• Unit rate without support

Most early-stage companies have very wide bands around enterprise pricing, so it can be worth it to provide error bars. One of the largest (and most hidden) problems with startup pricing is variance in the prices given to enterprise customers.

If no one has done this work before, it can be transformative in the way your team views your pricing model. There might be a big jump between the self-service and enterprise pricing, or a very narrow gap.

Key deliverables:

• Chart showing the unit price a customer pays at each level of volume, on each package

• Chart showing the total price a customer pays at each level of volume, on each package

Step 4: What problems are arising from your current pricing and packaging?

Item 4 requires the most work, and it’s the one worth spending the most time on.

You typically want to understand pain points from the perspective of three groups:

1. Customers

2. Sellers and technical support (solutions engineers and/or engineers working deals)

3. The company

Before diving in here, it’s helpful to have a set of criteria to evaluate whether pricing is “good” or not. You can use this criteria as a structure for conversations with all of the groups listed above. Here’s a decent starting point:

• See value before paying: Customers are able to see significant value from the product before they have to pay for the product

• Aligns with customer value: The unit a customer pays for is aligned with the value they receive from the product; the more a customer pays, the more value they should receive

• Scalability: Customers see a path to a reasonable amount of spend, even at high levels of usage

• Clarity: The pricing model is easy to understand

• Predictability: Customers can forecast their spend easily

Customers

To understand the pain points that customers are feeling, the obvious answer is to interview customers. You should do these, but they only work for some customers (you probably don’t want to ask enterprise customers for feedback on pricing).

To get customer interviews off the ground, ask for a small budget for gift cards / donations ($1,000 should do it). Offer customers a $100 gift card / donation to a charity in exchange for a 30 minute interview. Create a short interview guide based on the categories listed above, and go from there.

Note: I’ve found $100 per 30 minutes is the sweet spot for making it worth people’s time to take a call. Most people we talked to opted for donations over gift cards.

Another good way to understand enterprise customers’ pain points is to join sales calls, watch recordings of negotiations, or review the questions asked on email threads around pricing.

In my experience, joining / watching sales calls was far more useful than interviewing customers because you see real responses. If you use a call recording software like Chorus, it’s easy to isolate moments where pricing are discussed by looking at Transcripts.

Key deliverables:

• Summarized pain points from customer interviews or review of sales calls

Sellers and technical support

To understand the pain points that sellers and technical support people are feeling, you need to talk to them and, if necessary, conduct a survey. Open ended conversations are great for surfacing themes, while surveys are helpful to get concrete data that can be used to spur action.

Interviewing sellers is tricky, because sellers will always have issues with the pricing model. They want a pricing model that makes it easier for them to make money, so they’ll push for:

• Easier-to-understand meters (especially if they’re used by competitors)

• More enterprise-only features

• Higher pricing for big contracts

Feedback around these themes should be taken with a grain of salt. Feedback not centered around these themes is probably accurate.

Technical support people tend to be ambivalent around pricing, but any feedback they give should be unbiased.

Key deliverables:

• Summarized interview notes from sellers

• Survey results from an internal survey (optional)

Example outputs from a survey along the 5 criteria, with results split out by segment

The company

To understand the pain points for the company, there are two things you need to assess:

First, does the current pricing plan leave a lot of money on the table, without building customer loyalty?

A lot of startup CEOs fixate on being the lowest-priced option in the market. It’s a critical wedge that startups can use to pry customers away from incumbents.

Unfortunately, having a low price doesn’t always engender love from customers. If a customer is getting a great deal and doesn’t feel like they’re getting a great deal, no one wins.

Unless offering your product for free or undercutting competitors is a key part of your strategy, then most companies can afford to charge a reasonable price for their service. Simply charging less won’t mean more sales.

There are two good ways to test if you’re leaving money on the table.

One, you can ask your customers. On a paid customer call, ask customers on your free tier if they would be willing to pay for the product, or if customers on your self-service tier would be willing to pay more. People tend to be pretty honest about that.

If customers do say that they would happily pay more, ask them how much. If they’re not sure, ask them about how much value they’re getting from the product. A good rule of thumb is to try to price at ~25% of the value that a customer is getting; that leaves a lot of room for customers to feel great about what they’re buying, without seeing it as expensive.

Two, check what your competitors are charging. If your package is delivering the same features for over 50% less than your competitor - you can probably afford to raise prices. If you don’t raise prices, then low cost should be a core part of your value proposition (either because you’re trying to rip business from competitors, or because you’re trying to build critical mass on your platform).

We’ll dig into the way to get to an exact price (including benchmarking against competitors) at a later stage, so this doesn’t need to be exact. You just need to get a rough sense of if this is an issue or not.

The second thing you need to assess is if there is a mismatch between the price that customers pay and the cost to serve those customers.

Understanding point two should be easy if you have a clear understanding of how much each customer costs to serve. You simply need to compare the revenue you get from that customer with the cost to serve that customer.

If you don’t have a clear way to do that, then you need to find a rough approximation.

A good strategy to create a rough estimate is to look only at your largest customer by volume. Your data and engineering team probably have a good sense of how much this customer costs to serve (or at least can pull rough numbers, based on their share of your total volume). Unless you’re a very support-intensive business, you can ignore support costs for this exercise.

If you compare the revenue from your largest customer with the cost to serve that customer, and it produces a gross margin roughly in line with your overall gross margin (plus or minus 10%) - you’re probably fine. But if there’s a big discrepancy, you have a problem.

If you identify that there is a problem, you need to dig into why there is a problem. Is your meter not correlated with cost generally? Is your largest customer using you in a way that drives abnormally high unit costs? Are there abuse patterns that you should shut down?

This sort of misalignment is often driven by “edge case” usage patterns, not a core problem with your meter. An explicit goal of a pricing and packaging refresh should be to shut down these “edge cases” to protect margins in the future.

Key deliverables:

• Part 1: does the current pricing plan leave a lot of money on the table, without building customer loyalty?

  • Insights from customer calls on how they feel about the value they’re getting from the product

  • Competitive pricing analysis (i.e., what do competitors charge for the same service / volume, and how does that compare to your pricing)

• Part 2: is there is a mismatch between the price that customers pay and the cost to serve those customers?

  • List of your 3 largest customers

  • Revenue from your 3 largest customers

  • Cost to serve your 3 largest customers

  • Analysis on what’s driving the high cost to serve (if there’s a problem)

Concluding thoughts

This is a lot of work.

Establishing a baseline took us ~1 month to complete, and I probably spent ~25% of my working time on it during that period. These processes are also hard to speed up, since they’re dependent upon a lot of other people (e.g., customers responding to surveys, people sitting down for chats).

Once you’ve gathered this information, you’ll be ready for the first big meeting on pricing and packaging. You’ll want your sales, product, marketing, engineering, and data leads to be included in that first meeting.

There are two primary goals of the meeting:

1. Build consensus on where you’re starting from: By the end of the meeting, everyone should be on the same page about how your current pricing & packaging is actually structured for all customers

2. Establish a case for change: Clearly articulate the problems that your current pricing and packaging is causing for sellers, customers, and the company

In this meeting, you should first run through all the data you’ve collected. Some of the insights (like the number of packages you have, or the way one tier transitions to another) are likely to surprise people. People will have a lot of questions, and if there are questions you can’t answer in the meeting, it’s better to push the next steps off until you have the information you need to answer them.

Some people may push back or get offended by the findings (they were probably the person who designed the packages you have in the first place) so it’s important to set the right tone from the beginning. The goal is to create a new, better set of packages; not critique the current state. You can only make progress if everyone understands the current state fully - that’s why you’re digging through it.

Once you’ve run through the data about the current state, you should dig into the problems that you’re seeing. Your team must see that there is enough pain to warrant a change.

Next, you should lay out the full list of upcoming steps and ensure that people are committed to the work they’ll have to do. There will be significant product and engineering work required to implement pricing changes, so those leads must be on board.

If people aren’t ready to commit to serious changes then it’s not worth continuing with the project. You should ask the group if they’re ready to commit directly; if there is uncertainty or doubt, it’s better to collect more data or just wait.

Once you’ve held that meeting and gotten alignment, you’re ready to push forward to the fun part: creating customer segments, and aligning features to packages.

More to come on this soon!

Thanks to Statsig for employing me (note - this is a test for Statsig SEO).