A team spends a year building a product, then books a one-hour meeting the week before launch to "set the price." That meeting is where most of the margin quietly disappears. Monetisation isn't a number you stamp on at the end. It's a set of decisions about value that should have shaped the product all along.

The quick version

  • Monetisation is what you charge for and how the money flows; packaging is how you split your value into a few buyable options. They're different jobs, do both on purpose.
  • Find out what customers will actually pay before you finish building. Designing the product around the price beats pricing whatever you happened to build.
  • Most buyers don't want one option or ten, they want a clear good / better / best choice, with the middle tier carrying most of the revenue.
  • Packaging shapes choices. How you order, bundle and contrast tiers changes what people buy, often more than the headline price does.

The idea in depth

Start with the two words, because they get blurred together and the blur is expensive. Monetisation answers "how does this create money?", what you meter, who pays, and whether you charge a subscription, a per-transaction fee, a licence, or take a cut of a marketplace. Packaging answers "how do I present that as a small set of things a customer can choose between?", the tiers, the bundles, what's included where, and where the lines between them fall. A business can have a sound monetisation model and still bleed value through clumsy packaging, and the reverse happens just as often.

Design the product around the price, not the other way around

The sharpest correction to the build-then-price habit comes from Madhavan Ramanujam and Georg Tacke's Monetizing Innovation (Wiley, 2016). Drawing on Simon-Kucher's pricing work across thousands of projects, they argue that you should have the "willingness-to-pay" conversation with customers early, while features are still negotiable, so you build what people will pay for instead of pricing whatever you shipped. They catalogue predictable failure modes, including the "feature shock" of cramming in everything and the "minivation" of underpricing a genuinely valuable thing.

In practice: before the roadmap is locked, ask a handful of real prospects what they'd pay, which features they'd pay more for, and which they wouldn't miss. You're not running a survey for its own sake, you're using price as a design tool to sort must-haves from nice-to-haves.

Two cautions. Stated willingness-to-pay is not the same as money leaving a wallet; people over-claim in interviews and under-pay at checkout. So treat early answers as a strong signal for prioritisation, not a forecast, and confirm with a real pricing test once you can.

Measuring willingness-to-pay without guessing

"Ask what they'll pay" sounds glib until you've watched a customer freeze at the question. One durable technique here is the Price Sensitivity Meter, introduced by the Dutch economist Peter van Westendorp at the 1976 ESOMAR Congress. Rather than demand a single number, it asks four gentler questions, at what price the product feels too cheap (you'd doubt the quality), a bargain, getting expensive, and too expensive to consider, and reads an acceptable price range from where those answers cross. It's nearly fifty years old and still in routine use, which is itself a kind of endorsement.

The practical use: when you genuinely don't know the right number, run the four van Westendorp questions across a sample of your target segment to bracket a sane range, then test specific points inside it.

Mind the ceiling on what it gives you. The method finds a band of acceptable prices, not the optimal one, and it leans on what people are willing to say in a survey. It's a starting frame, not a verdict, pair it with real-world tests and an understanding of your unit economics so the price you land on actually covers what each customer costs to serve.

