top of page
Writer's pictureUlrik Lehrskov-Schmidt

How to validate new SaaS pricing : Internal Validation, Interviews & Sales Tests

Updated: Sep 22, 2022

Your Ultimate Guide to validating SaaS Pricing before launch to ensure minimal risk and maximal learning. Complete with step-by-step how-to guides on Internal Validation, Customer Interviews and Sales Tests.

Full guide below the video


TABLE OF CONTENTS



What is SaaS Pricing Validation

SaaS Pricing validation is the process of discovering how new packaging and pricing will perform in the market before you do a full-scale launch.


One aspect of validation is to reduce risk. If your pricing fails it can be pretty catastrophic after all. Customers will churn. Sales will drop. Customer success will be flatlined by angry customers. You can loose existing revenue and ARR growth rates can drop.


Another key aspect is to make necessary adjustments to new Pricing and Packaging in order to make it perform better both commercially and operationally.


Why use SaaS pricing validation.

Isn't it too much work to validate pricing before you launch? If we can just 'fail fast' why not just do so instead of spending valuable resources and time on validation?


Three main reasons to use a good validation framework:

  1. Validation actually speeds up your learning cycle: instead of waiting several weeks to see if new pricing is a hit or miss you learn 10x faster by breaking the question into smaller chunks.

  2. Validation is action focused. By getting a stream of small feedback chunks on small parts of your pricing you can improve it throughout the launch process - including adjusting pricing up.

  3. Validation forces all teams (Sales, Product etc.) to jointly understand why something works or fails. Everybody owns the process together and are part of the fix.


All in all the quality of your experimentation improves drastically. The core value of 'fail fast' is to be able to base subsequent experiments on learnings from previous failed ones. If you can get 10x the learning out of a failed attempt with only 10% more effort you should take the deal.


Validation actually speeds up your learning cycle.

Checklist: How SaaS Pricing Can Fail

Before we dive into the three methods of SaaS Pricing Validation, I want to give you this underlying framework to understand how your SaaS Pricing can fail.


Basically there are two main reasons: fuel or friction.


Either your offering doesn't generate enough demand (fuel) for the customer to take action and buy or your offering is designed so poorly that the customer doesn't think it's going to work (friction).


Use the below checklist in your mind at all times to identify the issue.


SaaS Failure Checklist

  1. Bad capability? (e.g., the core solution is not good enough for the job to be done)

  2. Bad fencing?

  3. Bad packaging?

  4. Bad pricing model?

  5. Too expensive?

  6. Poor communication of any/all of the above?

Generally, 1 and 6 above are the “fuel” or demand part of your equation. 2 to 5 are the “friction” parts. Whenever you hit a "no" from a customer in a validation process - place it in the above checklist.


Also note that it's hierarchical from the top down: if you have a bad fencing (e.g. segmentation of your product and pricing offering to serve distinct customer groups) your customers will say "no" to all levels of the checklist below that.


Fix from the top down.


With that said - here is how you uncover that feedback through validation.


The 3 Steps of SaaS Pricing Validation


There are generally 3 ways to build your confidence that you’ve got good pricing:

  1. It makes sense to you and your team

  2. Customer interviews.

  3. Sales Test


And remember customers want you to have good pricing. This doesn’t mean that they want you to be expensive, but rather that they want a good method of exchanging value with you.


Customers want you to have good pricing

Customers want to buy a product that solves a clear job for them, using a sales channel that balances their particular needs for speed, convenience, and trust, while paying in a way that is fair and transparent. More importantly, you also want all those things, so your interests are clearly aligned with those of your customers. This means that, on the structural level at least, you can have an open and honest conversation with your customers about your pricing and any other part of your commercial model.


Step 1: Internal Validation


Internal validation is the process of ensuring everyone in your organisation has 'signed off' on the pricing and added their unique insight to it.


