How to monetize new features and use cases

As your product grows and develops, you’ll often add new use cases to deliver more value to existing users or capture new user segments. Each new use case requires you to rethink your monetization model.

In this guide, we’ll discuss the importance of monetization when introducing new features, when you should consider adding a new use case and expanding your monetization strategy, and the difference between vertical and horizontal expansion.

Importance of monetization when introducing new features

Your monetization model represents the fluid and ever-changing way you capture value for your business from the value you deliver to customers.

The optimal monetization model depends on three main factors:

1. Use cases you solve
2. The audience you target
3. The competitive environment you operate in

Whenever one of these changes, so should your monetization approach. Yet, it’s common for product teams to develop new functionalities and solve new problems without regularly considering how they fit into existing models.

The more often you do this, the higher the risk that your monetization strategy will misalign from your value offering. As a result:

• You might lose both users and revenue with a suboptimal monetization approach
• Over time, your monetization strategy will become so outdated that you’ll need significant changes to catch up, which can create friction and dissatisfaction for users

Of course, not every feature you add requires changes in the monetization model, especially if you are an early-stage company still looking for product-market fit.

But as your product matures, adding new use cases will become increasingly more impactful on your model. You must consider all aspects of the business and make conscious decisions.

Use case vs. feature

By adding a new use case, I don’t necessarily mean every single new feature. We talk about a new use case if you solve a significant problem for your existing or potential customers.

For example, let’s say you’re building a restaurant reservation tool. If you add the ability to preselect specific seats for specific people while booking a table, you’re not solving a brand new problem. You’re expanding how effectively you solve the “I want to book a table upfront” problem.

You create a new use case when you add a new functionality that serves a new purpose in the product. In the restaurant reservation tool example, it could be an option to order takeout meals for delivery via your app. It creates new value by solving a new problem and targeting new user segments. That’s a new use case.

When to add a new use case?

There are three main reasons to add a brand new use case instead of improving the value of existing features:

1. Expand target audiences — Expanding your reach and targeting new audiences often requires solving brand-new, adjacent problems
2. Cost-to-serve — If the new feature you add significantly influences the costs you acquire, it makes sense to treat it as a separate, standalone service
3. Segment differences — If some of your user segments have specific needs and willingness to pay, it’s wise to create a new offering targeting only a subset of users

An example would be Figma adding an enterprise plan. It doesn’t add much new value for existing users, and enterprise users have more demanding needs and are willing to pay more to cater to those needs. Adding enterprise features to the core product would be suboptimal; thus, Figma created a brand-new use case (new plan) targeting the new audience with a different monetization strategy (different terms, timing, pricing).

Vertical vs. horizontal monetization model expansion

There are three ways to change your monetization model:

1. Change the current rules of the model
2. Expand/contract horizontally
3. Expand/contract vertically

While adding new use cases, you’ll most likely either expand vertically or horizontally, so we’ll focus on those two approaches.

---

Over 200k developers and product managers use LogRocket to create better digital experiences

Learn more →

---

To understand how vertical and horizontal model expansion differ, let’s look at an example. Say you’re building recruitment ATS software and currently solving two main use cases:

1. A use case for solo headhunters to invite and process hand-picked candidates
2. A use case for enterprise recruiters to connect job listings and screen and process hundreds of applications

You monetize these two use cases separately with two different plans, each with different features, contract terms, and pricing adjusted to different target audiences:

In this case, a vertical expansion of the monetization strategy would mean adding a separate, third plan to the mix.

For example, if you identify a new segment with a new need — say, hiring and managing international contractors — it makes sense to create a new plan serving these use cases, especially if existing segments are not interested in the functionality. It would mean a separate monetization model for that use case with a set of rules optimal for the given audience and use case:

Horizontal expansion happens when you try to monetize the new use case as an additional service in your existing mix.

For example, say you discovered an underserved need in your current segments, such as background checks. On one hand, both headhunters and enterprise recruiters need this feature, so it doesn’t make sense to create a brand new plan for it. On the other hand, background checks are expensive. So, just adding it to existing plans would either result in:

• Lower margins due to higher cost-to-serve
• Increased price, making the offering less compelling for users who are not interested in background checks

The optimal scenario here would be offering it to everyone, but as an expansion with its own monetization strategy:

This wouldn’t change the default monetization strategy for both main use cases but would give users an option to expand the value they’re getting.

For example, a monetization plan for headhunters could be:

• Features — A specific set of headhunting features
• Price — $200
• Timing — Recurring every month
• Scaling — $0.10 commission for every new candidate in the database

With an option to expand to a new use case, with its own monetization strategy, such as:

