Monetization strategy is a critical part of every product development. It ensures you balance generating value for users with creating revenue for the business.
However, many people simplify monetization to slapping a price tag on features and services. In reality, it’s a much more complex topic.
In this article, you will learn what the monetization model is, the elements that make it up, and examples of it in practice.
A monetization model shows how you capture value from your customers and what tradeoffs you take while doing so.
It includes how much you charge, how often, what for, and how the price scales over time for a specific use case.
Your monetization model impacts:
The first step to building a monetization model is understanding the use cases you’re solving for. By use cases, I mean high-level problems your product solves.
It’s the most important part for two reasons:
Let’s look at an Amazon marketplace as an example. Some use cases they might serve might include:
Monetizing these three use cases together would be ineffective.
Users that want to purchase items at a discount are probably more price-sensitive and shop with you irregularly. Small transaction fees make the most sense, especially if you place them on the seller’s side (that way buyers feel they’re buying at a discount).
Shoppers that need an item delivered as soon as possible have a different need — express delivery. It requires more costs on Amazon’s side, but these shoppers are also willing to pay extra, so Amazon can charge more for service. Making it a separate service with a separate price point paid by buyers in need makes sense.
Those who want items delivered repeatedly also require different features and a different monetization approach. Here Amazon could use a monthly subscription model (maybe even with a yearly model to incentivize revenue retention), which wouldn’t be feasible for the two previous use cases.
Here you have one product with three different use cases and three different monetization models for these use cases.
The combination of all monetization models you implement is your monetization strategy.
For monetization purposes, think of use cases on a high level. You want to focus on the main problems you are solving.
As an example, high-level use cases for Uber would be:
These four use cases allow us to design four different sets of solutions for these problems.
My favorite way of defining a high-level use case has five parts:
Let’s use a hypothetical example: Uber is designing a new high-standard transportation service called Uber Luxury.
In the example, it would be, “I want to get to my designated destination at a high comfort standard”.
Different products can solve the same problem for different people. And different people, although sharing the same problem, have different:
This will be an important insight when defining the monetization model.
In this case, let’s assume that you researched and discovered that busy executives traveling for work purposes are an underserved segment you want to target.
Their needs and willingness to pay will differ from “middle-class casual riders” that are already served by Uber Black.
For example, some ways to “get to the designed destination at a high comfort standard” could include:
Brainstorming these will help you identify and benchmark competitors’ monetization models and look for potential risks and opportunities.
For example, suppose one of the main reasons users choose Uber Luxury over renting a limo is due to lower price. In that case, it’s a valuable insight that you can’t charge more than this competitive alternative.
It could be daily (Instagram), weekly (Netflix), monthly, yearly (TurboTax), or every now and then (homes.com).
Understanding your frequency will help you nail your billing frequency. It wouldn’t make sense to share a subscription for a home-purchase website or ask users to pay a one-time fee every time they use Netflix.
Let’s say that you learned that your audience needs a car several times a week, but there are both busy weeks when they use it a lot and slower weeks (you’ll need that insight later).
The more researched and well-defined your use case is, the easier it will be to create an efficient monetization model, so don’t rush through this exercise. Put in the effort, and it’ll pay off in the next step.
There are various ways to approach defining a monetization model. However, there are four key elements:
Let’s continue with our Uber Luxury example.
The first step is to define the packaging, or how the users will interact with your product.
Start with basic solutions to solve the high-level problem. If the problem you are solving is “I want to get to my designated destination at a high comfort standard,” you must first and foremost provide a luxurious and comfortable car.
Then look at why this audience would choose your solutions over alternatives. If it’s the ability to order the car on demand on their phone, or the ability to track the exact location of the car, you need to provide these functionalities to your customers.
Over time, keep talking to your users and improving their experience by adding the functionalities they desire (and are willing to pay for) the most while removing all the unnecessary noise.
A set of features for high-comfort transportation for executives could include:
The next step is to understand how the price is going to scale.
Without proper price scaling, you’ll either:
There are three ways to scale the price. You can do it based on:
Ideally, the price should scale as the perceived value for the audience scales.
While for casual users who want to get from point A to B, an optimal value proxy is the number of miles traveled (the more you travel between destinations, the less you need to travel on your own or with public transport), it might be different for executives.
Not only do they pre-order cars to wait for them so that they don’t waste time waiting for a pickup, but they also tend to take a lot of short trips throughout the day and prefer to have the same car with them until they finish meeting, rather than repeatedly ordering and waiting for service.
In this case, there’s more value in actual car availability than the distance traveled. So it makes more sense to increase the price as the car availability increases.
Now it’s time to answer how much you charge per unit of your value metric.
In your case, you decided to scale the price with car availability. Now, how much should every minute of car availability cost?
Pricing strategy is a complex and multi-faucet topic, so in the scope of this article, I’ll cover it on a high level.
Start by understanding your audience’s willingness to pay for the features you deliver. For example, company executives that use corporate funds to travel will be less price-sensitive than casual middle-class drivers.
There are many willingness-to-pay tests you can conduct, such as:
These should give you an acceptable price range that you can charge.
Then it’s helpful to compare it with use case alternatives and as well as review reasons why executives would choose Uber Luxury over other options.
If the main reason is a lower price, you should adjust your price to be significantly cheaper than the price of alternatives. If it’s not feasible for you, you might want to investigate if there are some features you can remove from the packaging to lower the price point.
On the other hand, if the main reasons are the added flexibility and features, charging a higher price-point than your alternatives might be reasonable.
Make sure the price you charge is aligned with your audience’s willingness to pay and why they’d choose your offering over the alternatives available.
The last question is to decide when to charge the customer.
There are three main timing models:
Some use cases shouldn’t be monetized. If your growth model is based on a freemium offering, then you should serve some free use cases and have a strategy to convert users from them to paid use cases down the road.
Paying per transaction basis works best (in your case, it would mean a per trip basis) if the product is used sporadically, and you don’t need a long-term commitment to build a habit.
Depending on the use case, it can be a weekly, monthly, or even yearly payment. Don’t limit your thinking to fixed-price subscriptions. In your case, recurring billing could mean charging every month for the total of minutes accumulated in the last month.
The frequency of use and its predictability are key here.
In your case, we identified that executives would need your service several times a week. However, there might be weeks when the service is used heavily and weeks when your audience won’t travel that much.
Now, for a more practical example, let’s look at two more monetization examples:
Figma is a collaborative design tool, and its monetization model looks more or less like this:
It serves three main use cases for three different audiences:
Solo designers use it to work on personal projects, so they don’t require many functionalities apart from just setting up projects.
Since Figma builds its growth strategy based on virality, they provide the service for free, even allowing customers to invite an extra editor to fuel its virality loop.
Small teams have different needs. They need to work on multiple projects and make their work easier by sharing libraries, version history, and custom permission.
Because Figma values collaborative design, and collaboration is hard to measure, they charge on a per-editor basis, as it’s an efficient proxy to measure “how much collaboration the team gets.”
The frequency of use is high and predictable, so monthly recurring billing makes sense.
Enterprises have different needs, so they deliver even more value for their use case of managing a company-wide design process. Although they require extra functionality, their willingness to pay is higher, and so is the price point.
Lastly, it often takes a few months for the company to get used to working together on Figma, so Figma decided to go with an annual lock-in to ensure customers build the right habits around the product before renewing.
Thumbtack is a two-sided marketplace that connects home renovation professionals with homeowners in need. There are two main use cases:
Let’s start with the professional side.
It provides everything needed to acquire a new client (without any extra fluff).
The main value for professionals is the revenue they gain from the platform, but since it’s hard to track (these services are often settled in person), Thumbtack decided to charge per acquired lead. The assumption is that the more leads you generate, the more you earn in the long run.
The job is very seasonal, and different professionals will have different amounts of leads, so Thumbtack decided to go with transactional billing and charge per captured lead (value realized).
Now let’s take a look at the homeowner’s use case.
Once again, Thumbtack delivers all they need to fulfill the use case without any unnecessary features. It also allows Thumbtack to keep the costs to serve the use case low.
These low costs are essential, as Thumbtack decided not to charge homeowners at all.
First, their willingness to pay is already very low (they already have to pay the professional). Secondly, since Thumbtack is a marketplace, it must provide a constant supply on at least one side.
Not charging homeowners means more homeowners will join the platform, attracting more professionals and eventually generating more revenue.
The monetization model is an inseparable part of each high-level use case your product serves.
Mapping it is a valuable exercise to:
Although these exercises are time-consuming, ensuring the best fit between your current monetization model and the use case you serve is the most efficient way to maximize your revenue and fuel further product development.
Featured image source: IconScout
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.
Concept evaluation bridges the gap between what seems like an out-of-the-world idea and what users truly need.
Nick Ehle talks about minimizing dependencies by designing teams and organizations to be as empowered as possible.
Value-based pricing is about using the perceived value, also referred to as willingness-to-pay, to set the right price points for the product.
Carolina Devia Angarita about the importance of understanding who your customers are and what they’re thinking when they come to your site.