How to package features into tiers
Guide · Pricing Intelligence · 5 min read · last verified 2026-07-27
Packaging is the decision of which capabilities belong in which pricing tier: what a buyer at each stage receives, and what has to change about their situation before the next tier becomes the right one. Done well, it is an act of description — each tier names a kind of company and equips it. Done badly, it is an act of extraction — features withheld wherever withholding seems likely to force an upgrade. The principle that separates the two: fence by buyer maturity and by value received, never by spite. Everything below unpacks what that means in practice.
A tier is a buyer, not a bucket
The most reliable packaging test is narrative. For each tier, can you describe the company it serves — their size, their stage, the problem that brought them in, the moment they'll outgrow it — in a sentence a salesperson would actually say? If a tier can only be described by listing its features, it isn't a tier; it's a bucket, and buyers tend to experience buckets as arbitrary. Packaging tends to go wrong at the very first step, when the team starts from the feature list and asks what can be withheld, instead of starting from buyer situations and asking what each situation needs. The feature list is the inventory. The tiers are the customers. Inventory-first packaging almost always produces at least one fence that exists for no articulable reason, and buyers are often unnervingly good at finding it.
Fences buyers grow into
The strongest fences are drawn along maturity: capabilities that only become relevant once the buying organization itself has grown. Multiple workspaces matter when there are multiple teams. Approval workflows matter when more than one person touches the work. Granular permissions, audit visibility, and consolidated administration matter when someone is accountable for other people's usage. These fences have a property that no other kind shares — the buyer graduates into them. The moment a customer needs the capability is the moment the upgrade is legitimate, so the upgrade conversation arrives feeling like recognition rather than ransom. The underlying concept has a name and a broader theory — what is a price fence covers it as a definition — but the packaging application reduces to one question per feature: does needing this correlate with having grown? When the answer is yes, the fence will tend to hold without resentment.
Fences that track value received
The second legitimate family draws fences along value: capabilities and capacities that scale with how much the buyer is getting out of the product. More seats, more monitored markets, more tracked questions, higher volumes of whatever the product processes — these ask more from the customers who are demonstrably receiving more, which is the fairness intuition pricing is supposed to encode. The design risk in this family is unit choice: pick a unit buyers experience as a tax on success and the fence starts fighting the customer's growth instead of riding it. The unit should rise with realized value, not with the customer's mere enthusiasm for using the thing they bought.
The spite fence
The third family is the one to refuse: withholding something every buyer needs, at every stage, purely because scarcity creates upgrade pressure. A spite fence is crossed not by growing but by suffering. The canonical example is gating single sign-on behind the top tier — why gating SSO behind enterprise tiers backfires makes the full argument, but the shape generalizes: when a capability is about safety, security, or basic dignity of use, fencing it converts the upgrade moment into a grudge. The tell is internal: if the packaging discussion contains the phrase people will have to upgrade for this, said about something with no maturity or value logic behind it, a spite fence is being built. Such fences do sometimes produce upgrades — that is what makes them tempting — but they tend to collect their real cost later, at renewal, in reviews, and in the sales conversations where a prospect asks why a basic thing costs extra and the honest answer is embarrassing.
How many tiers
Reason from mechanics rather than from convention. Each tier must describe a distinct buyer and do a distinct job; the right count is however many such descriptions genuinely exist for your market, and it is usually smaller than the number of buyer types the team can brainstorm. Too many tiers and the differences between adjacent ones stop being narratable — buyers stall in comparison, and sales starts inventing the distinctions on the fly. Too few and the distance between tiers becomes a cliff that mid-sized buyers refuse to jump. The middle position deserves particular scrutiny, because a middle tier added merely to soften the jump — rather than to describe a real company — tends to fail in a characteristic way; why the middle pricing tier usually fails examines that pattern on its own, and the packaging-level question here is simply whether your middle describes anyone you could name.
The out-loud test
The final check is spoken. Take each fence and have someone explain it to the face of the buyer it affects. You'll want the higher tier once several teams are working in here survives being said out loud; we switched that off so you'd have a reason to upgrade does not. Fences that can be spoken without flinching tend to be fences that hold through renewal, because the customer's own growth keeps re-justifying them. Fences that require euphemism will eventually be described accurately by someone else — usually in public. Magrios publishes its own tiering openly at /pricing, not as a claim of having solved packaging, but from the same reasoning: a fence you would hesitate to publish is usually the wrong kind of fence. And packaging by tiers has a frontier beyond it — the strictest form of value alignment is charging for results themselves, considered in should you tie price to outcomes; tiers are often the honest middle ground between flat simplicity and that harder bargain.