Last night, when I went to open Spotify, I was greeted with the below screen.
Spotify just increased its prices in the US from $9.99 per month to $10.99 per month. Netflix also raised prices multiple times, but most recently in 2022.
Price is one of the most powerful levers that you have in your business, so how should most companies think about pricing?
Despite all of the complications that a subscription model brings to calculating LTV, it's still one of the most important metrics that you have as a company.
If you want to increase the value of your company in a sustainable way, you need to increase revenue. To increase revenue, you should be focusing on getting LTV as high as possible.
There are really only 2 ways of doing this:
As I've mentioned in previous posts, getting users to stay around longer can be tricky for mature products, as a lot of products sit in a use case that have a certain "natural" end to them that is only a few months long.
If your product focuses on diet, fitness, mediation, finding a job, dating (etc) then you're probably looking at average user lifecycles that are under 6 months.
Short of selling annual plans or lifetime plans, as a lot of companies in this space have done, this isn't a lot that you can do to scale up LTV that isn't a prices raise.
There is no definitive measure that will tell you if you are charging too much or not enough. You have to research your competitive set and test this change for your self.
The thing that you should be trying to do is to charge at the maximum price for your users, your strategy, and the growth rates that you want.
Price raises are tricky because they have: knowable positive impacts, unknowable positive impacts, knowable negative impacts, & unknowable negative impacts.
Some of these will show up within the measurement window of an A/B test, others wont :)
You can't say exactly what is going to happen, but assuming that you run a successful pricing test (more on that below), you can should be able to anticipate a range of impact:
Despite all of the complexity and uncertainty on this topic, I am still big believer in testing your pricing several times per year.
There is no faster way of raising revenue that just charging more for the product. Patrick Campbell has mentioned testing a price raise once a quarter, which I agree with especially for more mature companies (on this podcast which is great btw).
I have never met a company that wasn't emotional about their prices and doesn't have an internal bias against raising prices mostly based on fear of failure.
It's just human nature. Price is where you have to put a number on all the hard work that you have done and see if the market accepts it. That alone produces anxiety.
Assuming that you want to test this (and you should), I would do the following.
There are a lot of ways of raising prices, the least risky one is just raising them for new users who have never tried the product before. They don't have a concept of the "existing" pricing, so there is not a lot of risk of blowback.
The most risky version is raising prices on the existing users. This is where companies typically experience the most blowback.
Other, more subtle tactics include include raising the prices of one of your plans, such as the monthly plan only.
Alternatively, if your paywall structure has any concept of metering (such as Zapier does with the number of tasks), you can lower the amount of credits in a tier which effectively increases the price.
This is one of the many reasons that I like metered paywalls, as it gives you a lot of flexibility.
There are a lot of methodologies to do pricing research, all of which sound very fancy and impressive, but none of them will tell you what your users will actually pay for the product with the same degree of confidence as a pricing test.
When we did this at Codecademy, we did the following:
It will obviously stay on the pricing page, but limit places like blog post, forums, drip email sequences where uses might not see the same price package they see on the product . This makes test set up a lot easier.
You might have to also exclude any users coming in through paid channels who may or may not have been exposed to pricing.
Design the test to both control for risk and make sure you're measuring to a high level of confidence
Our primary KPI was revenue per allocated user, meaning we wanted to increase the overall revenue of the user base. We only tested on new users.
We measured through the end of the first month of churn and our trial period. We also monitored plan ratios (between monthly and annual) as well as on platform actively.
Make sure everyone understand the value that is created and you have full exec level buy in on the results.
You need a very high level of buy in to get these tests approved, so allocate time to chase down all the edge cases and lingering questions.
The most common argument that a company makes in these posts is that they have added a lot more value to the product. Whether this is true is up for debate, but it seems to be the standard line.
I'd suggest being clean on the mechanics of:
At Codecademy, we actually did 2 other things that gained us some additional revenue from a price raise.
We were raising prices across the board, so we took the chance sell a few more annual plans with the message of "lock in a lower price" before this happens.
Because we were only raising prices for new users, we dropped a quick message in the cancellation flow for users telling them that:
This wasn't a major needle mover, but every little bit helps when it comes to lowering churn.