Here is how you do it:

  1. Design the new pricing & Packaging framework with a core team of 3-5 people from across the organisation - usually involving at least both Product and Sales.

  2. Build a presentation that clearly explains the new Packaging & Pricing. 7-10 slides max.

  3. Show it to the teams (Sales, Product, Customer Success etc.).

  4. Ask them to 'stress test' the new pricing by phrasing questions to it. Sales: "Can I give discounts to this?" Product: "How is this feature related to the XYZ use-case?" CS: "If a user upgrades mid-year, what price should they pay?" Finance: "How will I invoice this new usage based pricing?"

  5. Compile all questions into an FAQ.

  6. Sit down in the core management team and answer all of the questions.

  7. Publish the FAQ internally.

  8. Move onto the next validation step: Customer Interviews

A few notes on internal validation.


First: The teams might want to use the 'stress test' to promote their own preferred pricing model. Block this hard. The point of having the key functions in the core design team is to ensure each part of the business is heard in the process early and to ensure buy-in from those departments early. When that is done you are now trying to close the framework - not open it up.


Second: be practical when answering the FAQ questions. There are three main kinds:

  1. Questions whose answers follow directly from the design - i.e. mainly hashing out of communication and understanding.

  2. Arbitrary decisions: some questions simply have several viable answers. Pick one and move on.

  3. Hard questions: sometimes a team member will put her finger on a real issue that you missed. Some inconsistency or flaw - or technical impossibility. Usually this can be handled with minor re-designs of the model. If big enough, you have to re-do the presentation to the teams, ask for new 'stress test' etc.. But in 90% of cases



Step 2: Customer Interviews

Customer interviews happen immediately after the internal validation. Here is how to do it.


Book 3–5 interviews, of about 30–45 minutes each, with current or prospective customers. This is enough to get a clear 'no', which is the point. Interviews are a falsification process.


When booking the interviews, you should tell the customers something like the following:


“We are working on a redesign of our product packaging and our pricing model. Naturally, we would like this to be an attractive offering in the market, so we would like to invite you to a 45-minute Zoom call to show you version 1.0 of our new product packaging and pricing and get your honest feedback. This is not a sales call, and we’re not going to ask what you would be willing to pay—we are only focused on the model itself and how it fits with your business.”


I then put together a 5–12 slide presentation with the following structure:

  1. Company presentation (if you must)

  2. The job you are trying to solve

  3. The packaging of the product (including fencing)

  4. The packaging + pricing model

  5. The packaging + pricing model + price points

  6. The packaging + pricing model + the price points of add-ons, services, etc.

  7. Any number of FAQ-type backup slides if you foresee certain tricky questions that might need attention (e.g., a visual showing a discount curve, information about how resellers are paid, the packaging for the fence that this customer is not part of, etc. This is a good place for the FAQ you built in internal validation)

The idea is to ensure you get feedback from the customer on the right structural level about your packaging and pricing - re: The SaaS Failure checklist above.


If you just show them the whole shebang straight out of the gate, you can’t separate the feedback you get because most customers will immediately focus on the price point. And if they don’t like your “$10/user/month” model, you will have a hard time telling if it’s the “$10” they don’t like or the “user/month.” So, you should show it in a staged approach, in the order in which you designed it: packaging first, then pricing model, then price points.


At each step in this process, you show them your slide, give them a minute to take it in (don’t talk), and then ask:

  1. Does it make sense to you?

  2. Do you see yourself fitting into this model? (e.g., “Which of these packages would be for you?” or “Does this pricing metric work for you?”)

That’s it. If you establish that they understand the model and that they have demand for it, that’s enough. Take any other feedback they have and engage in a conversation with them. This should be run as a semi-structured interview.


How to Handle Customer Interview Push-Back

And now to the kicker: if they answer a hard “no” to either of those two questions, you don’t proceed to the next slide.


Let’s say, for example, that you’ve shown them your new packaging, and they got it straight away, really liked it, and could immediately place themselves into it (e.g., “We would definitely go for the ‘Agency’ tier, given all of the automation features there”). But when you showed them the pricing model—a price per client project, say—the customer was suddenly not onboard and said things like, “How would you even define that? We have clients that have been with us for years, and sometimes we structure 100s of projects for them, but really these are part of one larger campaign. Also, some projects we have are really huge, but others are very, very small—and some of the smaller ones we don’t make any money on. They are just done to sell other projects.” And so on.


