No one talks about pricing, and yet it’s the key to whether your product succeeds or fails.
In this presentation, Janna Bastow shows how pricing is an extension of your product, something that can be experimented with in lean ways for truly profitable results!
You’ll hear about pricing vectors and packaging considerations for your product, and how to test and experiment in ways to maximize your learning by taking advantage of feedback loops and buying signals.
Stop underselling yourself and leaving money on the table! Unlock the power of pricing in your product.
Auto-generated transcript - may contain errors. Tap a timestamp to jump the video.
Hi, TuringFest. It's wonderful to be involved in this year's festivities. I was meant to be there in person with you, but coronavirus woes means I'm joining you from here in sunny Brighton instead. Now this audience is a really special one to me. Brian and I both took a chance on one another many years ago.
He was running a new conference, and I was an unproven speaker. He invited me along to speak at Turing Fest in twenty sixteen and to share my experience and knowledge with his audience. And I shared what I knew at the time, and I called that talk the power of product focus.
It was a raw firsthand experience of how our growth had slumped and how we regained our traction through a focus on product objectives and rapid experimentation. The next year, I came back and spoke about the power of product culture, the idea that product thinking could emanate across your organization and result in more innovation, less wastage in the development process, and organizations that can overcome just about any challenge.
Each of these previous talks spoke to where I was in my journey as Progpad's cofounder and CEO. Each is embedded with the learnings I've been picking up and making sense of up until that point. So I'm super thrilled to be back at TuringFest.
And in my usual TuringFest fashion, I'll be sharing my raw learnings and some good rants along the way. Today, I'll be tackling the topic of the power of product pricing. Now before we start, ask yourself, are you underpriced? Who here is underpriced? Do you think you could actually be charging more for your product but haven't actually made the move to correct those pricing levels for one reason or another?
The reality is most of us are in that position. Most of us are building superb products that actually solve problems, but aren't actually getting paid enough for the time it takes or, more importantly, for the value that we create. And I'll let you in on a dirty little secret.
No one talks about pricing. The average SaaS startup spends six hours working on pricing. That's not per week or not per month or not even per year. That's ever in their lifetime. And considering how tightly linked pricing is to product market fit and just basic unit economics in business, this is ridiculous.
But I get it. The first several years of ProdPad's life, we put very little effort into thinking about pricing ourselves. When we started, we simply plucked some numbers from thin air. We copied pricing from others in adjacent spaces and came up with something really super simple.
It was nineteen dollars for the basic plan and thirty nine dollars for the plus plan. Why? It felt like a good number. We could see that collaboration software in that sort of area next to us went for about that. And frankly, we didn't have the guts to ask for more back then.
You know, we were pretty chuffed when we had our first paying customers within the month. But we didn't question whether our pricing was too low for quite some time. We shouldn't have plucked these numbers from thin air. We should have checked these numbers right out the door as a higher starting price point would have given us more to build from from day one.
Compared to what we know today, our approach was cavalier and shortsighted. I left money on the table, money that could have been invested in future growth. But pricing mistakes like this are super common. And if there's any big takeaway I have, it's that your pricing is probably hurting you.
But it could be one of the biggest opportunities for impact on your traction and your bottom line that you've seen in a long time. But let's acknowledge this upfront. For most of us, playing and pricing isn't fun. It's an uncomfortable process, and it means having to put a value on your work.
Sometimes having to face hard truths or even hard notes when faced with customers who just don't share your vision about how much you think they should pay. Pricing is emotional. It's finicky. It's technical, and it's never as rational as we'd like to think.
Maybe this is why we spend so little time on it. Now one of the things I'm most proud of is just how far we've come with our pricing at Broadbat. Our average revenue per account when we launched was twenty bucks. Now not including enterprise sales, that ARPA figure has crossed beyond the two hundred dollar mark.
That's ten times what it was in the beginning. Now you can see it hasn't been a straight line. Like battle scars, our historical revenue metrics show off tough lessons learned. Now with those of you who see me at the sweet end of this graph, rockets all ablazing, you might ask, okay.
Well, what's the perfect pricing? Well, I'm here to tell you one big thing I've learned. It depends. This is basically evergreen mantra for every product situation, and it holds true here. It depends on the state of your specific product, the niche of your market, your timing, your branding, and so much more.
It's really more about using the product process to figure out what works for you. But there's a lot you can learn from other people's mistakes and journeys, which is why I'm sharing mine. In the early days, we just had some super simple functionality and two plans at low starting prices.
Our early customers signed on readily for these, but our average revenue per account was low. My cofounder and I continued to build up the application. We gave it richer functionality to serve the growing market, and then we launched our third tier premium and charged seventy nine a month.
Why? Because it was more than the package below. That was basically it. We weren't talking to our customers about how much they thought they should pay or running experiments to see what it could be priced at. We were just happy to see that they were paying.
And this went on for a couple quarters, and we ended up lifting the ARPA into the fifties. And at the time, we were just focused on building a product that solved needs and picked prices that sounded good and made sense given the context of the market we could see around us.
Starting simple wasn't a bad plan, and focusing on building out a product of value is, of course, what we should have been doing. But we also should have been talking to customers directly about pricing and how they buy. You can learn so much from five to ten customers.
Had we asked these questions, I would have discovered early on that we were undercharging for the value we were actually providing. I also would have learned a lot more about how people in the b to b world purchase software and would have invested a lot more in smoothing out that process over the years.
But as it was, we were pretty happy with our growth, not knowing what we were leaving on the table. We had a couple hundred customers to reflect on by this point in time, and it was around this point that we started seeing the real cracks forming in our pricing.
See, we'd settled on a popular configuration for pricing, good, better, best pricing. And if you don't know it by name, you know it by format. It's sort of the gold standard. Apparently, seventy percent of SaaS companies use it. It's when you have three options presented, starting cheap, and then they get more expensive as more gets bundled into the top tier packages.
And there's nice middle ground type of pricing between super simple products and those that have much more complex needs. And I can see why so many startups, including us, gravitate towards this format of pricing. You know, consumers are used to the good, better, best, and there's thousands of examples and familiar templates to copy from.
So little effort has to go into conjuring up your own pricing to match this. So at a stab, there's worse places to start from. The problem with good, better, best pricing is that it relies on excellent bundling or fencing. And this is easy if you've got a simple product and some straightforward enhancements that differentiate it into bundles that speak well to your different target segments.
Those enhancements should be drawn along lines that are value drivers. Your core good package has to deliver some value, and then your better and best packages need to deliver more value. Your own value driver will be unique to your product. Perhaps it's to do with the number of appointments booked or students enrolled or cars serviced or emails sent or whatever it is.
For good, better, best to work, you should be able to point to that one main value driver and create packages around that. You can have multiple value drivers, but it can be really tricky to stack these up into nice, neat bundles. Each feature bundled in a premium package should be driver enough to pull someone towards that package if they are in that right target audience.
None of them should be seen as superfluous. If so, you run into a problem where people feel like they're being charged for things in a bundle that they don't need. Even if the package isn't more expensive because of that feature, if there's something unused in that package, it drags the perceived value of that whole thing down.
And this is where we started seeing complications with our own pricing. We didn't have just one value driver, but we did recognize it as that. And we didn't do enough discovery to really suss out the problems. Instead, we were pretty reactive, but we did try this experiment to test out the edges of our bundles.
Bolt ons. They were a way to make our product configurable. It allowed people to add on things like extra products and user seats and integrations and other things to bridge the gap between the existing products we already supported and these custom products that they could create.
It was a bit of a mess to manage, but it was a way to see if people actually valued these things and if they paid for them. For example, we could see that people value the ability to add extra teammates more than the ability to manage extra products.
Their willingness to pay for that was higher. It was our first pricing experiment, and we were stepping into the unknown. We tried it out. We based it off some good old gut feel and qualitative research. Essentially, lots of conversations with our growing customer base.
Boltons was our way of doing it, but it wasn't the ideal way of going about it. Yes. It resulted in uplift, but it wasn't the leanest experiment. We could have learned more faster by doing a deeper analysis of what people were willing to spend and what features were truly driving value.
In hindsight, I could have used some deeper quantitative methods like each of these, which I'll explain. The Van Western Dorp is a goodie. It's a method of determining pricing sensitivity. It's all about nailing your product's pricing based on your customer's perception. You don't want it to be too expensive, nor do you wanna be too cheap.
There's a sweet spot, and this method will help you find it. And you need to ask these questions of informed users. They need to know what it is that they're responding about. So it helps if they are already existing customers or have seen a detailed demo.
Ask them these questions to learn things like, at what price is your product too expensive? At what price is it so cheap they think it's pure junk? This set of four questions helps you figure out your pricing sweet spot. You can then map out these answers on a chart based on the percentage of respondents who give you each answer, and it gives you four points.
One of which is your optimal price point. As in, just as many people think it's too cheap as it is too expensive at that point. Now that really just goes to show that you can't please everybody with pricing nor should you, but you can calculate how you can please the biggest segment of them, and that's a powerful opportunity.
And the Gabor Granger method is a great follow-up to the Van Westendorp because it can be used to strengthen the case or hone the numbers found in the previous method and discover new insights too. It's a super easy one to set up a survey for.
Just start off with a question to determine if the respondent would actually buy your product at a reasonable price. If they answer four, five, six, as in they would, then send them to the second question about specific pricing and start with the highest price point that you're considering.
If they answer one, two, or three to that, as in no, then bring them to the next price increment down. Have three to four price levels lined up in a survey format like this, and see how far down you have to go to get each respondent to say they'd be likely to buy.
Those answers can then be mapped out into a chart that shows what percent are willing to pay. This gives you a price demand curve. I wasn't switched on to these research methods at the time. This next phase was a really interesting time for us.
It represents one of our biggest failed pricing experiments ever. We introduced a starter plan. It was in response to the customer discovery work we'd been doing. We'd realized that there was a bunch of product people out there who wanted a low cost, simplified version of the product.
So we gave it to them, twenty bucks per year. But it attracted the wrong sorts of customers. Our bet was that these customers would eventually convert to regular customers, paying the usual hundred or so dollars a month on average that our existing customers did.
What we ended up with were a whole bunch of people who joined with Gmail or throwaway accounts, logged in personal credit cards for that twenty bucks, and then forgot about the product. So our number of customers shot up, but our ARPA went down on average.
Now this doesn't mean that your freemium or low cost experiments will fail. Your results may vary. Now we got a sense of this lower end market from customer discovery, and that led us to run-in that direction. And run with it, we did. Fundamentally, built for the low end of the market because some people told us to in customer interviews, and we struggled to say no to what seemed like it could be a really lucrative opportunity.
And I don't begrudge trying it. It was a valid test based on valid feedback. But we didn't treat it like a real experiment. An experiment should be something that is defined upfront with success criteria and target outcomes. It should have a trigger point at specific points after launch when it's specifically measured for success, and a call should be made on whether the experiment was a success or failure.
As it was, we simply didn't put enough into it to really see the right results and didn't make a fast enough call on whether it was working or not. So rather than creating a new channel of leads who were ready to convert, it created more noise and support effort for us.
We didn't have the sales firepower or even the marketing automation in place to really convert those leads into any meaningful revenue. But we had enough success with several hundred new customers signing on a short order to make it feel like there was enough big potential.
But in hindsight, it was a distraction from us crafting perfect packages out of the product we were building for our core market and wasn't the big catalyst we were hoping for. My lesson here is to be aware of pricing experiments with mixed results.
Be clear about what it is you expect to happen and shut it down if it's not right. In twenty seventeen, we introduced new plans, building in what we'd learned from the bolt ons experiment previously. Our pricing was all over the place by this point in time.
This initiative simplified it and lifted the pricing up to match the value we were providing to customers at this point. Our team was much more grown up at this phase. It was a lot less shooting from the hip. We'd spoken to hundreds of customers at this point in time and had lots of evidence backing up why they bought and what held them back when they didn't buy.
We actually did the Van Wessen Dort pricing sensitivity analysis to quantify price points before we launched them. We ran surveys to settle on the best package names. Hindsight is twenty twenty, though. And if I could think of ways we could really nail that relaunch of pricing back then, it would have been the inclusion of a proper conjoint analysis.
Conjoint analysis is sort of the mother of all quantitative methods for researching pricing and packaging. There are a bunch of different formats that a conjoint analysis can take, but some top use cases are things like identifying how respondents value combinations of features that you present to them or presenting them with a series of full descriptions of a certain product or bundle and then asking them which one they'd be most inclined to buy.
If done well, a Condroid analysis can help determine which features are most value and which ones aren't. Which mixes of features should go together to create the best possible sets of packages? This set of experiments and iterations served us well and resulted in a nice uptick in our ARPA and our growth in general.
The work we'd done got us closer to being able to charge based on the value we were providing and not based on what it cost to us. But it's clear here in this next phase that we'd stopped experimenting and had topped out with our ARPA figures.
We were just focused on building out our products and service and team in this period, but we're still seeing some of the same problems that we ran into with the good, better, best pricing early on. See, as the product progressed over the year, it became clear we weren't building just one simple product.
We're building a platform that has three distinct use cases and attract different types of users. Our pricing from the very beginning was all based on the assumption that we're pricing from one product, which has got richer in functionality as you went up the pricing tiers, And it was time to challenge those assumptions.
And besides having a direct impact on revenue, pricing also affects other critical business stats, things like your conversion rates and churn. And good is said to be the enemy of great. And while we had good growth and good revenue, we would never achieve greatness if we didn't rethink our assumptions from the ground up.
And what we found is that there were people who wanna be able to access deep functionality in the road mapping module, but weren't using the customer feedback stuff or vice versa. Or large teams who wanted basic levels of functionality, but for a large group of people versus small companies who had requirements for deep functionality, but for just a handful of people.
Our three packages, even though they were balanced the best we knew how, were just not cutting it. Good, better, best, at its best wasn't cutting it. What we needed to do was modularize our packaging, but doing so was way too big a challenge to take on in one go.
We needed to experiment and to derisk the move first. So the big bet of last year has been the concept of add ons, and it's absolutely an echo of the bolt ons experiment we hastily did in twenty thirteen. But this time, it's set up as an actual experiment to test the viability of this future modularization.
The great thing about pricing experiments is that you can see the impact in incredibly tangible ways when they work. You can see it in your bottom line. One thing we did learn is that people don't spend as much as they say they will.
We know because we measured it. We had a huge rate of interest, whoever we talked to, in these new add on options. But in reality, a smaller segment actually paid. And this is actually normal and expected. It's one of the biggest drawbacks of experimenting with pricing, doing any sort of surveys or talking to your customers about pricing.
People don't tell you the truth about what they pay. Simple as that. They sometimes don't even know if they can or would pay. You know, it's one thing for them to say they'd buy something and something else altogether to get them to enter their credit cards and and make the payment.
So make sure to never count your chickens before they hatch. The proof is always in the payment receipt. And now one of the daunting things about changing something big, like changing both your pricing and packaging, is often the scale of the change. You could be looking down the barrel of a big release to get some changes out, and you aren't even sure if your customers will definitely buy it.
So a Wizard of Oz experiment can help you here. It's a test when there's actually nothing truly technical going on behind the curtains. With pricing, you don't actually have to change your actual pricing to test your pricing. I always recommend that you test your pricing changes way up the funnel to see what happens.
So if you're raising prices, common move, just change it on your website first and see if it affects your trial sign ups. If people are still signing up and your conversion rate isn't affected, then you know that people are ready to try your product at the higher price.
It gives you confidence to change it in app. If your conversion rate tanks and people don't start new trials when they see this new price, then flip it back. Right? You don't have to make that change. It's just text and design that you've changed at this point in time.
No harm done. So make your changes further upstream to check as to what works or what doesn't work. When it comes to pricing changes, I also encourage you to just effing do it. With all the research methods and experiments, you'll never be a hundred percent certain till it's live and people are actually buying it.
And there's way more upside to running your pricing experiment with playing with pricing and seeing what happens. You're way more likely to learn something that eventually allows you to increase revenue than you are to take a hit on revenue when you experiment with pricing.
Now remember that there are two types of decisions. Some are type one, irreversible. You can't go back on them. But most are type two, reversible. Your pricing experiments, your pricing decisions are all reversible. If it goes sour, you can roll back, and there's no harm done.
So as long as you're ready to document and learn along the way, you're golden. Keep experimenting. Keep trying things. And one thing that will empower you to make changes is having a great policy for legacy customers that is allowing existing customers to keep their own plans.
It's a great way to thank them for their early support and hugely simplifies your ability to test and iterate for the new customers coming in. Means you can ask your existing customers really candidly, how much do they think your product's worth without them thinking that they're gonna get an imminent cost increase for themselves.
However, don't lock yourself into legacy pricing forever. It should be consideration you put forward if you can, but not a contractual obligation on your part. It's these sort of things that can make it really tricky or unpleasant to acquire or fund your business down the line if you end up having a whole bunch of custom contracts with all your old customers.
And we've talked a lot about different ways to experiment with pricing. So what about AB testing? Honestly, AB testing can get in the sea. It's my least favorite type of all types of experimentation. In some cases, AB testing is magic. If you work for Amazon or Booking dot com and you have eleven billion site visitors at any one point in time, you know, they're all doing impulse or urgent purchases, it makes sense.
It's easy to get statistical significance between two variations. But if not, you're otherwise gonna need to run tests for a long time. And during that time, you can't change anything else, or you end up with results that aren't trustworthy. They're not statistically significant.
The other problem is, particularly with pricing, people get tetchy. Right? Always assume that people will land on your pricing page more than once when they're making a purchasing decision. So if you're AB ing two different prices and someone comes back on, you know, day one to see price one and on day two to see another price, or if they're comparing notes with a colleague or checking it on a secondary device, you're going to look really untrustworthy.
They're not gonna know what to think. So you're better off running surveys and interviews that are upfront about the fact that you're testing pricing or running tests in time based cohorts. So all in all, I hope I've given you some tips today on how you can begin questioning the assumptions you've made in your pricing and stop leaving money on the table.
To sum up, you need to find your key value drivers that you can base your pricing around. You need to set pricing based on the value you deliver, not what it costs. You can get creative using a different mix of experiments. See what works for you.
And consider using discounts or bolt ons to test the edge of packages to see what works for customers before committing to any big overhauls. And treat your pricing experiments like you do any other experiments. Capture the expected outcomes, track the results carefully, and follow-up to get the most from the work that you actually do.
And on that note, I thank you very much for your time. Please do feel free to connect with me. I'd love to chat with you all, reach out if I can help in any way at all. Thank you, amazing product people of TuringFist.
