Pricing Tier Architect

Packaging, Tiers, and Bundles

by wondelai · MIT license · ★ 2,235 on GitHub · updated Sep 10

- Leaders, Fillers, Killers

# Packaging, Tiers, and Bundles

## Table of Contents

- [Leaders, Fillers, Killers](#leaders-fillers-killers)
- [The Classification Procedure](#the-classification-procedure)
- [Good-Better-Best Design Rules](#good-better-best-design-rules)
- [Naming Tiers](#naming-tiers)
- [The Feature-Allocation Matrix](#the-feature-allocation-matrix)
- [Designing Upgrade Paths](#designing-upgrade-paths)
- [Bundle or Unbundle: A Checklist](#bundle-or-unbundle-a-checklist)
- [Pricing-Page Implications](#pricing-page-implications)

## Leaders, Fillers, Killers

Packaging starts from one observation: features are not equal in the buyer's mind, and treating them equally destroys value. Every feature falls into one of three classes — *for a given segment*:

- **Leaders** drive the purchase decision. The buyer would walk without them; they would pay meaningfully more to get them. A package exists to deliver its leaders.

Overview

Packaging starts from one observation: features are not equal in the buyer's mind, and treating them equally destroys value. Every feature falls into one of three classes — for a given segment:

Manual install (npx, ZIP)

Claude Codenpx skills add wondelai/skills --skill packaging-tiers-and-bundles -g -a claude-code

Claude.ai / desktopZip the folder and upload it under Settings → Capabilities → Skills.

Codex, Cursor, other agentsPoint them at SKILL.md. The other files are plain text.

Connects with Agent Alley MCP · agentalley.io/mcp

Files included

packaging-tiers.md11.4 KB

Read packaging-tiers.md here

wondelai/main1 file

packaging-tiers.md11.4 KB

packaging-tiers.md

Show the full text128 lines

packaging-tiers-and-bundles/packaging-tiers.md128 lines · 11.4 KB

PreviewCode

Outline

RawView on GitHub

Leaders, Fillers, Killers

Packaging starts from one observation: features are not equal in the buyer's mind, and treating them equally destroys value. Every feature falls into one of three classes — for a given segment:

Leaders drive the purchase decision. The buyer would walk without them; they would pay meaningfully more to get them. A package exists to deliver its leaders.
Fillers add modest value. Nice to have, tip the scales in a tie, harmless to include — but nobody buys for them and nobody pays extra for them. Fillers round out a package and differentiate tiers cheaply.
Killers reduce willingness to pay when forced into the package. The buyer does not want them and resents funding them. Classic killers: paid-for capabilities a segment will never use ("why am I paying for call-center features?"), mandatory services (required onboarding fees), or features that add complexity the segment fears.

The segment qualifier is everything. On-premise deployment is a killer for a startup buyer (cost, maintenance, fear) and a leader for a bank (compliance). SSO is invisible to freelancers and non-negotiable for enterprises. There is no absolute list — only a per-segment classification, which is why segmentation precedes packaging.

The Classification Procedure

Run this before designing tiers, and again whenever a significant feature ships:

List the units of value. Enumerate every feature or capability a buyer could perceive as a thing they get — typically 15-30 items. Group sub-features (ten small report types = "reporting"). If the list exceeds ~30, you are itemizing too finely.
Collect evidence per item, per segment. From WTP interviews and surveys:
- Decision impact: "Which of these would have to be present for you to buy?" / "Rank the top 5 that drive your decision."
- Incremental WTP: "How much more would you pay for a version with X?" or point-allocation across the list.
- Negative reaction: "Which of these would you not want to pay for, even bundled?" / "Would including X at a higher price make you walk away?"
Score and classify. A practical rubric per segment:

Evidence pattern	Class
Top-5 decision ranking for ≥40% of segment, positive incremental WTP	Leader
Rarely ranked, near-zero incremental WTP, no negative reaction	Filler
≥20% of segment reacts negatively to paying for it	Killer

Sanity-check against behavior. Usage data, lost-deal notes, and support requests should corroborate. A "leader" nobody uses after purchase is a marketing leader only — fine, but know it. A "filler" that churned customers cite as missing was a leader you misread.
Decide the fate of each killer. Three options: unbundle into an optional add-on (the default), move it to a tier whose segment values it (where it may be a leader), or cut it entirely if it is a killer for everyone.

Good-Better-Best Design Rules

Three tiers is the default architecture because it exploits how people choose: extremes feel risky, the middle feels safe, and a premium anchor makes everything below it look reasonable.

Design "Better" first. The middle tier is the offer most buyers should take — the compromise effect will pull them there anyway, so build it to be genuinely right for your core segment and price it where you want your average revenue to land.
"Best" is the anchor and the enterprise home. It must contain real leaders for the high-WTP segment (not just bigger limits), priced 2-4x "Better." Even at modest volume it pays twice: directly, and by making "Better" an easy yes.
"Good" is the fenced entry. It exists to capture the low-WTP segment and to start upgrade journeys. Give it real value — a taste of the leader, not the meal. If "Good" fully contains the leader, nobody upgrades; if it is useless, it poisons trust and trials.
Plan around a 70/20/10 shape. As a planning expectation, aim for roughly 70% of buyers in Better, 20% in Best, 10% in Good. Strong deviations are diagnostic: most buyers in Good means weak fences or an overpriced middle; most in Best means your anchor is missing and you are likely minivating.
Fence with leaders, then limits. The primary fence between tiers should be a feature the higher segment genuinely values (leader fence). Quantity limits (seats, projects, API calls) are secondary fences — good for growth-based upgrades, weak as the only differentiator.
Four tiers maximum. A fourth tier (usually a free or a custom-enterprise tier) is acceptable; five or more measurably increases choice paralysis and support burden. Collapse before you add.
Price gaps must be explainable in one sentence per gap. "Team adds the integrations and approvals agencies need" — if you cannot say it, the buyer cannot see it, and the gap reads as arbitrary.

Naming Tiers

Tier names are a self-segmentation device: a buyer should know which tier is theirs within five seconds.

Name by customer or use stage: Solo / Team / Business / Enterprise, or Starter / Growth / Scale. These work because buyers identify themselves before reading the feature table.
Avoid opaque sequences (Bronze/Silver/Gold, Basic/Plus/Premium) when segments differ by kind of need — metals only communicate "more," not "for whom."
Never name a tier something aspirational that insults the others. "Professional" above "Basic" implies Basic buyers are amateurs; they notice.
Keep names stable. Renaming tiers invalidates documentation, reviews, and word-of-mouth ("get the Team plan") — rename only with a repackaging worth that cost.

The Feature-Allocation Matrix

The working artifact of packaging design — every feature, its classification per target segment, and its tier placement:

Feature	Class (segment)	Good ($19)	Better ($49)	Best ($129)	Add-on
Core editor	Leader (all)	✓	✓	✓	—
Projects	Fence (limit)	3	25	Unlimited	—
Slack/Teams integration	Leader (Team seg)	—	✓	✓	—
Approval workflows	Leader (Team seg)	—	✓	✓	—
Advanced analytics	Leader (Agency seg)	—	—	✓	—
API access	Leader (Agency seg)	—	Read-only	✓	—
Custom branding	Filler	—	✓	✓	—
Email support	Filler	✓	✓	✓	—
Dedicated CSM	Leader (Enterprise)	—	—	✓	—
On-prem deployment	Killer (SMB) / Leader (Ent)	—	—	—	$
Mandatory onboarding	Killer (all)	—	—	—	Optional $

Rules visible in the template: each tier above Good adds at least one leader for its segment; killers never sit inside a tier price; limits create a second, growth-driven upgrade trigger; every row has an explicit decision (no "TBD" rows on a shipping pricing page).

Designing Upgrade Paths

Packaging is static; customers are not. Design the journey between tiers:

Place the fence where usage naturally grows. The best upgrade trigger is success: the team that hits the 3-project limit because the product worked. Analyze usage distributions and put limits just below the point where committed users land (if engaged teams typically reach 4-6 projects, the free/entry cap is 3).
Prompt at the moment of need, not on a schedule. "You've hit your project limit — Team gives you 25" converts; a monthly upsell email annoys. Every fence needs an in-product moment that explains the next tier in terms of what the user was just trying to do.
Let users preview the leader. Time-boxed trials of higher-tier features (7 days of analytics when first opened) outperform descriptions. A leader experienced is a leader bought.
Never make downgrades destructive. Losing access to premium features is acceptable; losing data or exports is hostage-taking — it poisons reviews and, in some jurisdictions, regulators agree.
Mind the cliff between self-serve and enterprise. If Best is $129/seat and Enterprise is "call us" starting at 10x, mid-market buyers fall into the gap. Bridge with a transparent volume schedule or a mid tier.

Bundle or Unbundle: A Checklist

Bundling raises total willingness to pay when the parts reinforce each other; it destroys clarity when they do not. Work through the list:

Bundle when most of these are true:

Components are complementary in use — each makes the others more valuable (editor + review + publishing)
One buyer evaluates and pays for all components
Buyers' WTP for components is negatively correlated (some value A highly and B mildly, others the reverse) — the bundle averages both into one strong yes
Buying separately would create integration or decision friction you can remove
The bundle story is tellable in one sentence ("everything a podcast team needs")

Unbundle when any of these is true:

A component is a killer for a meaningful segment of bundle buyers
Different components are bought by different roles or budgets
A component's natural price metric differs (per-seat product bundled with a per-volume API)
The bundle price exceeds the prohibitive threshold of your core segment even though individual WTPs are healthy
Competitors win by selling the one component a customer wants without the rest

Default resolution for borderline cases: tiered bundles (the core bundle plus add-ons) — keep the complementary heart together and let contested components be chosen.

Pricing-Page Implications

The pricing page is where packaging theory meets a visitor with 20 seconds of patience:

Three or four columns, one highlighted. Highlight "Better" with a "Most popular" badge — only if it is actually true; invented popularity claims are both unethical and, in several markets, illegal.
Use the anchor deliberately. Either order tiers premium-first (strong anchor for sales-led products) or highlight the middle with the premium adjacent (standard for self-serve). Never hide the premium tier — it is doing anchoring work even when unsold.
Lead each column with its leader. The first 2-3 bullets under each tier name must be that tier's leaders for its segment — not the longest list. Bury fillers in the expandable comparison table below.
State the price metric next to the price. "$49 per editor / month, billed annually" — ambiguity about the metric ("per user? per viewer?") kills conversion and seeds support debt.
Make the annual/monthly toggle honest. Show the math; don't display annual-billed prices as if monthly without labeling.
Answer fence questions in an FAQ. "What happens when I hit the project limit?", "Can I downgrade?", "Do viewers cost money?" — every fence creates a question; unanswered questions create abandoned carts.
Test packaging before price. A/B tests that move features between tiers or change the highlighted column routinely shift revenue more than ±10% price tests — and are safer to run.

1	# Packaging, Tiers, and Bundles
2
3	## Table of Contents
4
5	- [Leaders, Fillers, Killers](#leaders-fillers-killers)
6	- [The Classification Procedure](#the-classification-procedure)
7	- [Good-Better-Best Design Rules](#good-better-best-design-rules)
8	- [Naming Tiers](#naming-tiers)
9	- [The Feature-Allocation Matrix](#the-feature-allocation-matrix)
10	- [Designing Upgrade Paths](#designing-upgrade-paths)
11	- [Bundle or Unbundle: A Checklist](#bundle-or-unbundle-a-checklist)
12	- [Pricing-Page Implications](#pricing-page-implications)
13
14	## Leaders, Fillers, Killers
15
16	Packaging starts from one observation: features are not equal in the buyer's mind, and treating them equally destroys value. Every feature falls into one of three classes — for a given segment:
17
18	- Leaders drive the purchase decision. The buyer would walk without them; they would pay meaningfully more to get them. A package exists to deliver its leaders.
19	- Fillers add modest value. Nice to have, tip the scales in a tie, harmless to include — but nobody buys for them and nobody pays extra for them. Fillers round out a package and differentiate tiers cheaply.
20	- Killers reduce willingness to pay when forced into the package. The buyer does not want them and resents funding them. Classic killers: paid-for capabilities a segment will never use ("why am I paying for call-center features?"), mandatory services (required onboarding fees), or features that add complexity the segment fears.
21
22	The segment qualifier is everything. On-premise deployment is a killer for a startup buyer (cost, maintenance, fear) and a leader for a bank (compliance). SSO is invisible to freelancers and non-negotiable for enterprises. There is no absolute list — only a per-segment classification, which is why segmentation precedes packaging.
23
24	## The Classification Procedure
25
26	Run this before designing tiers, and again whenever a significant feature ships:
27
28	1. List the units of value. Enumerate every feature or capability a buyer could perceive as a thing they get — typically 15-30 items. Group sub-features (ten small report types = "reporting"). If the list exceeds ~30, you are itemizing too finely.
29	2. Collect evidence per item, per segment. From WTP interviews and surveys:
30	- Decision impact: "Which of these would have to be present for you to buy?" / "Rank the top 5 that drive your decision."
31	- Incremental WTP: "How much more would you pay for a version with X?" or point-allocation across the list.
32	- Negative reaction: "Which of these would you not want to pay for, even bundled?" / "Would including X at a higher price make you walk away?"
33	3. Score and classify. A practical rubric per segment:
34
35	\| Evidence pattern \| Class \|
36	\|------------------\|-------\|
37	\| Top-5 decision ranking for ≥40% of segment, positive incremental WTP \| Leader \|
38	\| Rarely ranked, near-zero incremental WTP, no negative reaction \| Filler \|
39	\| ≥20% of segment reacts negatively to paying for it \| Killer \|
40
41	4. Sanity-check against behavior. Usage data, lost-deal notes, and support requests should corroborate. A "leader" nobody uses after purchase is a marketing leader only — fine, but know it. A "filler" that churned customers cite as missing was a leader you misread.
42	5. Decide the fate of each killer. Three options: unbundle into an optional add-on (the default), move it to a tier whose segment values it (where it may be a leader), or cut it entirely if it is a killer for everyone.
43
44	## Good-Better-Best Design Rules
45
46	Three tiers is the default architecture because it exploits how people choose: extremes feel risky, the middle feels safe, and a premium anchor makes everything below it look reasonable.
47
48	1. Design "Better" first. The middle tier is the offer most buyers should take — the compromise effect will pull them there anyway, so build it to be genuinely right for your core segment and price it where you want your average revenue to land.
49	2. "Best" is the anchor and the enterprise home. It must contain real leaders for the high-WTP segment (not just bigger limits), priced 2-4x "Better." Even at modest volume it pays twice: directly, and by making "Better" an easy yes.
50	3. "Good" is the fenced entry. It exists to capture the low-WTP segment and to start upgrade journeys. Give it real value — a taste of the leader, not the meal. If "Good" fully contains the leader, nobody upgrades; if it is useless, it poisons trust and trials.
51	4. Plan around a 70/20/10 shape. As a planning expectation, aim for roughly 70% of buyers in Better, 20% in Best, 10% in Good. Strong deviations are diagnostic: most buyers in Good means weak fences or an overpriced middle; most in Best means your anchor is missing and you are likely minivating.
52	5. Fence with leaders, then limits. The primary fence between tiers should be a feature the higher segment genuinely values (leader fence). Quantity limits (seats, projects, API calls) are secondary fences — good for growth-based upgrades, weak as the only differentiator.
53	6. Four tiers maximum. A fourth tier (usually a free or a custom-enterprise tier) is acceptable; five or more measurably increases choice paralysis and support burden. Collapse before you add.
54	7. Price gaps must be explainable in one sentence per gap. "Team adds the integrations and approvals agencies need" — if you cannot say it, the buyer cannot see it, and the gap reads as arbitrary.
55
56	## Naming Tiers
57
58	Tier names are a self-segmentation device: a buyer should know which tier is theirs within five seconds.
59
60	- Name by customer or use stage: Solo / Team / Business / Enterprise, or Starter / Growth / Scale. These work because buyers identify themselves before reading the feature table.
61	- Avoid opaque sequences (Bronze/Silver/Gold, Basic/Plus/Premium) when segments differ by kind of need — metals only communicate "more," not "for whom."
62	- Never name a tier something aspirational that insults the others. "Professional" above "Basic" implies Basic buyers are amateurs; they notice.
63	- Keep names stable. Renaming tiers invalidates documentation, reviews, and word-of-mouth ("get the Team plan") — rename only with a repackaging worth that cost.
64
65	## The Feature-Allocation Matrix
66
67	The working artifact of packaging design — every feature, its classification per target segment, and its tier placement:
68
69	\| Feature \| Class (segment) \| Good ($19) \| Better ($49) \| Best ($129) \| Add-on \|
70	\|---------\|-----------------\|------------\|--------------\|-------------\|--------\|
71	\| Core editor \| Leader (all) \| ✓ \| ✓ \| ✓ \| — \|
72	\| Projects \| Fence (limit) \| 3 \| 25 \| Unlimited \| — \|
73	\| Slack/Teams integration \| Leader (Team seg) \| — \| ✓ \| ✓ \| — \|
74	\| Approval workflows \| Leader (Team seg) \| — \| ✓ \| ✓ \| — \|
75	\| Advanced analytics \| Leader (Agency seg) \| — \| — \| ✓ \| — \|
76	\| API access \| Leader (Agency seg) \| — \| Read-only \| ✓ \| — \|
77	\| Custom branding \| Filler \| — \| ✓ \| ✓ \| — \|
78	\| Email support \| Filler \| ✓ \| ✓ \| ✓ \| — \|
79	\| Dedicated CSM \| Leader (Enterprise) \| — \| — \| ✓ \| — \|
80	\| On-prem deployment \| Killer (SMB) / Leader (Ent) \| — \| — \| — \| $ \|
81	\| Mandatory onboarding \| Killer (all) \| — \| — \| — \| Optional $ \|
82
83	Rules visible in the template: each tier above Good adds at least one leader for its segment; killers never sit inside a tier price; limits create a second, growth-driven upgrade trigger; every row has an explicit decision (no "TBD" rows on a shipping pricing page).
84
85	## Designing Upgrade Paths
86
87	Packaging is static; customers are not. Design the journey between tiers:
88
89	- Place the fence where usage naturally grows. The best upgrade trigger is success: the team that hits the 3-project limit because the product worked. Analyze usage distributions and put limits just below the point where committed users land (if engaged teams typically reach 4-6 projects, the free/entry cap is 3).
90	- Prompt at the moment of need, not on a schedule. "You've hit your project limit — Team gives you 25" converts; a monthly upsell email annoys. Every fence needs an in-product moment that explains the next tier in terms of what the user was just trying to do.
91	- Let users preview the leader. Time-boxed trials of higher-tier features (7 days of analytics when first opened) outperform descriptions. A leader experienced is a leader bought.
92	- Never make downgrades destructive. Losing access to premium features is acceptable; losing data or exports is hostage-taking — it poisons reviews and, in some jurisdictions, regulators agree.
93	- Mind the cliff between self-serve and enterprise. If Best is $129/seat and Enterprise is "call us" starting at 10x, mid-market buyers fall into the gap. Bridge with a transparent volume schedule or a mid tier.
94
95	## Bundle or Unbundle: A Checklist
96
97	Bundling raises total willingness to pay when the parts reinforce each other; it destroys clarity when they do not. Work through the list:
98
99	Bundle when most of these are true:
100
101	- [ ] Components are complementary in use — each makes the others more valuable (editor + review + publishing)
102	- [ ] One buyer evaluates and pays for all components
103	- [ ] Buyers' WTP for components is negatively correlated (some value A highly and B mildly, others the reverse) — the bundle averages both into one strong yes
104	- [ ] Buying separately would create integration or decision friction you can remove
105	- [ ] The bundle story is tellable in one sentence ("everything a podcast team needs")
106
107	Unbundle when any of these is true:
108
109	- [ ] A component is a killer for a meaningful segment of bundle buyers
110	- [ ] Different components are bought by different roles or budgets
111	- [ ] A component's natural price metric differs (per-seat product bundled with a per-volume API)
112	- [ ] The bundle price exceeds the prohibitive threshold of your core segment even though individual WTPs are healthy
113	- [ ] Competitors win by selling the one component a customer wants without the rest
114
115	Default resolution for borderline cases: tiered bundles (the core bundle plus add-ons) — keep the complementary heart together and let contested components be chosen.
116
117	## Pricing-Page Implications
118
119	The pricing page is where packaging theory meets a visitor with 20 seconds of patience:
120
121	1. Three or four columns, one highlighted. Highlight "Better" with a "Most popular" badge — only if it is actually true; invented popularity claims are both unethical and, in several markets, illegal.
122	2. Use the anchor deliberately. Either order tiers premium-first (strong anchor for sales-led products) or highlight the middle with the premium adjacent (standard for self-serve). Never hide the premium tier — it is doing anchoring work even when unsold.
123	3. Lead each column with its leader. The first 2-3 bullets under each tier name must be that tier's leaders for its segment — not the longest list. Bury fillers in the expandable comparison table below.
124	4. State the price metric next to the price. "$49 per editor / month, billed annually" — ambiguity about the metric ("per user? per viewer?") kills conversion and seeds support debt.
125	5. Make the annual/monthly toggle honest. Show the math; don't display annual-billed prices as if monthly without labeling.
126	6. Answer fence questions in an FAQ. "What happens when I hit the project limit?", "Can I downgrade?", "Do viewers cost money?" — every fence creates a question; unanswered questions create abandoned carts.
127	7. Test packaging before price. A/B tests that move features between tiers or change the highlighted column routinely shift revenue more than ±10% price tests — and are safer to run.
128