Software Packaging Framework: How to Decide Edition Boundaries

TL;DR: The hard part of software packaging is not enforcing edition boundaries, tooling does that now, but deciding where they belong. That decision starts with your Customer Groups, the clusters who derive value the same way, not with your feature list. Plot each group’s capabilities on value in use against usage frequency, and the editions, add-ons, and what to stop charging for fall out of the pattern; the shape of the offer, editions, modules, or a platform, follows the groups.

Software packaging is a design decision before it is an enforcement one, and a software packaging framework has to get the design right. The hard question is not how to switch a feature on for paying customers; tooling solves that now. The hard question is what shape the offer should take and where the boundaries belong in the first place: whether you sell editions, modules, or a platform, which capabilities anchor the premium edition, which belong in the base, and which you should stop charging for at all. Get that wrong and no amount of enforcement infrastructure saves you.

I first presented this software packaging framework publicly at a Business of Software workshop in Boston in 2014, though we had been running it in client workshops since 2011, built from two strands of our own pricing work: how customers use software, and how they value it. It is SPP’s own synthesis, refined over years of engagements. The current wave of pricing and entitlement tooling has rediscovered that packaging must change over time, then built software for the easy half, enforcing the boundaries you set, and left the hard half, deciding well, exactly where it was. And there is a step that comes before any of it: you have to know which customers you are packaging for before you touch a single feature.

The first boundaries are between customers, not features

A packaging plot is only meaningful for one kind of customer at a time. Customer Groups are clusters of customers who derive value from your product in the same way, regardless of size or industry. They are not the segments most companies start with, the small/medium/large or by-vertical splits that look tidy on a slide but say nothing about how anyone actually uses the product. And they are not buying personas, which were popularized for this work and turn out to be the wrong unit for it. (That mistake is common enough, and consequential enough, that it gets its own treatment.)

Packaging is downstream of those groups. How many editions you need, whether editions are even the right container, which capabilities cluster together: all of it follows from how many distinct ways your customers buy and use, not from how your product team organizes its roadmap. Most packaging problems we are called in to fix are Customer Group problems in disguise: three editions serving five kinds of buyer, with the sales team papering over the gap through custom configurations and one-off discounts until the exceptions become the real pricebook.

The failure mode is specific, and it is why the customers come first. Blend two groups into a single plot and you get the average of two value profiles, which describes neither of them. We once watched a client build their packages around the average customer, the one who buys two of this and ten of that. No one bought the average. It fit no one, and every real customer ended up paying for something they did not want or missing something they did.

Drawing those group boundaries is its own piece of careful work, and it comes before any of the feature work. The 2×2 I showed in Boston in 2014 sorted features for one coherent group at a time, and that part has not changed. What evolved was everything around it: running the plot for every distinct group, then re-running it as products and customer mixes shifted, turned into a sprawl of spreadsheets. Formalizing the group boundaries as the explicit first move, then building LevelSetter to carry the per-group analysis, is how we kept it from buckling under its own bookkeeping. Define the groups first, then run the plot once for each. Everything below assumes you have done that.

The software packaging framework: value in use × usage frequency

The two axes

Within a single Customer Group, the SPP Packaging Decision Framework maps every candidate capability on two axes:

• Value in use: how much the customer’s outcome depends on the feature when they use it.
• Usage frequency: what share of that group actually uses it.

A capability is anything a customer could pay for, delivered as product or as a service: a software feature, but also an onboarding program, premium support, or an advisory engagement. The grid plots all of them the same way.

One word in that second axis has caused more confusion than anything else. Frequency asks how many of your customers reach for the feature at all. It was never a per-user engagement metric. As the 2×2 was copied around the industry, that is the distinction people dropped: “usage frequency” slid into daily-active counts and sessions-per-week, the dashboard numbers product teams already had. But a feature can be used constantly by the handful of power users who depend on it and still sit untouched by most of your base. What moves an edition boundary is how many customers reach for a capability and which ones, not how hard the few who do lean on it.

The point of the two axes is that they pull apart two things companies routinely conflate. A feature can be valuable but narrowly used: a power capability only a slice of customers reach for, though the ones who do can’t live without it. Or it can be widely used but low value: table stakes a large share relies on and nobody will pay extra for. Those two belong in completely different editions, and a single “importance” score would have buried the distinction.

Reading the four quadrants

Plotting your capabilities this way does the work:

• High value, high usage: your Tier Candidates. These anchor your premium edition. They are the reason a customer trades up, because a wide share of your base both reaches for them and depends on them heavily.
• High value, low usage: your Add-On Candidates. Strong differentiators for higher editions or paid options. Only part of your base reaches for them, but the customers who do can’t do without them, which makes them excellent fences between editions.
• Low value, high usage: your Basic Features. Table stakes. They belong in the base edition; charging for them creates friction without capturing value.
• Low value, low usage: Not Worth Doing. Candidates to cut, bundle invisibly, or stop maintaining. They rarely justify their place on a feature list.

