Freemium, pricing and monetisation: A product manager’s decisions
Free accounts are growing, but operating costs are rising faster than revenue. Or customers rely heavily on the product while their plan barely reflects its value. A product manager needs to connect price, customer benefit, costs and understandable rules.
01Start with what the customer is paying for
Pricing is more than selecting a number for a plan card. It shapes who the product serves, how customers can grow and when they encounter restrictions. Name the value first: completed jobs, supported locations, team collaboration or processed documents. Then find a unit customers understand and you can measure reliably.
Stripe distinguishes models including flat-rate subscriptions, per-seat pricing, tiered pricing and usage-based charging. Being able to implement a model does not establish that it suits your product. The choice should reflect the customer's actual work.
Per-seat pricing is easy to explain but may discourage people from inviting colleagues. Charging per document follows workload more closely but can create anxiety about unpredictable bills. A flat fee offers certainty, while leaving you to address exceptionally expensive usage. Calculate the bill for a small, typical and demanding account before choosing.
For a mobile product, also compare subscriptions, in-app purchases and advertising as different monetisation models.
02Decide what free access is meant to test
Freemium provides an ongoing free version with restricted scope. A trial provides access for a limited period. A guided demonstration lets you explain the product before implementation. These options address different barriers, so do not choose freemium simply because a competitor offers it.
| Option | When to consider it | What to establish |
|---|---|---|
| Freemium | Independent evaluation and low servicing costs | A meaningful reason to upgrade |
| Trial | Value becomes apparent within a limited period | Enough time to complete real work |
| Guided demonstration or pilot | Data, integration or approval is required | Implementation costs and buying process |
A free user should receive genuine utility. If you block the result before they understand the product, you are testing patience. There must also be a natural reason to pay, such as greater volume, more teams or control over more complex work. If most target customers can remain free indefinitely, a more prominent upgrade button will not solve the underlying issue.
Our guide to user onboarding and reducing early drop-off develops the path from registration to a first useful result.
03Build packages around needs rather than feature inventories
Describe the intended customer for each plan in one sentence. An independent specialist might need simple records; a manager of several teams might need responsibilities, approvals and capacity visibility. Customers can compare those differences more easily than three similar columns containing dozens of ticks.
Define what happens at a limit. Does a new action stop, do additional units become chargeable, or must an administrator approve an increase first? Customers need warnings and a view of current usage. Do not use basic security or reasonable access to a customer's own data as a trap to force an upgrade.
Use add-ons for needs with distinct value, such as a particular integration or additional service. Too many combinations make support and testing harder. When designing custom software, consider packages alongside access permissions. The pricing page and the application's actual behaviour must agree.
04Calculate the cost of free accounts
The following is an illustrative model, not a recommended price list or market average. It covers one month and 1,000 active accounts. A paid account generates EUR 20 per month and incurs EUR 4 in variable costs. A free account costs EUR 0.50. Variable costs represent directly attributable operation and servicing; amounts exclude taxes and involve no currency conversion.
| Paid share | Paid / free accounts | Revenue | Variable costs | Amount remaining after these costs |
|---|---|---|---|---|
| 2% | 20 / 980 | EUR 400 | EUR 570 | EUR −170 |
| 5% | 50 / 950 | EUR 1,000 | EUR 675 | EUR 325 |
| 8% | 80 / 920 | EUR 1,600 | EUR 780 | EUR 820 |
The middle row is 50 × 20 − 50 × 4 − 950 × 0.50 = EUR 325. This is not profit: fixed costs, development and customer acquisition still need to be paid. Nor does the table measure how many registrations upgraded during a period. It compares the share of paid accounts within one illustrative monthly population.
Substitute your own costs by customer segment. Examine accounts with large data volumes, external paid services or frequent support separately. An average can hide a small group consuming most of the capacity. Test limits, self-service guidance and the suitability of customers attracted by the free version as well as the price itself.
- 2% paid accountsRevenue: 400Variable costs: 570
- 5% paid accountsRevenue: 1,000Variable costs: 675
- 8% paid accountsRevenue: 1,600Variable costs: 780
Illustration, not a benchmark: 1,000 active accounts for one month. A paid account generates EUR 20 and costs EUR 4; a free account costs EUR 0.50. Shares of 2/5/8% mean 20/50/80 paid accounts. Revenue = paid × 20; costs = paid × 4 + free × 0.50. Differences of EUR −170/325/820 are not profit: fixed costs, development and acquisition remain. Taxes excluded.
05Measure conversion, retention and actual revenue
Always define the denominator and time window for conversion. For example, measure how many accounts created in a particular month paid within 60 days. Do not compare new registrations with users who had six months to decide. Track the first useful outcome and repeated use as well, to separate pricing problems from a product people do not understand.
MRR normalises recurring revenue to a monthly amount and excludes one-off fees, as ChartMogul explains. Do not count an entire annual payment as one month's recurring revenue. MRR is neither cash in the bank nor profit. Track new subscriptions, expansion, contraction and departures separately.
When changing prices, also compare retention, support demand and the resulting economics. A higher upgrade rate may have been bought with an excessive discount. A larger average payment could conceal smaller customers leaving. Understand the reasons instead of selecting the metric that looks most favourable.
06Test one clear hypothesis at a time
Use interviews to check whether customers understand the pricing unit and can estimate their own bill. Ask them to compare concrete options against their current situation. A general question about the most they would pay does not address implementation, budget or purchasing authority. Add real offers and record the reasons people accept or reject them.
Before an experiment, write down the hypothesis, target group, observation period and unwanted side effects. Do not change pricing, packaging, onboarding and advertising audiences simultaneously. With a small customer base, avoid claiming statistical certainty. Use repeated interviews and successive offers whose terms you can trace.
Bring product, finance, sales and support into the decision. The product manager combines their evidence but should not guess accounting consequences or promise changes the billing system cannot support. Keep versions of prices and terms so that you can establish which offer each customer accepted.
07Make monetisation work in day-to-day operation
For usage-based pricing, define the billable event, error corrections and the treatment of late records. Customer usage screens and invoices must follow the same rules. Stripe's usage-based billing documentation illustrates the dependence on measured usage. Choose the implementation route according to your existing setup and required capabilities.
Test failed payments, upgrades, downgrades and cancellation. Stripe supports retries for some failed payments, but certain declines require a new payment method. See the payment retry documentation. Record a dissatisfied customer leaving separately from a technical payment problem so that the response addresses the actual cause.
In your web application, account administrators should see their current plan, limits, next billing event and available changes. Prepare a process for disputed usage. An attractive pricing page cannot compensate for a confusing invoice or an unclear support response.
08Treat a price change as a product change
Separate new customers from existing ones. For current customers, check accepted terms, notification requirements and the effective date for the relevant contract and market. Do not assume a universal notice period. Decide whether to preserve the old plan, migrate accounts or offer several options.
Give support example invoices and answers to likely objections. Test monthly and annual subscriptions, discounts and changes during a billing period before launch. Afterwards, review complaints, billing errors and departures by group. A way to correct a poorly configured change belongs in the plan alongside the expected benefit.
09Frequently asked questions about product pricing
Is freemium suitable for every SaaS?
No. You need a useful free version, affordable servicing and a convincing reason to pay. A demonstration or paid pilot may suit products that require substantial implementation work better.
How many plans should we offer?
As many distinct needs as you can explain clearly and support operationally. Three cards are not compulsory. Each additional plan creates more rules, testing and decisions for customers.
What is a good free-to-paid conversion rate?
There is no useful universal percentage without a definition of accounts, time, price and costs. Compare your own equivalent groups and the amount remaining after costs, rather than conversion alone.
Should annual subscriptions be cheaper?
They may help cash planning, but a discount reduces revenue. Calculate the effect and consider the customer's commitment and cancellation terms. Annual payment alone does not demonstrate lasting satisfaction.
10Connect your pricing to the product
Send us your current plans, limit rules and a few anonymised examples of usage. We can review the connection to your application and billing and identify what needs checking before a change.