We spent two hours in a conference room staring at our three pricing tiers, and nobody could explain why they existed.
Basic, Pro, Enterprise. The classic SaaS packaging structure. We had features neatly organized by tier: Basic got the essentials, Pro got more features, Enterprise got everything plus white-glove support. It looked professional on the pricing page.
Then our Head of Customer Success asked a question that broke everything: "Why do Basic customers churn at 45% annually while Pro customers churn at 8%?"
The room went silent. We'd optimized our tiers around features. We'd never asked whether the tiers matched how customers actually grew.
Turned out Basic tier was perfectly designed for customers to outgrow it within 60 days, hit artificial limits we'd built into the product, get frustrated, and leave. We were converting customers into churn risks by selling them the wrong package from day one.
Our packaging wasn't a strategy. It was just features organized by price, optimized for no one.
The Tier Structure That Everyone Copies (And Why It Fails)
Most SaaS companies have the same three-tier structure we had: a cheap entry tier to capture leads, a mid-tier "sweet spot," and an enterprise tier for big deals.
The logic makes sense on a whiteboard. Start customers small, let them expand as they grow, capture more revenue over time. Classic land-and-expand.
The reality is messier. Your Basic tier either has too many features (customers never need to upgrade) or too few (customers hit limits immediately and churn instead of upgrading).
For us, Basic was deliberately limited. We capped users at 5, capped data storage at 1GB, and removed "advanced" features we'd decided were "premium." The goal was to create upgrade pressure.
It worked. We created so much pressure that customers exploded and left.
I watched the patterns in Intercom. A company would sign up for Basic, add their team, start using the product actively, then hit the 5-user limit three weeks later. They'd get an error message: "Upgrade to Pro to add more users."
We expected them to upgrade. Instead, 60% of them churned within the next 30 days.
When I interviewed these churned customers, they all said the same thing: "We were just getting started. The limit felt arbitrary. We weren't ready to triple our investment when we were still evaluating whether the product worked."
We'd designed Basic tier for customers who wanted to "try before buying." But we'd capped it at a point where they couldn't actually prove value before hitting a wall. The tier structure optimized for our revenue model, not their success.
The Workshop That Changed How We Think About Packaging
After watching dozens of customers churn at the Basic-to-Pro boundary, we ran a packaging workshop to rebuild our tier structure from scratch.
I didn't start with features or price points. I started with customer jobs-to-be-done at different company stages.
The first question I asked the team: "Forget our current tiers. Describe the three types of companies that buy our product based on how they use it, not how much they pay."
We spent 45 minutes debating this. Marketing wanted to segment by company size. Sales wanted to segment by deal value. Product wanted to segment by feature usage.
Finally, our CSM team cut through it: "There are companies testing to see if this works, companies using it actively for one team, and companies rolling it out across their organization."
Testing. Single team. Organization-wide.
That became our new tier framework. Not Basic/Pro/Enterprise. Not Small/Medium/Large. Not feature sets arbitrarily divided by "sophistication."
We had three genuinely different use cases that needed three different packages:
Starter tier was for companies validating that our product solved their problem. They needed unlimited time to test, basic features that proved value, but none of the scale features because they weren't scaling yet.
Team tier was for companies who'd proven value and were now using it actively within one department. They needed collaboration features, higher limits, and integrations to fit into their workflow.
Company tier was for companies rolling it out across multiple teams or geographies. They needed admin controls, security features, advanced analytics, and dedicated support.
This sounds obvious now. It wasn't obvious in the room. We'd spent years thinking about packaging as feature sets, not as customer maturity stages.
The Uncomfortable Truth About Feature Gatekeeping
The hardest part of the workshop was deciding what went into each tier. We had 40+ features to allocate, and every product manager wanted their feature in multiple tiers to "maximize adoption."
The VP of Sales had the opposite view: keep features out of lower tiers to create upgrade incentive.
Both perspectives were wrong.
I made the team do an exercise: for each feature, answer one question: "Does this feature help customers get value faster, or does it help customers who've already gotten value do more?"
If it helps get value faster, it belongs in Starter. If it helps customers who've gotten value do more, it belongs in Team or Company.
This framework immediately surfaced our biggest packaging mistake. We'd put our best onboarding features—the ones that helped new customers understand the product—in Pro tier, because they were "sophisticated."
New customers on Basic tier were struggling through a worse onboarding experience, taking longer to get value, and churning. Meanwhile Pro customers who already understood the product got enhanced onboarding they didn't need.
We'd literally inverted the tier logic. We'd given the worst experience to the customers who needed the most help.
Once we applied the "get value faster vs. do more" framework, half our features moved tiers. Onboarding wizards, getting started templates, basic integrations—all moved down to Starter. Advanced analytics, API access, custom workflows—all moved up to Company.
The result was counterintuitive: our cheapest tier got better, not worse. It included more features than our old Basic tier, but those features were all focused on helping customers prove value quickly.
Why "Good, Better, Best" Thinking Breaks Packaging
Most pricing pages present tiers as "good, better, best"—implying that higher tiers are objectively superior and lower tiers are compromised versions.
This makes sense for physical products. A Toyota Camry is objectively less capable than a Lexus. You buy the Camry because you can't afford the Lexus.
For software, it's backwards. Your cheapest tier should be the best at one specific job, not the worst version of every job.
During our workshop, I asked the team: "Is our Starter tier the best product in the market for companies validating whether this category of tool works for them?"
The answer was no. We'd stripped out features and imposed limits that made validation harder. We'd designed a deliberately worse product to create upgrade pressure.
This is the trap most SaaS companies fall into. You think about tiers as feature counts, not as optimized solutions for different customer jobs.
We rebuilt Starter tier to be the absolute best product for validation. Unlimited time, unlimited users (up to 10), all the core features, great onboarding, responsive support. The only things we removed were features that literally didn't matter until you'd scaled—audit logs, SSO, custom roles.
The old mindset would have screamed "you're giving away too much!" The new mindset recognized that if Starter customers successfully validated value, they'd eventually need Team or Company features naturally.
We weren't creating upgrade pressure through artificial limits. We were creating upgrade demand through customer growth.
Six months after relaunching this tier structure, our upgrade rate from Starter to Team went from 12% to 34%. Churn in Starter dropped from 45% to 18%. We'd made the cheap tier better and sold more expensive tiers as a result.
The Test That Revealed What Customers Actually Valued
Halfway through the workshop, we hit a problem. We'd reorganized features into tiers based on our theory of customer jobs-to-be-done. But we hadn't validated whether customers agreed with our tier definitions.
So we tested it. I created a simple exercise: showed 30 customers our proposed new tier structure and asked them to place themselves in a tier based on the description, not the price.
Then I asked: "If you could add one feature from a higher tier to your current tier, what would it be and why?"
The responses were fascinating. Starter tier customers didn't ask for "advanced" features from Team tier. They asked for things like better templates, more integrations with tools they already used, and clearer getting-started guidance.
Team tier customers didn't ask for enterprise features. They asked for better collaboration tools, workflow automation, and usage analytics to prove ROI to their boss.
Company tier customers asked for things we hadn't even built yet: custom reporting for executives, regional data residency, dedicated CSM.
Each tier had its own feature gravity. Customers in Starter tier weren't looking up at Team tier thinking "I wish I had those features." They were looking laterally thinking "I wish Starter was even better at helping me validate this."
This insight changed everything. Instead of designing tiers as a ladder where each rung has more stuff, we designed them as different products optimized for different jobs.
Starter tier competed with "doing this manually" and "trying our competitors." Team tier competed with "expanding DIY solutions" and "buying standalone tools." Company tier competed with "building internally" and "enterprise alternatives."
We weren't selling good, better, best. We were selling three different products that happened to share the same core platform.
The Pricing Math That Everyone Gets Wrong
Once we'd redefined our tiers around customer jobs, we had to price them. This is where most packaging workshops fall apart.
The CFO wanted to maintain our revenue per customer. Marketing wanted to keep prices low to drive acquisition. Sales wanted flexibility to discount Enterprise.
Everyone was optimizing for their own metric, which is how you end up with tier pricing that makes no one happy.
I introduced a different framework: price each tier based on the value you enable at that stage, not the cost to serve or the features you include.
Starter tier customers are validating whether this category of tool works for them. The value we provide is risk reduction—they can test thoroughly before committing. Price should reflect the value of that certainty, not the cost of the features.
Team tier customers are using it actively within one department. The value we provide is productivity improvement for that team. Price should reflect the value of those productivity gains.
Company tier customers are rolling it out organization-wide. The value we provide is strategic capability they couldn't build themselves. Price should reflect that strategic impact.
This led to counterintuitive pricing. Our old Basic tier was $29/month because we'd stripped out features to make it cheap. Our new Starter tier was $49/month even though it included more features, because the value of risk-free validation was higher than we'd been charging.
Our old Enterprise tier started at $500/month with heavy discounting because sales didn't believe customers would pay more. Our new Company tier started at $800/month with less discounting because we'd clearly articulated the strategic value.
The math worked. Average revenue per customer increased 28% despite having a cheaper entry tier available, because we were pricing to value at each stage rather than pricing to feature count.
What Actually Happened After We Launched
We rebuilt our entire tier structure in one workshop. Relaunched it 60 days later. And immediately second-guessed everything when early metrics looked weird.
Starter tier signups dropped 20% in month one. The CFO panicked. We'd raised the price from $29 to $49 and scared away customers.
Except conversion from trial to paid increased 35%. We were getting fewer signups but more serious evaluators. The higher price filtered out tire-kickers who were never going to buy.
Team tier adoption took off. In our old structure, 12% of customers ever upgraded from Basic to Pro. In the new structure, 34% of Starter customers graduated to Team within 6 months. They weren't upgrading because they hit limits—they were upgrading because they'd proven value and wanted to scale.
Company tier was the biggest surprise. We'd assumed it would be a sales-led tier that required custom negotiations. Instead, 15% of Team tier customers self-upgraded to Company tier online because we'd made the value proposition clear.
The tier structure that had felt risky in the workshop—give away more in Starter, charge more in Company, focus on jobs-to-be-done instead of feature counts—performed better than our "safe" original structure across every metric.
The Framework That Actually Transfers
After running this workshop for our company and then consulting with a dozen others, I've found the framework that works across different products:
Your tiers should map to customer maturity stages, not feature sophistication levels. Ask: what are the three fundamentally different ways customers engage with products in your category as they grow?
For us it was validate → team usage → company-wide. For a marketing tool it might be test campaigns → active channel → full marketing stack. For dev tools it might be solo developer → team project → platform infrastructure.
Price to the value you enable at each stage, not the features you include. Starter tier that helps customers de-risk a decision is more valuable than you think. Company tier that enables strategic capabilities is more valuable than you're charging.
Move features between tiers based on "helps get value faster" versus "helps do more with value already proven." This usually means moving onboarding, templates, and getting-started features down to cheaper tiers and moving scale, governance, and customization features up to expensive tiers.
Test your tier definitions with real customers before you launch. Show them descriptions and features, ask them to place themselves in tiers, and listen for what they wish they had versus what tier they think they should buy.
Most packaging workshops fail because they start with "how should we organize our features?" The better question is "what are the distinct jobs customers hire our product to do at different stages, and what does each stage need to be successful?"
Answer that, and the tier structure becomes obvious.