[ Archetype 01 ]
Editions
Good/better/best and its variants. The editions can be independent, ladder by maturity, or follow whatever progression is natural to the product and market. Breaks when a usage limit is doing the structuring.
Topic hub
Packaging
The offerings decision in the pricing architecture: how licensed capabilities group into editions, modules, bundles, and suites. Archetype selection, Customer Group coverage, and the upsell motion packaging owns.
[ The offerings decision ]
Same capabilities. Five ways to sell them.
Every archetype is a different grouping of the same capability set: editions that ladder or stand independent, modules around a core, apps riding a platform, one all-in-one offer, or products composed into a bundle. The shape is derived from how your Customer Groups get value; SPP’s value-in-use × usage-frequency framework does the sorting underneath.
Same squares.
Different groupings.
Different groupings.
About this hub
Packaging is the offerings decision: how everything you sell groups into what a customer can actually buy.
It sits in the middle of the pricing architecture. The licensing model decides what a unit of your product is. Packaging decides how those units group into offerings. The pricing model decides what each offering costs. Most packaging debates start with a grid of three editions and work backward; the architecture works forward.
01 / 03
Good/better/best is one archetype. It is also the most copied.
Three stacked editions is the most common packaging in B2B software, and not because it keeps winning on the merits. It spread because consultancies show up force-fitting a perceived best practice, and because software companies copy each other's pricing pages. Common is not the same as correct.
The right shape is derived from how your Customer Groups get value: two editions, four, or a completely different pattern. The test is coverage, fit, and simplicity, not landing in a familiar grid.
02 / 03
Five archetypes, one decision.
[ Archetype 02 ]
Modular add-ons
A base offer plus capabilities sold separately. Fits distinct groups with distinct needs; sprawls when every feature becomes a SKU.
[ Archetype 03 ]
Platform + apps
A core platform with applications riding on it. The composition question moves to what the core must include for the apps to make sense.
[ Archetype 04 ]
All-in-one
A single sized offer. The right answer more often than the industry admits, especially when Customer Groups converge on one way of extracting value.
[ Archetype 05 ]
Bundles
Products composed into an offer with its own identity, grouping offerings where the other archetypes group capabilities. The economics live in what the bundle makes attachable, not in the discount.
A sixth shape shows up in the wild that is not an archetype at all: the volume commitment that gates capabilities, a value metric decision wearing packaging's clothes. Untangling that conflation is half the work of a packaging redesign.
Archetypes also compose, and bundles are usually how: the first four shapes group capabilities into offerings, and a bundle groups those offerings into a composed offer. A platform's apps can be bundled, a modular core can be bundled with another product's edition. The mix is a design choice inside these five, not a sixth archetype.
03 / 03
Packaging's job is upsell. The metric's job is expansion.
The two growth motions are different machines. Packaging drives upsell: a richer edition, an added module. The value metric drives expansion: more units of what the customer already has. When packaging tries to do the metric's job, editions turn into usage tiers and both motions stall.
Start with Software Packaging: The Offerings Decision below for the definitive treatment, then the supporting articles for the specific calls: choosing an archetype, Customer Groups versus buyer personas, and the redesigns that follow. Sibling hubs cover the neighboring decisions: the full architecture in Software Monetization, model debates in SaaS Pricing, and AI-specific metric questions in AI Pricing.
[ Start here ]
1 article
[ 01 ]
Software Packaging: The Offerings Decision
Packaging groups licensed capabilities into what you sell. Editions are one archetype among several; the right one is derived from your Customer Groups.
2026-07-16
Start here
[ More on this topic ]
2 articles · most recent first
2026-06-19
Packaging Is a Customer Group Problem, Not a Persona Problem
Personas were built for messaging, not monetization. Customer Groups, clusters that extract value the same way, are the right unit for packaging.
Read →
2026-06-19
Software Packaging Framework: How to Decide Edition Boundaries
Packaging is a design decision, not just an enforcement one, and it starts with your Customer Groups. Here's the framework we presented in 2014, and the…
Read →
[ FAQ ]
4 questions
What is software packaging?
The offerings decision in a pricing architecture: how licensed capabilities group into what you actually sell, whether that is editions, modules, bundles, or a single all-in-one offer.
Is good/better/best the right packaging for most software companies?
It is the most common and the most copied, not automatically the most correct. The right shape is derived from how your Customer Groups get value; that can mean two editions, four, or a different pattern entirely.
When should a company change its packaging?
The customer mix is always changing; packaging goes wrong when those changes accumulate and diverge from its current expression. That accumulation is the problem with pricing as an event: distinct groups pulling apart favor modules, converging groups favor consolidation, and the shape follows the groups, not the calendar.
Does packaging set the price?
No. Packaging defines the unit a price attaches to; the pricing model and value metric then determine what that unit costs and how it scales.
Package around your Customer Groups, not a template.
If your edition grid needs a spreadsheet to explain, the packaging is doing the wrong job. Derive the structure your Customer Groups actually buy, and keep it simple enough for a sales team to defend.
Book a working session →