• Features — Background checks
• Price — $10
• Timing — Transactional, per every use
• Scaling — With every new background check

This way, you maximize earnings from heavy users of background checks without increasing the price for headhunters not interested in this use case.

When to use vertical vs. horizontal expansion

The example above should give you an idea of when vertical expansion makes more sense versus horizontal expansion.

Consider three main factors when deciding between horizontal and vertical expansion:

1. Consumer value — If the new use case is applicable and desirable to different segments of users, it makes sense to allow everyone to benefit from it by expanding horizontally. However, if only a specific niche cares about a particular set of functionalities, creating a separate offering (e.g., a separate plan) for these users might be more optimal to better package the value for the niche and not dilute your value offering for other segments by promoting add-ons they don’t care about
2. Cost-to-serve — If the cost of serving a new use is high, horizontal expansions seem safer. Otherwise, it’d be hard to define a price point where you don’t lose money by setting the price point too low or scare casual people off by setting the price point too high
3. Price scaling — The vertical use case makes sense if the price you want to charge scales similarly to your main model. If it scales differently, horizontal expansion might be a better approach

Let’s use a Figma example again.

When Figma decided to go with an enterprise plan, it added functionalities like:

• Design systems
• Shared libraries
• Custom permissions

The value of these additional features scales the same way the team plan scales. The more editors you have, the more you collaborate using new features, and the more value you get (and the more you pay).

Creating a second, more expensive plan with added features and a higher cost per editor made sense. The pricing was clear and addressed the price sensitivity of a specific segment (enterprises).

Now imagine Figma decided also to create paywalled online courses teaching basic design skills. In this case, it wouldn’t scale in the same manner. You might have 20 junior editors who would benefit significantly from these courses, or you could have 20 pros that don’t need them at all.

That would make horizontal expansion problematic. One client could have three juniors and 17 seniors, thus getting very little value out of the plan with e-learning, while another could have an entire team of juniors heavily using the courses. Value doesn’t scale in the same manner.

And if you decided to scale the price with editors and course learners in the same plan, the pricing would be very confusing.

In that case, expanding horizontally is more efficient and user-friendly. For example, Figma could charge extra for every course taken or on a per-hourly basis without affecting default plan prices. That would allow Figma to charge only those users who actually benefit from it and scale the price with usage:

Examples of vertical and horizontal monetization strategies

Let’s look at two real-world examples of use case expansions to solidify our understanding of vertical versus horizontal monetization models:

• Uber Pool
• Peerspace add-ons

Uber Pool

Uber realized that a segment of users is interested in rides on demand, but this segment is also very price-sensitive. So Uber decided to expand vertically with an option to order a shared ride with other riders.

The vertical strategy made sense because the cost-to-serve is similar or even lower than other use cases, it’s valuable only to a specific segment of users that’s price-sensitive and less privacy-sensitive, and the value you get scales similarly to normal Uber rides (i.e., with the number of miles traveled).

Peerspace add-ons

Peerspace allows you to rent a space for various types of events. Over time, the company learned that guests have more needs than just space. They often need to organize equipment on their own or organize catering.

So, Peerspace expanded horizontally, allowing it to, among other things, add catering with fixed price-points per guest and provide equipment on a per-event basis. These options are available regardless of how much you pay for the space you rent.

The horizontal strategy made sense here because these needs were common among different groups of guests (both those renting cheap places for a few hours or expensive places for multiday events), the price doesn’t scale with the number of guests (only half might be interested in catering), and providing these extra services is expensive (charging on a per-case basis rather than giving it to everyone allows them to control costs).

Wrap up

You don’t need to change your whole monetization approach with each new use case. Sometimes it’s OK just to add it to your existing model to improve the value you deliver. The important part is to do so consciously.

If you keep solving new problems and delivering new value without thinking about your monetization model, you might lose money on the table, scare loyal customers off with higher prices than they perceive as valuable, or lead yourself into a position where you have to create significant changes in your monetization strategy, resulting in high user dissatisfaction.

If the price scales similarly to your current model, the cost-to-serve a specific use case is similar, and there’s a well-defined segment that needs that use case, consider vertical expansion by adding a new tier to your plan mix.

If the price scales differently to your current model, there’s a high cost-to-serve a specific use case, and/or the use case is valuable for most of your users, consider horizontal strategies by allowing add-ons and expansions for all types of users.

Use cases and monetization models don’t exist in isolation. You can’t think about one without considering the other.

LogRocket generates product insights that lead to meaningful action

LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.

With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.

Get your teams on the same page — try LogRocket today.

Share this:

• Twitter
• Reddit
• LinkedIn
• Facebook