TL;DR: Packaging is the middle decision in the pricing architecture (licensing, packaging, pricing): how licensed capabilities group into what you actually sell. Editions (good/better/best) are one archetype among several, alongside modular add-ons, platform-plus-apps, all-in-one, and bundles. The right one is derived from how your Customer Groups get value, never defaulted. Packaging’s commercial job is upsell: a richer edition or another module. The value metric’s job is expansion: more of what a customer already has.
Good/better/best is one packaging archetype, not the only one. It is also the most common, and not because it keeps winning on the merits: consultancies show up force-fitting a perceived best practice, and software companies copy each other’s pricing pages. Defaulting to it is how a B2B pricing page ends up with an edition grid the sales team can’t explain without a spreadsheet. The right shape is derived from how your Customer Groups get value, and that can mean two editions, four, or a completely different pattern altogether. What matters is that every Customer Group is covered, the packaging meets their needs, and the structure stays simple enough to sell, not that you end up in a magic pattern.
Packaging is the second of the three decisions in a pricing architecture: licensing selects the value metric, packaging groups licensed capabilities into what you sell, and pricing sets what each configuration costs. It surfaces in nearly every SaaS pricing model comparison without ever getting named as its own decision.
What Packaging Actually Decides
Packaging is the decision about how all the intellectual property you sell (software features, services, and insight) groups into a given offering. It covers which capabilities live in the base offer, what sits outside as an add-on or module, and what moves upward as a customer’s needs grow.
Two companies can sell an identical product at an identical price with completely different packaging, and two companies can package identically at wildly different prices. Packaging is not a price decision. It’s a composition decision: what goes with what.
This is also where a price physically attaches. Whatever unit packaging defines (an edition, a module, a bundle) becomes the container a list price sits on; the value metric then scales that price by quantity. Clean packaging produces a pricing model a business can maintain. Sprawling packaging produces one nobody can.
The industry conflates two things here that don’t belong together: which capabilities group into which edition, and how a per-unit rate changes with volume on a single product. “Tiered pricing” gets used for both, and the confusion is not cosmetic: one is a composition decision, the other is a rate schedule.
The Job Packaging Does, and the One It Doesn’t
The single most common packaging mistake we see: conflating expansion (the licensing model’s job) with upsell (packaging’s job). It happens when a usage cap is built into an edition boundary instead of into the licensing model: two separate decisions collapsed into one, with no clean way for the buyer to accept just one of them.
The market’s own tooling vocabulary shows how far this conflation has spread. Entitlement-platform vendors routinely list credit-based, token-limit, model-access, and rate-limit structures side by side as “tiered pricing” for AI products. Three of those four are metric decisions wearing packaging’s name. Naming a usage cap a “tier” doesn’t make it a packaging decision; it makes the packaging vocabulary imprecise enough to hide the real decision underneath it.
None of this means a usage-scaled offer is wrong. It means the packaging boundary should gate capabilities: which modules, which support level, which governance controls. The licensing model, separately, should gate volume. Conflate the two and you’ve built an edition ladder that can’t tell a buyer what they’re actually paying to unlock.
The Archetypes: Editions Are One Option, Not the Default
When your Customer Groups stack, each wanting everything the group below wants and then more, an edition ladder is the right container. A data-platform vendor’s edition ladder, a base edition followed by progressively deeper governance and support wrapped around the same usage-based unit, is a textbook case of stacking editions on top of a shared metric. Stacking is one pattern among several that show up in live B2B markets, though.
Modular, à la carte, and add-ons
Capabilities are sold as separate components a customer assembles, rather than pre-bundled into a fixed ladder. This fits Customer Groups with different needs and little overlap. Force them into a shared edition and everyone buys capability they’ll never touch.
Platform plus apps
A near-universal core carries a set of group-specific extensions on top: a suite of software vendors sell one platform this way and let each Customer Group attach the applications relevant to their work. This fits when the core is genuinely shared value and the differentiation lives at the edges.
All-in-one, single offer
No editions at all: one price, everything included. This fits a single, tightly scoped Customer Group with low variance in how the product gets used. Edition machinery here would just add sales friction with no segmentation to show for it.
Bundles
Software, services, and insight packaged together (implementation, enablement, premium support, benchmarking data) rather than software alone. Packaging covers all three forms of intellectual property, not just features.
When the volume commitment gates the capabilities
One market pattern deserves naming precisely because it is not an archetype: plans where the volume commitment gates which capabilities a customer can access (more integrations, deeper governance, a higher support edition) rather than how much of one capability they can consume. That structure collapses two different commercial motions into one axis. Expansion is the value metric’s job: more units of what the customer already has. Upsell is packaging’s job: more capabilities. When volume selects the edition, the two motions merge, and the structure quietly assumes that capability need rises with volume.
It often does not. The buyer with modest volume and heavy governance needs, a mid-sized firm in a regulated industry, cannot buy under this structure: the capabilities it requires sit behind a commitment it cannot justify. Vendors then handle the mismatch with ad hoc exceptions, and the exception path becomes the real pricebook. If your plans gate capabilities on committed volume, that is not a packaging archetype at work. It is a packaging decision being made by the licensing metric, and it deserves to be made deliberately instead.
Peer-reviewed research on versioning of information goods backs the general shape of this list. Offering both a bundle and its individual components tends to outperform pure bundling or pure unbundling, because buyers value the same components differently. The same body of research names the cost side that limits how many editions makes sense. Maintaining another version carries a real cost, so an added edition only pays off when the value split across Customer Groups justifies it.
The Shape Is Derived, Never Assigned
The right archetype is derived from how your Customer Groups actually use the product, not from size-or-industry groupings. The value-in-use-by-usage-frequency framework reads that pattern capability by capability; this piece stays one level up, at what the pattern is telling you to build.
Some companies should move from good/better/best toward all-in-one as their Customer Groups converge on a single way of extracting value. Others should move the opposite direction, breaking a bloated edition apart into modules as distinct groups pull further apart. The shape isn’t fixed once; it follows wherever the groups go.
We’ve seen the failure mode often enough to name it precisely. A vendor with three editions serving five genuinely distinct buying patterns papers over the gap with custom configurations and one-off add-ons, until the exceptions outnumber the published structure. The container was built for the product roadmap, not the customer.
Design and Enforcement Are Different Jobs
Packaging has two separate jobs, and the current wave of pricing tooling only solves one of them. Design decides what shape the offer takes and where the boundaries sit. Enforcement makes the product honor those boundaries at runtime: feature gates, entitlements, access control.
Vendors in the entitlement-infrastructure category are genuinely good at the second job now: modern architecture separates the product catalog, metering, and billing layers, and re-packaging no longer requires an engineering sprint.
None of that solves the harder question. That infrastructure will enforce a brilliant packaging design and a confused one with equal fidelity. It won’t tell you whether a boundary belongs at 50 units or 200, or whether a capability drives upsell or just buyer resentment. That judgment is still yours, and no runtime layer makes it for you.
Packaging’s Place in the Architecture
Confusing licensing, packaging, and pricing is how companies end up debating “usage-based versus tiered” as if it were one choice: one names a metric, the other a packaging structure.
Packaging also isn’t a decision you make once and file away. As the product adds capability and Customer Groups shift with it, the boundaries that made sense at launch stop matching how people actually buy. Revisiting packaging on the same cadence the product ships, rather than waiting for a multi-year repricing event, is what keeps the offer legible instead of accumulating exceptions.
An edition grid that requires a spreadsheet to explain is a sign the packaging structure and your Customer Groups have come apart. Let’s map where.
Packaging is the one decision in the architecture a prospect sees before they ever talk to sales. Book a working session to see how the archetype question plays out against your own Customer Groups.
