A guide to monetization models

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.

What is a monetization model?

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 friction you create — The more you ask from users upfront, the fewer users will be interested in the offering
• The type of revenue you optimize — Some models make it easier to capture new revenue, while others encourage more recurring revenue
• Your growth model — Different monetization models put friction in different elements of your growth loop; for example, it would be hard to build a growth channel with a fully paywalled serviceA monetization model shows how you capture value from your customers and what tradeoffs you take while doing so.
• Payback period — You can optimize for less LTV sooner or more LTV over a longer period of time
• How much revenue you leave on the table — There’s no perfect monetization model, and depending on tradeoffs you take, you’ll almost always have some inefficiencies

What is monetization strategy?

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:

1. Monetization models don’t exist in isolation and must align with how you deliver value to users
2. You might serve multiple primary use cases, requiring more than one monetization model in your offering

Let’s look at an Amazon marketplace as an example. Some use cases they might serve might include:

• “I’d like to purchase items at a discount”
• “I need an item delivered to me as soon as possible”
• “I want my favorite items to be delivered on a recurring basis”

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.

Defining use cases

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:

• “I want to travel cheaply from place A to place B regularly”
• “I want to get to my designed destination as soon as possible”
• “I want to get to my designed destination at a high comfort standard”
• “I want my package to be delivered to a destined location”

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:

1. Problem
2. Audience
3. Alternatives
4. Why
5. Frequency

Let’s use a hypothetical example: Uber is designing a new high-standard transportation service called Uber Luxury.

1. Problem — What is the distinct problem you are solving?

In the example, it would be, “I want to get to my designated destination at a high comfort standard”.

2. Audience — Who is the persona you’re targeting?

Different products can solve the same problem for different people. And different people, although sharing the same problem, have different:

• Expectations
• Willingness to pay
• Willingness to commit

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.

3. Alternatives — What are alternative options to solve the given problem for a given audience?

For example, some ways to “get to the designed destination at a high comfort standard” could include:

• Renting a limo
• Getting a private chauffeur
• Using a luxurious taxi service

Brainstorming these will help you identify and benchmark competitors’ monetization models and look for potential risks and opportunities.

4. Why — Why do or would users choose your product over the aforementioned alternatives?

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.

5. Frequency — How often does your audience experience the problem?

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.

Elements of the monetization model

There are various ways to approach defining a monetization model. However, there are four key elements:

• What (what do you charge for?)
• Scale (how does the price scale?)
• Price (what’s the actual price-point you charge?)
• Timing (when and how often do you ask users to pay?)

Let’s continue with our Uber Luxury example.

What

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:

• Luxurious standards car (core value proposition)
• Ordering on demand (differentiator from alternatives)
• Tracking car locations
• Ability to receive company invoices (specific need of the audience)
• Pre-ordering and having the driver wait in a designer location (specific need of the audience)
• Having the driver on a stand-by in between trips (specific need of the audience)
• A professional driver with a confidentiality clause (specific need of the audience)

Scale

The next step is to understand how the price is going to scale.

Without proper price scaling, you’ll either:

• Undercharge heavy users, leaving money on the table
• Overcharge infrequent users, probably scaring them off

There are three ways to scale the price. You can do it based on:

• Features (the more features you get, the more you pay)
• Usage (the more you use the product, the more you pay)
• Outcome (the more value you get, the more you pay)

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.

Price

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:

• Probability questions
• Indexing
• Van Westendorp’s pricing surveys
• Mock sales

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.

Timing

The last question is to decide when to charge the customer.

There are three main timing models:

• Never
• Transactional
• Recurring

Never

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.

Transactional

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.

Recurring

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.

Monetization model examples

Now, for a more practical example, let’s look at two more monetization examples:

• Figma
• Thumbtack

Figma

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
• Small teams
• Enterprises

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

Thumbtack is a two-sided marketplace that connects home renovation professionals with homeowners in need. There are two main use cases:

• On the buyer side, to connect with the professional to get the job done
• On the professional side, to gain new clients:

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.

Closing thoughts

The monetization model is an inseparable part of each high-level use case your product serves.

Mapping it is a valuable exercise to:

• Ensure you are conscious of your strategy
• Help you spot places where your monetization model might misalign with the value you deliver or the audience you serve
• Give you an artifact to inspect and adapt

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