TL;DR: Personas were designed for messaging, not for mapping how value gets extracted. Build packaging around them and you get edition sprawl and a sales team quoting around the whole structure. The correct unit for packaging is the Customer Group: a cluster of customers who derive value from your product the same way, regardless of size or vertical. That shared value profile is what determines which capabilities belong together. Get customer groups vs buyer personas right and the edition structure consolidates naturally; then the value metric and price points have something coherent to work against.
Picture a packaging mess you have inherited: an edition grid that sprawls across six columns, most features metered into their own line, a sales team quietly quoting around the whole structure. The cause is almost always the same: the team built it for personas. This piece is about why that distinction decides whether your packaging holds together, and where the framework behind it comes from. For the framework itself, the value-in-use / usage-frequency grid that sorts capabilities into editions, see the software packaging framework; here I want to stay on the unit you run it for.
Customer Groups vs Buyer Personas: The Distinction That Decides Packaging
A Customer Group is a cluster of customers who derive value from your product the same way, regardless of size, industry, or org chart, and who should therefore be packaged and priced as one. That is the unit packaging runs on. A persona is not.
What a Customer Group is, and what a persona is not
Customer Groups are not the size/vertical splits most companies start with, the small/medium/large or by-industry slices that look tidy on a slide but say nothing about how anyone actually uses the product. Two customers in different verticals, at different sizes, can pull value from your software identically, and that shared value profile, not the org chart, is what should drive packaging. Group by value similarity and the right editions almost name themselves. Group by anything else and you end up fighting your own structure.
Peer-reviewed research on versioning of information goods reaches the same conclusion: edition structure should reflect how different customers extract value, not who they are.
Personas were popularized for this work, and in our experience that is a category error. A persona is built for sales and content, and it lives in the minutiae. Betty in purchasing reads different content than Frank on the warehouse floor, and a good sales team speaks to each in their own language. That is what personas are for. Monetization works at the opposite altitude: it asks how the Bettys and Franks together pull value from the software as a whole, the one question personas were never built to answer.
The mismatch shows up in workshops. Teams arrive with a dozen buyer types sorted into quadrants and a packaging structure that mirrors all twelve. The packaging question was never which buyer. It was which value pattern. This is the same error behind content frameworks applied to pricing: a tool built for messaging gets pointed at a monetization decision it was never designed to make.
| Buyer persona | Customer Group | |
|---|---|---|
| Designed for | Sales and content | Packaging and pricing |
| Unit of analysis | The individual buyer | The value-similarity cluster |
| What it captures | How to speak to and sell to a buyer | How a group extracts value from the product |
| Effect on packaging | Inflates editions, one per buyer type | Consolidates editions to distinct value patterns |
| Scales by | Every new buyer you discover | The handful of ways value actually gets extracted |
When to use each
Use buyer personas when the job is messaging, content, and the sales conversation: speaking to Betty and Frank in language that lands for each. Use Customer Groups when the job is packaging, the value metric, and price: deciding which capabilities belong in which edition and what each is worth. The first sorts by who is in the room. The second sorts by how value gets extracted once the contract is signed.
The mistake leaves a signature
Overly complicated packaging, the kind where the edition grid sprawls and most features are metered into their own line, almost always traces to a team that started from personas. The logic is seductive: if Betty cares about this and Frank cares about that, surely the package should reflect both, and the one after them, and the one after that.
In our packaging engagements the pattern is consistent. Personas multiply with every new buyer discovered. Customer Groups collapse to the handful of distinct ways value actually gets extracted. That sprawl is one of the clearest signs your pricing strategy is not working.
When a company hands us a packaging structure they cannot explain to their own sales team, the fix never starts with the features. It starts by asking how many genuinely different ways their customers use the product, almost always fewer than the number of editions on the page. That gap is the mess.
Why the popular alternatives also miss
The persona literature does have a way to get from one buyer to the whole account, but watch where it leads. When it aggregates personas, it aggregates them into a buying committee, and that committee’s job is consensus: getting six or ten stakeholders to a shared yes. Your packaging does have to clear that committee, and getting the yes is a real gate. But clearing it is necessary, not sufficient. Consensus says nothing about whether the structure captures appropriate value once the contract is signed. The critical question is not whether packaging gets by the buyer, but whether it gets by and captures the value it should. That second half turns on how the customer extracts value, which the Customer Group captures and the committee does not.
Jobs-to-be-Done gets closer to value, but it does so by dropping the persona entirely, organizing around the job and its outcome rather than who is in the room. That is a more useful altitude, and still not the unit for packaging. A single Customer Group can have several jobs, and a single job can span several groups. The job describes what the customer is trying to accomplish; the Customer Group describes who extracts value the same way. You package for the second.
So the popular frameworks either stop at the purchase decision or abandon the persona to reach value. Packaging needs neither. Packaging expresses what you offer each Customer Group; value extraction comes from the whole pricing architecture, the value metric and the price points working together with the packaging, not any one of them alone.
Get the relationship between the pricing model and the value metric wrong, or design the shape around the committee or the persona, and the other pieces have nothing coherent to work against. The same trap recurs across SaaS pricing models: a structure chosen for the buyer, not the value pattern.
When You Aggregate Personas, What Exactly Are You Packaging For?
Persona aggregation collapses distinct customer groups into a single muddled target — and your free-to-paid boundary pays the price. The How to Price Software eBook shows how licensing, packaging, and pricing work together to draw that boundary around real customer groups.
Quantifying a persona does not rescue it
Some try to save the persona for monetization by quantifying it, pinning a willingness-to-pay number and a feature-preference score to each buyer type. It is a real attempt, and it still misses, for two reasons.
Quantifying a persona does not change what it is. A numbered individual is still an individual, not the pattern by which a group extracts value. Precision applied to the wrong unit gives you a confident answer to the wrong question.
The figures usually come from willingness-to-pay surveys. In B2B software, those capture stated intent in a low-stakes hypothetical, not behavior under a real contract. Three decades of pricing research methodology point the same way. Stated-preference measures systematically diverge from revealed preference under real purchase conditions. That is exactly why methods built to mimic the actual choice were adopted over methods that rate a buyer in isolation.
The Customer Group sidesteps both problems. It is not a person, so there is no individual to mistake for a pattern, and it is defined by how value gets used rather than by what a respondent claims in a survey. That is why it holds up under a real contract where personas do not.
Where the value-in-use / usage-frequency grid comes from
The value-in-use / usage-frequency grid, capabilities plotted on value against breadth of usage, has circulated under several names. Value versus usage. Perceived value versus expected adoption. The labels vary; the two axes, and the packaging decisions they drive, do not. The name you learned the grid under may have quietly changed its meaning.
The original axes: value in use and usage frequency
I first presented this grid publicly at a Business of Software workshop in Boston in 2014. We had been running it in client workshops since 2011, synthesized from years of our own pricing and packaging work, so it is SPP’s own synthesis. Precursor concepts, how customers use a product, what drives their value, which features matter most, go back earlier in our materials. The full two-axis grid with its named quadrants is the 2011 synthesis, not something older dressed up. On our 2014 slide the axes read value in use and usage frequency.
How the usage axis was misread
If you have seen the same grid with its axes named perceived value and expected adoption, those are later labels for exactly these two axes. “Adoption” is a faithful relabel, because it asks precisely what we asked: how much of the customer base actually takes a feature up. The relabel kept the meaning. What did not survive the copy was the reading of it.
As the grid spread, “usage frequency” slid into daily-active counts and sessions-per-week, the engagement dashboards product teams already had. That reading is wrong. The axis was always about breadth, what share of a group reaches for a capability at all, not intensity, how hard the few who use it lean on it. A feature can be used heavily by a handful of power users and still belong in the base, because most of the group never touches it. Lose that distinction and the grid quietly stops sorting editions correctly.
Packaging is the start, not the whole answer
Getting the unit right fixes packaging. It does not, by itself, finish monetization. Packaging expresses the offer to each Customer Group. The revenue comes from the pricing architecture around it. Three pieces carry that: the value metric that meters what customers receive, the price points that capture a fair share, and the discipline of revisiting all three as the product moves.
We treat the model as a starting read of how each group values your capabilities. Then we validate it against real customers over time, so the model and the market converge rather than drift, the discipline of continuous monetization. Personas cannot anchor any of that work. Customer Groups can. They are defined by the one thing all of it depends on: how value gets created in use, and how the business captures a return on it.
If your packaging has quietly sprawled and the sales team is quoting around it, the fix starts one level up, at the Customer Groups, before you touch the feature grid. See how we work or book a working session to start there. Once the groups are right, the value-in-use / usage-frequency grid sorts capabilities into editions from a structure that finally holds together.
