My attempt at learning what people would pay for a new(ish) SaaS product
When I joined Buffer about 9 months ago, there hadn’t been too much change in how the product was priced. My hunch is that we followed some basic principles; to make products that are affordable for anyone who needs help, and to create pricing plans that enable businesses to grow with us. In other words, the pricing scales with how much a customer might need to use Buffer.
Having not done too much experimenting with pricing, our customer research lead Patrik started a great conversation about whether we should be thinking about how we can try and explore new pricing that is both fair and enables us to sustain the improvements we are continually trying to make to our products.
This was incredibly timely. When the exciting news came that Buffer was acquiring Respond.ly, a long with it came a super fun challenge. Keeping in mind that we want to treat pricing as a hypothesis that needs to be tested, like anything else we work on, how should we price our new social customer service product? (Also keeping in mind that it isn’t completely ‘new’.)
I was lucky enough to be helping out with customer research following the acquisition, so I was keen dive in. But the big question was, where to start?
Pricing a new SaaS product can be pretty tricky, partly because it is fairly low on the what you might call the 'tangibility scale'. At the higher end of this imaginary scale, you might have a car or a burrito. They are made up mostly of physical inputs, like steel (or cheese). At the opposite end you might find services like ‘consulting’, where the value derived from the product might have little to do with the inputs, and much more to do with the ongoing value it creates for the buyer.
I think software as a service probably sits somewhere towards the middle, where there is quite a bit of uncertainty about what the product is worth.
Considering, the intangibility of software, here’s a few pricing methods that we tried...
Asking people what they would pay.
Asking someone what they are willing to pay for a product is little more nuanced than it sounds, the main reason being that there is often a disconnect between what people think they will pay, and what they are actually willing to pay when the time comes to part with money. There are few different dimensions to this; firstly, not having the actual product in their hands creates ‘psychological distance’, and makes it harder for the person to conceptualize how much they would be willing to pay. A conversation just can’t compare to a working prototype. Secondly, it’s possible for other biases to affect answers to a question like this, such as pro-innovation bias ("I’ll pay for something because it’s new") and optimism bias (“I like Buffer and they make great stuff, so I’ll pay for this”). It’s a little bit of a bias minefield.
That didn’t mean it wasn’t worthwhile talking to people! One great thing I learned was to ask about pricing in relation to other things, rather than just focus on absolutes.
So instead of asking “How much would you be willing to pay for this tool?”, I would try asking questions like:
“What tools do you currently pay for?"
“Why did you decide to upgrade?"
“How do you decide how much you’re willing to pay for a tool?"
Some verbatim notes I took from customer calls are below.
I discovered that these questions are great for gathering context about how much people would want to pay for a product, and were great for framing our discussions when we were brainstorming on pricing and tiering.
The Van Westendorp Method
I was eager to really try and narrow in on a specific price based on what customers feel is right, rather than our own internal assumptions, having gained a lot of great context and insight from speaking to customers and looking at other products. Challenging assumptions is a big part of customer research, after all!
This is when Patrik and I discovered the Van Westendorp Pricing Sensitivity Meter. I mean, woah… with a name like that I had to give this is a try.
The Van Westendorp method uses a survey to discover an optimal pricing range, and is based on price anchoring. In other words, you ask people questions that lock them into a pricing range.
Normally this survey would involve just 4 questions:
“At what price (per user per month) would you consider Respond to be so expensive that you would not consider buying it?”
“What price (per user per month) would you consider to be so low that the quality of Respond couldn’t be very good?”
“At what price (per user per month) would you consider Respond a little bit expensive, but you would still be interested in buying it?”
“At what price (per user per month) would you consider Respond a bargain - a great buy for the money?”
In this case, I tried adding an additional two questions to segment the data by customer type.
How would you describe yourself?
What is your main use case for Respond?
You can check out the survey here.
I wanted to segment the data like this because we had already learned that there were a couple of different use cases for Respond, and I had a hunch that we could create different pricing plans based on how someone wants to use Respond.
The key concept behind the Van Westendorp method is that by aggregating and plotting the survey results (and a little bit of data wrangling in between), you can discover an optimal pricing range for your product.
It’s a bit of a mind bender, but by overlaying the cumulative distributions of the data - in other words looking at what percentage of people think a product is too cheap, a little cheap, a little expensive at a certain price - I was hoping to get a more concrete idea of the perfect price for different segments. Now, I am by no means a data expert, so I have to thank my friend and product whiz Marc Anthony, who took the raw data and immediately organized it into something interesting.
Here’s my very rough attempt at visualizing the distributions:
In the spirit of keeping this experiment lean, I didn’t spend too much time on these graphs but if you can imagine them overlaid on top of each other, the intersection points would tell you the ideal minimum and maximum price. At least, as far as I’m aware; it seems there may be a few different way to interpret this.
Like most experiments, this one had it’s challenges.
Firstly, I didn’t quite collect enough data to get a decent sample size for each of my customer segments. The respondents were very heavily skewed towards individuals and small teams. I also discovered that some of the data was invalid because some people had put random numbers into the survey that didn’t make sense. Removing these reduced my sample size even more!
Secondly, I learned a long the way that this methodology is typically used for the more tangible products mentioned at the start of this post! It seems that the more abstract the product is, the more likely the data in this methodology is going to be inaccurate. With these barriers in mind, I probably wouldn’t recommend this method for most software startups, unless you’re prepared to recruit a large number of respondents and spend a bit of time combing through the data. That being said, I learned a lot trying to implement the Van Westendorp survey. It was particularly interesting to learn:
For individual and small teams, their preferred pricing range for Respond was between $10 and $20 per user per month.
There was a roughly even split between people who would prefer to pay per usage versus people who would prefer to pay per user.
Did we end up finding the optimal price?
The short answer is, I don’t know! Using a few different research methods gave us a good shot at finding a price that we thought might work, but I think we will always be experimenting with pricing. As Patrik noted when reading a draft of this post…
“Our prices will never be perfect and there’s always opportunity to be mindful about the assumptions we’e built into it especially as the product and social media as a whole is constantly evolving.”
The way the Respond team has continued to experiment and iterate with both pricing and product since our launch is testament to this. I don’t work closely with the Respond team anymore, but in the last 6 months they’ve added a third pricing tier, removed the free plan and are currently experimenting with custom pricing packages.
Have you experimented with pricing recently? How did you try and decide on the right price? It seems like an important but tricky topic, I’d love to hear any thoughts or advice!