The boundaries fall out of the pattern, not out of any single capability. But the pattern informs the call; it does not make it. The framework tells you where each capability belongs and why; it does not hand down the shape to express that in, which is the practitioner’s read, not the grid’s. Experience, and the limits of what your product and services can deliver, tell you how far to simplify. You build a software capability once and expose it through visibility controls; a services capability you include or leave out.

This is not only practitioner intuition. Peer-reviewed research on versioning information goods arrives at the same place: separate editions pay off precisely when a capability delivers disproportionate value to one class of customers and little to another. That is the high-value, narrow-adoption corner of the grid.

The framework in motion: a worked example

Say you are packaging a B2B SaaS product with a dozen capabilities on the table, from the dashboard everyone opens on login to an API only a handful of integration-minded customers will ever wire up. Plot each one for the Customer Group that actually reaches for it, not the buyer persona who signs the contract. The two are rarely the same, and pricing to the persona is how products end up charging for the wrong things.

The clusters name themselves. The login dashboard, standard reports, and saved views land high-usage but low-value, your Basic Features. What a broad share depends on becomes your Tier Candidates; the power features a slice cannot work without become Add-On Candidates; whatever lands low-value, low-usage is Not Worth Doing.

The boundaries are now obvious, and they came from the pattern rather than anyone’s opinion about which feature “feels premium.”

The plot is a snapshot of your assumptions, not a verdict. Every dot is a judgment, and the grid earns its keep by making those judgments explicit enough to test, not by settling them. Replot it and the dots move, faster now that AI keeps resetting what customers value: a premium capability competitors now give away drifts toward Basic; a trade-up driver you bet on shows weaker adoption and slips toward Add-On; a once-useful feature loses its usage and lands in Not Worth Doing. Each move is a packaging decision the framework surfaces before a churned customer or a stalled deal surfaces it for you.

The shape follows the groups, not a template

Notice what the plot has not done: it has not told you to build three editions. It has sorted capabilities for one group. The structure of your offer, the containers your customers actually buy, comes from laying the per-group results side by side and reading how the groups relate.

Sometimes the groups stack, each one wanting everything the group below it wants and then more, and an edition ladder fits, whether it runs to good/better/best or stops at good/better. Sometimes they want genuinely different things with little overlap, and a modular structure serves them where forced editions would make everyone buy bundles half full of capabilities they will never use. Sometimes a near-universal core carries a set of group-specific extensions, and a platform shape fits best. And there are structures still taking form as usage and AI change how value gets delivered, which is why the real menu is editions, modules, platforms, and others, not a fixed three.

You do not pick the shape off a template and then force your customers into it. The shape is dictated by the groups, and reading it correctly is the judgment the framework exists to inform. The right number of editions is however many distinct decisions your Customer Groups actually make, not the industry’s default of three.

Why this is a design problem, not an enforcement one

Here’s the distinction the current tooling wave blurs. There are two different jobs in packaging:

1. Design: deciding what shape the offer takes and where the boundaries go, by group, by value, and by usage.
2. Enforcement: making the product honor those boundaries at runtime, via feature-gating, entitlements, access control.

A venture-funded category now exists to do the second job well, and it does. Entitlement systems let you re-package without re-engineering, which is genuinely useful. But that infrastructure is agnostic about what the editions should be, and about whether editions are the right shape at all. It will enforce a brilliant packaging design and a terrible one with equal fidelity. The strategic lever, the part that decides whether trading up feels obvious or arbitrary to a customer, is the design, and the design is exactly what the tooling leaves to you.

This is why the rediscovery is only half a rediscovery. The market has correctly concluded that packaging can’t be static: you have to move boundaries as the product and the customer base evolve. That is the right instinct, and one we were arguing in 2014: packaging is something you maintain, not set once. But “we can re-package easily now” is not “we know where the boundaries should go.” The first is solved. The second still takes judgment, and a framework, and it starts with the customers, not the catalog.

Using it well: a few rules learned the hard way

• Separate the customers before you separate the features. A capability that anchors the premium edition for one Customer Group is table stakes for another. The plot is only meaningful one group at a time.
• Don’t let customer-mix penetration masquerade as value. The feature used by 80% of your base isn’t a premium opportunity, it’s a table-stakes signal. In our experience, near-universal adoption tends to mean near-universal expectation, and charging extra for it breeds resentment more often than revenue. Premium packaging belongs where adoption is meaningful but selective.
• Build once, expose selectively. Build a capability a single time, then turn it on or off by edition. Maintaining a different build per edition is how packaging becomes a maintenance sinkhole.
• Re-run it on your product’s cadence. Run the plot as often as you ship, not once at launch. The model begins as your team’s read of how customers value things; validating it against real customers over time closes the gap until the two views converge, the discipline of continuous monetization. Stop, and the mix and its perception of value drift apart without your noticing, and sales is the first to feel it across the table.

Packaging design is where most of the monetization upside, and most of the self-inflicted friction, actually lives. If you’re redrawing your packaging for an AI-era product and want the shape and the boundaries to feel obvious to customers rather than arbitrary, that’s the conversation we have every day. See how we work or book a working session.

FAQs