Point of view: Make it easy to start and easy to grow. Tiers define the default path for each segment. Add-ons capture high-variance, high-value needs without forcing upgrades. This is a practical workflow: define tiers and add-ons, decide what goes where, design upgrade paths, and ship with rules customers can predict.

What tiers and add-ons are (and why they matter)

Tiers. Predefined bundles for distinct segments (for example, Starter, Growth, Enterprise). Each step increases capability, limits, and support.
Add-ons. Optional modules or capacity on top of a tier. Useful when a minority of customers value a capability much more than the median.

Why use both

• Acquisition clarity: tiers reduce choice overload.

• Expansion flexibility: add-ons let accounts grow spend without jumping a full tier.

• Better willingness-to-pay capture: heavy users or specialized buyers can pay for what they uniquely value.

• Roadmap signal: packaging pressure reveals which features are baseline versus premium.

Primer: OpenView on packaging and value metrics.

Pros and cons at a glance

Tiers

Pros

• Simple buying experience

• Clear segmentation and positioning

• Built-in upgrade path

• Easier competitive comparison

Cons

• Rigid bundles can force “all or nothing” upgrades

• Risk of over- or under-serving segments

• Repackaging later can be disruptive

Reference layouts: Salesforce editions, Airtable plans

Add-ons

Pros

• Precise monetization for polarized features

• Incremental expansion without a tier jump

• Lets different buyer personas participate (for example, IT funds a security add-on)

• Good for variable costs or expensive capabilities (AI/compute, advanced analytics, premium support)

Cons

• Can create decision complexity if there are too many

• Risk of “nickel and diming” perception

• Harder to compare against competitors that bundle generously

Tasteful examples: Notion AI, Figma Dev Mode

How add-ons drive expansion without forced upgrades

• Bridge the gap. If Pro is $100 and Enterprise is $300, a $50 add-on for a single Enterprise feature can raise ARPU without a $200 jump.

• Capacity relief. Offer usage packs when customers hit plan limits. Prevent churn at the ceiling and keep momentum until a full upgrade makes sense.

• Lifecycle timing. Many premium needs appear after activation. Sell the core first, attach the add-on when the value is obvious.

• Persona targeting. Some capabilities map to different budget owners. Keep them separate so the right team can fund them.

• Cost alignment. If a feature has real variable cost, put it behind an add-on or usage pack to protect unit economics.

More on price architecture: Paddle/ProfitWell on feature packaging.

When tiers are better

• Core value. Capabilities most customers need should live in tiers. Gate them by tier level, not as add-ons.

• Simplicity as a moat. If your segment values speed and clarity, fewer choices convert better.

• Enterprise procurement. Large buyers prefer complete bundles that check security, compliance, and support in one line item.

• Positioning. Tiers communicate who the product is for. Use them to anchor your narrative and defend against comparison tables.

Playbook: combine tiers and add-ons for growth

A) Define tier “jobs” and guardrails

For each tier specify:

• Target segment and outcomes

• Core capabilities and limits tied to your value metric

• Support and compliance expectations

• List price range and typical approval path

Keep to two to four tiers. If you think you need five, consolidate.

B) Choose add-on candidates

Good add-ons are:

• Polarized (some customers love it, many do not need it)

• Expensive to provide (AI/compute, premium support, custom connectors)

• Adopted later in the lifecycle

• Owned by a different buyer (security, data governance)

• Able to stand alone with a clear value story

Limit the catalog. Most customers should not need more than one add-on at purchase.

C) Set rules for what goes where

• Core adoption drivers → tiers

• Specialized power features → add-ons

• Usage variability → credits and packs

• High-touch service → enterprise tier or services SKU

D) Design upgrade paths you can explain in one sentence

• “If you need SSO and audit logs, move to Business.”

• “If you need deeper analytics, add the Analytics Pack on any plan.”

• “If you exceed included credits, buy a pre-paid block at volume rates.”

E) Price with simple math and visible thresholds

• Anchor add-ons at 20–60% of the associated tier price unless the value case stands alone.

• Publish included allowances and overage rates.

• Offer pre-paid blocks for predictability and discounts for commitments.

• Keep round numbers buyers can remember.

Useful framing ideas: Nick Kolenda on pricing psychology.

F) Communicate outcomes, not parts

On the pricing page and in sales materials:

• Describe what the customer can now do and which metric moves

• Show who typically buys an add-on and when

• Provide a one-screen calculator for capacity decisions

Inspiration: HubSpot ROI calculators

Examples

• Collaboration SaaS. Three tiers by admin and security depth. Add-ons: advanced analytics, HIPAA pack, extra storage blocks. Outcome: clear entry path and multiple expansion levers.

• AI help desk. Tiers include user seats and monthly inference credits. Add-ons: premium models, fine-tuning, white-glove support. Heavy accounts pre-buy inference blocks for predictable spend.

• Data platform. Tiers align to governance and performance SLAs. Add-ons: private link, audit exports, dedicated compute. Enterprise bundles support and security to satisfy procurement.

Pitfalls to avoid

• Too many add-ons. Decision fatigue hurts conversion. Curate the list.

• Hiding essentials behind add-ons. Customers will view this as nickel and diming.

• Mismatched upgrade economics. If Pro + add-on > Enterprise, buyers will stall.

• Ambiguous limits. Publish allowances and overage math to avoid surprises.

• No migration plan. Repackages happen. Grandfather cleanly and provide clear paths.

Implementation checklist

1. Tier “jobs” defined with outcomes, limits, support, and list price ranges

2. Add-on candidates pass the polarized or expensive test and are few in number

3. Clear rules for what is tiered, what is add-on, and what is usage-based

4. Visible allowances, overage rates, and pre-paid block pricing

5. Pricing page copy explains upgrade paths in one sentence each

6. Sales has a one-pager and a calculator for capacity and ROI

7. Migration and grandfathering policy documented before launch

Further reading

• Packaging and value metrics: OpenView

• Feature packaging and price architecture: Paddle/ProfitWell

• Examples of tasteful add-ons: Notion AI, Figma Dev Mode

• Reference plan layouts: Salesforce editions, Airtable plans