The same user need can be served by completely different revenue mechanisms — and each one reshapes product design, pricing, and growth. A reference catalogue of eight, and how to choose.
▸ Try the interactive toolA business model is the mechanism by which a product creates value for users and captures a portion of it as revenue. The same user need can be served by fundamentally different models — each with different implications for product design, pricing, distribution, and growth. PMs who deeply understand their business model make sharper product decisions, because the model dictates what “good” even means.
This tool is a reference catalogue of the common tech business models, plus a method for choosing or evolving one. The key insight is that the model isn't fixed by the product — it's a choice, and adjacent models often unlock new growth. A subscription product might add usage-based pricing; a transactional one might layer on a subscription tier. Knowing the menu is what makes those moves visible.
How you create value (the product) and how you capture it (revenue). The capture mechanism — subscription, transaction, usage, and so on — shapes everything downstream: what to optimise, how to price, how growth compounds.
Teams often inherit a business model without examining it, then optimise the product for the wrong thing because they never questioned how value is actually captured.
| The shortcut | What it costs | What it gives you instead |
|---|---|---|
| Unexamined model | You optimise for the wrong metric because the model was never questioned. | Understanding the model clarifies what “good” means for your product. |
| Model-product mismatch | A great product on the wrong model still struggles to capture value. | Matching model to value-delivery makes capture efficient. |
| Missing adjacent models | Growth stalls because an obvious model extension goes unseen. | Knowing the full menu reveals adjacent revenue opportunities. |
| Copying a model that doesn't fit | Adopting a rival's model when your value works differently. | Choosing deliberately fits the model to how you actually create value. |
Each captures value differently — and the same user need can often be served by several, each reshaping what the product should optimise for.
| Model | How it captures value | Watch out for |
|---|---|---|
| Subscription (SaaS) | Recurring fees for access | Retention is everything; NRR below 100% is shrinking |
| Transactional | A cut of each transaction | Needs volume; revenue tracks usage closely |
| Marketplace | Commission on matched supply/demand | Cold-start & balancing both sides |
| Usage-based | Pay for what you consume | Revenue less predictable; aligns cost to value |
| Freemium | Free tier funnels to paid | Conversion rate & free-tier cost discipline |
| Advertising | Monetise attention, not the user | User incentives can conflict with advertisers |
| Licensing | One-time or term license fees | Weaker recurring revenue; upgrade cycles matter |
| Platform / ecosystem | Take rate on third-party value | Needs critical mass; governance is hard |
A subscription product had plateaued: every customer paid the same flat fee regardless of how much value they extracted, so the heaviest users were wildly underpriced and growth from existing accounts had stalled.
Examining adjacent models, the team layered a usage-based component on top of the subscription base — keeping predictable recurring revenue while capturing more from power users whose consumption had been effectively free. The product didn't change; the capture mechanism did, and expansion revenue followed.
The deliverable is your current model identified, with adjacent models evaluated for fit — a map of how you capture value and where you could capture more.
| Step | Question |
|---|---|
| Map current model | How do we capture value today, and what does it make us optimise? |
| Spot mismatches | Where does our capture diverge from where we create value? |
| Evaluate adjacents | Which neighbouring model could capture more, given how we deliver value? |
| Decide | Evolve, layer, or hold — with the implications named |
The business model silently sets the definition of a “good” product decision. Optimise hard under a model you never chose, and you may be perfecting the wrong thing.
The most useful reframe is that the model is a design choice, not an inherited fact. Because the same value can be captured several ways, a stalled product can sometimes be revived not by building more but by changing or layering how it charges — a subscription adding usage-based pricing, a transactional product adding a membership tier. Knowing the full catalogue is what makes those moves thinkable; without it, teams keep optimising the product when the leverage was in the model all along.
An inherited model quietly dictates your metrics. Examine whether it still fits.
If you misunderstand how value is captured, you optimise the wrong thing.
Their model fits their value creation, maybe not yours. Choose for your own mechanics.
Growth often hides in a neighbouring model. Don't assume the current one is the only option.
The business model sets the frame; pricing (Tool 20) sets the numbers within it.
Whether a model works is answered by LTV:CAC (Tool 19) — the model has to produce healthy economics.
Usage-based and platform models are natural homes for the expansion mechanisms in Tool 21.
The model influences which go-to-market motion fits (Tool 22) — freemium pairs with product-led, enterprise licensing with sales-led.
Pick a product and name its primary business model from the eight. Then identify what that model makes the team optimise for (retention? volume? conversion?).
Now pick one adjacent model and ask: could layering or shifting to it capture more value, given how the product delivers value?
If you can see an adjacent model that would capture more from the product's heaviest users, you've found the kind of leverage that grows revenue without building a single new feature.