If that is the feedback you get on your # ClientProject pricing metric, you really can’t use the feedback this customer would give you on the price point related to that metric—because any price is going to be “polluted” by the fact that the structure isn’t a good fit for the customer. If you get a stop like this, you thank them for the feedback and pull out the third question:


3. What should we do instead, then, to create a [packaging/pricing model/price point] that you’d like?


Then listen as hard as you can. You can challenge, gently, to understand the boundaries. For example, if the customer above suggests a “per user” metric, you can say something like, “We thought about that, but didn’t go with it because we were concerned you would then limit the use of the software to only a few of your employees instead of spreading it across your organization to create more value. Do you think that concern is unwarranted?”


You listen carefully to gauge if you’ve correctly understood the customer’s job to be done, value chain, budget structure, perception of fairness, unit economics, and so on. Because if your pricing isn’t working, it’s likely due to you not fully understanding one of those underlying factors.


Place the push-back on The SaaS Failure checklist and go back to the drawing board.


Feedback on Price Points in Customer Interviews

Now, you are likely going to get a bit of pushback or challenge on the price points. That is only natural.


What you are listening for is how the customer is trying to understand the price points. What are they comparing them to? Their internal unit economics in their own revenue model? Competitor price points? The pricing of other software? The price they are currently paying?

Remember, no price is in itself high or low. Price is always evaluated in relation to something else. The interesting thing for you is what that “something else” is. This information will be really valuable to your Sales teams, because they now know how to build their communication.


If you get really hard 'are you out of your mind!'-push back on the price point, just note it down. The next interview might be completely different. Understand why. If everyone agrees - then lower the price. If you get no pushback on the price points - consider raising them 50-100% and run another 3-5 interviews.



When to move on from Customer Interviews

You want customers to generally agree that your Packaging and Pricing Model is good, and have a 'medium' reaction to the price point.


At this point: wrap up any learnings you have. Adjust where necessary. Add newly resolved questions to the FAQ and move on to testing the new Packaging and Pricing in live sales.



Step 3 : Sales Test

The gold standard of validation is, of course, actually getting customers to buy. You can have a model that makes total sense on paper, but fails when it goes live. We need to solve for this with minimal risk.


But another equally large risk is that you do really good with your new pricing - but could have done far better. You raise prices 100% - but could have raised them 700%.


Wrong mental frame: launch sales test and hope we don't fail miserably.


Correct mental frame: launch sales test to learn as much as possible and adjust accordingly.


Acknowledge that Sales - and individual reps - have a lot at stake here in terms of commissions, relationships with customers and so on. Ensure you have buy in on the param


  1. With that said, here is how to do a sales test of new SaaS pricing:

  2. Pick the smallest possible market to test (e.g. US only, or SAP integrations only)

  3. Test only on new customers

  4. Do weekly learning sessions across functions

  5. Run for 1 sales cycle

  6. Adjust pricing and restart.

  7. When happy: launch to all markets.

  8. When happy again: start migrating legacy customers to new pricing.


Testing on the smallest possible market lowers risk. Find a sales champion in that market, who believes in the new pricing and have him or her spearhead the test. If your ACV is larger you probably have 2-5 customers in the pipeline where the next reasonable step is to talk pricing. All operational aspects of your new model (e.g. billing, new services etc.) you simply hand-hold with duct tape while running the test. If your product doesn't allow you to deliver two different versions to different customers, you will have to test on the entire market.


I advice testing new pricing on new customers first if at all possible. Existing customers will be too anchored to their current solution. There are exceptions, such as if you are in the middle of an on-prem to cloud transformation with that customer, so use common sense.


Have sales reps identify the reason for any lost sales and then review that data weekly together with Sales management to answer the question, “Why are the customers saying no?” Be prepared for sales reps to always blame price points, but don’t accept that straight away; instead turn the conversation around by saying, “What could we do on the core value of the product, the packaging, and the model to reduce the need for discounts or a lower price?” Remind the sales reps that they’re the ones who talk to customers all day, so they need to have a perspective on this and send it back to Product if they ever want to have something better to sell.