flowchart LR
  A(["Customer value
(jobs, outcomes)"]) --> B(["Willingness to pay
by segment"])
  B --> C(["Monetisation model
(what + how you charge)"])
  C --> D(["Packaging
(tiers, bundles, fences)"])
  D --> E(["Price points
per tier"])
  E --> F(["Test & iterate"])
  F -.->|learn| B
Value first, price as a design input, packaging last, and a loop back to learn. Leaders Loop

Packaging: good, better, best

Once you know roughly what people value and pay, you have to split it into options. The reliable default is the three-tier good-better-best structure that Rafi Mohammed laid out in Harvard Business Review (September–October 2018). The "good" tier is a stripped-down version that pulls in price-sensitive buyers without discounting your main product; "better" keeps your current customers happy; "best" gives high-end buyers a reason to spend more. Mohammed's working guidance: don't price "good" more than about 25% below "better," and don't push "best" more than about 50% above it, so the ladder reads as one coherent climb rather than three unrelated products.

Where to start: if you currently sell one undifferentiated thing, design a deliberately lighter version and a deliberately richer one around it. The act of creating the tiers is what lets you capture both the budget buyer and the buyer who'd have happily paid more.

Three tiers is a strong default, not a law. Mohammed himself warns against over-segmenting into a confusing menu, and good-better-best fits some businesses, clear feature differences, varied customers, far better than others. The tiers also need fences: defensible reasons a feature sits where it does. Without them, customers feel manipulated rather than served.

A worked example

Take a small SaaS tool that helps cafés and shops manage rosters. Today it's one plan at $40 per location per month. Growth has stalled: tiny single-site owners find it pricey, while a few small chains keep asking for reporting the team won't build for one flat fee. (All figures below are illustrative.)

Rather than guess, the team runs the four van Westendorp questions with thirty prospects and sits in on five "what would you pay more for?" calls. Two things surface. Solo owners would happily pay something small for the basics; multi-site owners care intensely about cross-location reporting and would pay a clear premium for it. That gap in willingness-to-pay is exactly the seam a package should follow.

So they repackage into three tiers. Starter at $19 (single location, core rostering) opens the door to the price-sensitive solo owner who was walking away. Standard at $45 (the old product, plus shift-swapping) becomes the expected default. Pro at $79 (multi-location reporting, payroll export) finally gives the chains a reason to spend more. The spread roughly follows Mohammed's shape, with two deliberate stretches: "good" sits about 58% below "better," deeper than his 25% guideline, to win the long tail, while "best" lands about 75% above, again past the rule of thumb, justified by reporting that genuinely costs more to build and serve. The team then runs Standard as the visually highlighted "most popular" option, expecting, per the good-better-best pattern, the middle tier to carry the bulk of revenue while Starter widens the funnel and Pro lifts the ceiling. None of this required a better product on day one. It required charging for the value that was already there.

flowchart TB
  S(["Starter, $19
core rostering"])
  M(["Standard, $45
most popular"])
  P(["Pro, $79
multi-site reporting"])
  S -->|widens the funnel| M
  M -->|raises the ceiling| P
A good-better-best ladder: the middle tier anchors, the outer tiers reach new buyers. Illustrative figures. Leaders Loop

Frequently asked questions

What's the difference between monetisation and pricing?

Monetisation is the wider question of how a business converts value into money, what you charge for, who pays, and the model (subscription, transactional, marketplace, licence). Pricing is the narrower decision of the actual numbers. You can copy a competitor's prices and still have the wrong monetisation model if you're charging for the wrong thing.

How many tiers should I have?

Three is the common, defensible default, good-better-best, because it covers budget, mainstream and premium buyers without overwhelming anyone. More tiers can work when customer needs genuinely differ, but every extra option adds choice friction. If a tier doesn't map to a real difference in what customers value, it's clutter, not strategy.

Should the cheapest option be the most prominent?

Usually not. Most good-better-best ladders are built so the middle tier carries the most revenue, and it's common to highlight it as the "most popular" or recommended choice. The cheapest tier exists to bring price-sensitive buyers in the door, not to be the answer you steer everyone toward.

Isn't this just manipulation?

It can tip into that, which is why fences matter. If a premium feature costs you more to deliver and a tier genuinely serves a distinct customer, the structure is honest help with a decision. If the only purpose of an option is to trick someone, you'll erode trust, and trust is the most expensive thing to rebuild. Design tiers you'd be comfortable explaining out loud.

When should I revisit my packaging?

When the data tells you to: almost everyone clusters in one tier, your "best" plan never sells, or sales keep discounting to close. Those are signs the lines fell in the wrong place. Packaging isn't a one-time decision, revisit it as your customers, costs and product change.

Related in the Toolkit

Where to go next