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 startup 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 posts, 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 have needed 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: how 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 the fact that it hopefully only occurs once.


Taken to extremes:


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 that 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 the 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 redo our time at Codecademy, I think we should have focused on user personas sooner and built 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 a 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 hindsight, it's 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.



The subtlety 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 to 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.), and the grouping that I’ve seen to be the most actionable is the subtle differences in why they are using your product.


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



The better 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.

‍