Try to place the feedback from sales into The SaaS Failure checklist to understand what to fix. Ensure the FAQ is used and continuously expanded as you learn.


After about one sales cycle you should have a clear understanding of the performance of your new packaging and pricing. However, very positive and very negative results come way faster. If you've hit true product-market fit you will see your pipeline fill up way faster than usual and likely your sales cycle will shorten. Speed up accordingly and consider testing higher price points.


If your new pricing fails miserably you will also know quickly, because customers will reject you early in the sales process. Fix this immediately and relaunch pricing again.


Assuming you get a good result overall, simply adjust the pricing and packaging to the learnings you got from the sales test. Now is also the time to focus a bit more on operations like billing, service set up etc., as you prepare to launch to all customers across all markets.


Assuming this also goes ok you can now choose to migrate legacy customers from the old pricing to the new (a topic I'll cover in another article).



What Validation Method should you use?


Depending on how fast you want to move and how much risk you want to take you can speed up or slow down the validation process:

  • Usually the internal validation will take around 2-3 weeks.

  • The Customer Interviews will take another 2-3 weeks.

  • Sales Tests will take a sales cycle - so anywhere from a few weeks to 6+ months. And usually requires 2-6 weeks of preparation in terms of sales materials, operational prep, product development etc.


For larger ACVs with longer sales cycles I usually recommend doing all three. The risk of having to redo an entire sales cycle is too high to not invest the extra 4-6 weeks into proper internal validation and customer interviews. And if you are really in a hurry to hit some external deadline (e.g start of a school year, big product reveal at upcoming exhibition etc.) you can run internal Validation and Customer Interviews in parallel - and even start the operational prep in parallel as well. Just warn everyone that everything in the model might change with a moments notice if someone points out a key issue you hadn't considered. It's risky, but it can work if you are in a crunch.


For early stage startups with ACV below $5K, you can run directly from design process into sales test and back again at a high speed. If your product roadmap is moving really fast, this can become a continuous cycle as you iterate towards true product-market fit.


Yes you are going to blow up a few times, as you launch something that falls flat on it's face - and the organisation is going to try to force you to do internal validation sooner or later to prevent blow ups. But you move fast.


Closing Thoughts + a War Story

I have done over 100 commercial redesigns for B2B SaaS businesses of all shapes and sizes. The validation process is a key element of this, often following immediately after a design phase and preceding a migration phase where existing or old customers is moved to the new pricing.


For startups the value of validation is learning. Real product-market fit comes from getting a lot of small, incremental details just right. I sometimes use the metaphor of a combination lock: all 5-digits need to be correct before the lock pops open. But when it does is where magic and explosive growth happen. If you are at this stage, pick the parts of the process above that really spoke to you and implement them. Forcefully. It will pay off.


For established companies the value of validation is the reduction of risk. Even if it is a completely new product were launching into the market - as opposed to the migration or redesign of an existing one - there is usually a lot riding on this. People have staged their careers on this being a good idea. The strategy might depend on it. And so on.


War Story - how a $0.05 sticker almost derailed an IoT strategy.

I once did a validation project for a global OEM in the cleaning segment - a $3B operation - who wanted to charge $0.05 cents for a sticker with a QR code that was part of the use-case of a global software solution they were rolling out - critical to the integration of existing use-cases and their long term IoT strategy with contract cleaners. They wanted to charge the $0.05 because they were "afraid that someone in Mozambique would order a million of them" if they were free (that was the direct quote from the executive VP in charge of the program).


I did a 30min interview with the CCO of their largest customer, who would probably order the solution to 50.000 hardware units a year. When asked about the $0.05 sticker his immediate response was "Then we can't buy it. It's not the price - that's fair enough. But we run our accounting on a unit level, so if we purchase 50.000 stickers we would have to have someone in accounting split that invoice into 50.000 sub-accounts. One for each machine. I just can't do that to accounting.".


We offered the sticker for free. And of course nobody ordered more than they needed.


--

And that's it - let me know in the comments below if you have questions or if you've had experiences (good or bad) running validation on SaaS pricing.


- Ulrik





Tags:

Comments


bottom of page