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.
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:
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:
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.
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.
There are three main reasons to add a brand new use case instead of improving the value of existing features:
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).
There are three ways to change your monetization model:
While adding new use cases, you’ll most likely either expand vertically or horizontally, so we’ll focus on those two approaches.
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:
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:
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:
With an option to expand to a new use case, with its own monetization strategy, such as:
This way, you maximize earnings from heavy users of background checks without increasing the price for headhunters not interested in this use case.
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:
Let’s use a Figma example again.
When Figma decided to go with an enterprise plan, it added functionalities like:
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:
Let’s look at two real-world examples of use case expansions to solidify our understanding of vertical versus horizontal monetization models:
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 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).
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 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, Product, UX, 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.
WAgile integrates the structured, sequential phases of waterfall with the iterative, flexible practices of agile.
Ryan Lee talks about how to focus on building your background, personal brand, and track record of success.
While you probably hear a lot about MVPs, two MVP concepts — a concierge and the Wizard of Oz — rarely receive much attention.
Maria Cuasay, Director of Product, Growth at Ancestry, talks about building MVPs and running experiments as fast as possible.