Paywall Strategy: Designing Features that Make Money

If your revenue isn’t growing fast enough, you might have fallen into one of the classic startups traps. Over serving your existing customers.

You got to where you are by knowing your customers and building things that they like and use.

However, the day comes when revenue starts to flatline or growth starts to slow.

Almost every start-up founder’s initial response to this is to just go harder. Crank out even more “classic” features for their core users and hope this does the trick.

Now sometimes this does work (and if so, great), however sometimes this doesn’t work and you need to figure something new out.

How Features Increase Revenue

In my opinion, most of the content in the “monetization strategy” space is fluff.

If you want to increase your revenue for a subscription product, you only have 3 options:

1. Attract more users
2. Collect more money from your existing users each month
3. Keep users subscribed longer

Those are really it. Whatever you are building needs to be able draw a line to one of these goals.

If you are shipping a lot of features and you’re not seeing revenue go up then, by definition,  they are not accomplishing any of these goals.

As we’ll explore below, within each of these categories, there are a lot of options within these groups.

The Problem Ceiling & LTV

As we’ve talked about in past post, the core constraint on your LTV is how long your user experiences the underlying problem that your product solves.

Users fundamentally buy products to address a problem that they have and their retention is going to be capped by how long that problem exists.

For example, I need power to my house for years whereas I am only going to focus on losing weight for a few months. Those are just the nature of those problems.

However, when you think about your “ceiling” for your LTV, there is a second important factor, howe valuable solving that problem is.

While entertaining myself during a long commute is a problem that I will experience for a long time, solving it isn’t that valuable. I might pay a few dollars a month to solve it.

Fixing my broken air conditioner however, is a problem that I will pay thousands of dollars to solve, despite that it hopefully only occurs once.

Taken to the extremes:

• If you are solving a short term, not essential problem, then your LTV will be low.
• If you are solving a long lasting, high value problem, your LTV will be high

If you are thinking about building features to increase your revenue, you should first be thinking about the underlying problem that trying to address for users, as this will become the ceiling of your LTV.

If you just keep building companion features for the same users for the same problem, you likely won’t see any difference in revenue growth.

The Secret Sauce: Who vs What

I’d argue whether your features make you any money depends less on what the feature is and more on who you’re building it for.

If you are building an “auto update your data” feature, that is worth very different amounts to a social media analyst vs a hedge fund manager.

The value of feature itself is dictated by the value of solving the underlying problem for that user.

Because of that, they will pay you wildly different amounts to solve it.

If I could go back and re do our time at Codecademy, I think we should have focused on user personas sooner and build specific features to monetize each of them.

Codecademy, like a lot of companies that built a great product, attracted a lot of different types of people.

We broke our user base down into the following personas:

1. Students/Hobbyists - people using the product for school work and/or just for fun
2. Career Up Skillers - people who want to add coding skills to their professional skills. Such as an excel based analyst to a python based analyst
3. Career Switchers - people who want to go from something that isn’t programming to becoming a full time engineer. Such as an paralegal to a back end engineer.

What we started to learn more as we focused on monetization, is that the vast majority of the people we were attracting were in bucket #1 and were very difficult to monetize.

With the benefit of hindsights, its now easier to understand why.

The problem of “teach me to code” while conceptually similar is actually worth a different amount to each of these personas and needs to be solved slightly differently.

• For Students, this basically means help me with basics of HTML & CSS to build a simple site that I can show to my friends. Solving this is worth almost nothing.
• For Career Up Skillers - this means help me map my existing knowledge and workflow of a tool (like spreadsheets) to a different, more technical tool (like Python or R). This is worth a few hundred dollars
• For Career Switchers - this means teach me a totally new set of theories, tools and techniques and also give me the ability to pass job interviews. This is is worth thousands of dollars.

The subtly here that matters is that how exactly you solve the problem matters.  The earlier that you focus on this, the better you’re going to be at it.

So What Do You Do With This Information?

Going back to our original framing, if you want to increase revenue, you have do one of the following things:

1. Attract New Users - these can be more of the same user, adjacent users, users who value the problem more, etc
2. Charge More Per Month - this can come in the form of raising prices, changing billing terms, creating a higher tier of service or selling add one.
3. Keeping Users Subscribed Longer - this can be getting better at solving your current problem, tackling related problems, tackling longer term problems, extending contract lengths, etc.

The first step here is starting to look at the features that you’re building and trying to understand which of these groups each feature is in.

The second step is to start to break your user base into personas, or the underlying groups of users that you have within your user base.

There are a lot of different ways of looking at personas (demographic based, geo based, etc), the grouping that I’ve seen to be the most actionable is the subtle differences on why they are using your product.

Or said more specifically, why they are looking to solve the problem that your product addresses.

• If you are hotel, technically everyone is here to sleep in a safe, comfortable place. However this means different things for business travelers, couples on a romantic trip or families on vacation.
• If you are DuoLingo, technically you help people learn different languages, but how this is different for people learning languages for work, learning as a hobby, or looking to reconnect with family.
• If you a power company, you need to treat the risk of a power outage very differently for residents, businesses or hospitals.

The better that you understand your users, the more likely you’ll be able to correctly map out the subtle differences in how they view the problem, pick out the valuable users, and design better solutions that will drive more revenue.

‍