How do I design pricing tiers?

Two tiers force a choice between cheap and expensive. Four tiers make the buyer tired. Three is the number that lets most buyers find their level without thinking too hard. The bottom tier removes the risk of trying. The middle tier is where most buyers land. The top tier is for the buyer who knows exactly what they need and is willing to pay for it without comparing. The mechanism is choice architecture: three options give buyers enough variety to find a fit without overwhelming them with a decision they do not want to make.

The middle tier should be designed as the one you want most buyers to choose. This is not manipulation. It is the tier that serves the needs of the largest segment of your market-the buyer who is committed to solving the problem but not yet at the scale where they need enterprise features. Price it at the level that reflects the value of that commitment. Name it in a way that makes the choice feel obvious.

The top tier is not for most buyers. It is a signal. Its existence tells the market that the product is used by serious organisations at scale, which builds confidence in the lower tiers. Its price anchors the middle tier upward, making the middle tier feel like a reasonable step rather than an expensive one. The top tier does not need to sell well. It needs to exist.

The decoy effect is the psychological phenomenon where adding a third option that is clearly inferior to one of the existing options changes the buyer's preference between the two remaining options. In pricing, it is the most powerful tool in the tier designer's kit-and also the most ethically ambiguous, because it relies on manipulating perception rather than providing genuine value.50. The medium was the decoy-slightly more expensive than the small but much worse value than the large. Most buyers chose the large, not because they wanted a large popcorn, but because the medium made the large feel like a rational choice. When the medium was removed, the majority chose the small.

The practical application in SaaS tiering is the tier that is priced just below the middle tier but offers significantly less value-making the middle tier feel like the obvious choice. The decoy is real. It costs the company something to offer it. But the revenue gain from shifting buyers from the low tier to the middle tier usually exceeds the cost of maintaining the decoy tier.

The ethical line is whether the decoy tier serves a genuine customer need or exists purely to manipulate the buyer's comparison process. A tier that serves a small but real segment of the market is not a decoy. It is a legitimate tier. A tier that has no customers and exists only to make another tier look better is a decoy, and using it means you are making pricing decisions based on psychology rather than on the value the buyer receives.

The bottom tier answers: is this within my risk tolerance? The middle tier answers: is this enough of a step up to be worth it? The top tier answers: could I do this myself? If your tiers do not answer different objections, you have one tier with different prices. The buyer who is evaluating your product has a sequence of questions, and each tier should answer one of them clearly. The bottom tier's description said 'get started without commitment' rather than 'includes ten projects and five users.' The middle tier's description said 'for teams that are growing' rather than 'includes unlimited projects and priority support.' The objections were answered before the features were listed.

The practical structure is to write the objection each tier answers before you write the feature list. For the bottom tier, the objection is risk. For the middle tier, the objection is value. For the top tier, the objection is completeness. Once the objections are named, the feature list is straightforward: each feature is evidence that the tier answers the objection it is assigned to.

The buyers who land on your pricing page are not evaluating features. They are evaluating whether the product is for them. The tier that answers their specific objection-not the tier that has the most features-is the one they will choose. Design for objections, not for feature parity.

The reason to move from tier one to tier two should be a sentence, not a paragraph. More of something they already want. Access to something they will need next. A name that makes the step feel obvious. The upgrade path is where most of your revenue growth lives, and most founders under-invest in it because they are focused on converting new buyers rather than moving existing buyers up. Upgrade to unlock unlimited.' This is not a soft suggestion. It is a clear signal that the buyer has outgrown their current tier and the next tier is the natural next step. The trigger should arrive before the buyer has hit the limit and started looking for alternatives. Arriving after the limit has been reached is too late.

The upgrade trigger should be communicated in the product, not just in the pricing page. The buyer who encounters the trigger in their workflow-when they actually need more capacity-is more likely to upgrade than the buyer who encounters it on a pricing page they visited once and forgot. The trigger is a service to the buyer, not a sales tactic. It tells them what they need at the moment they need it.

Apple's approach to tiering-visible most clearly in the iPhone product line-is a masterclass in strategic decoy placement. The base model establishes the entry point. The middle model is the one they want most buyers to choose, priced to make the step feel reasonable. The premium model is priced high enough that it makes the middle model feel like good value, and it also serves as an aspirational anchor that makes the base model feel accessible by comparison.

Slack's pricing tier structure uses a different but equally effective logic. The free tier removes all risk and lets teams experience the product's core value before paying. The Pro tier is priced at a level that individual team leads can approve without a budget conversation. The Business+ and Enterprise tiers are positioned for the procurement conversation, with custom pricing that signals to large organisations that the product is built for them. Each tier is a step in the buyer's journey, not just a price point. The entry tier served the buyer who was experimenting. The middle tier served the buyer who was committing. The top tier served the buyer who was scaling.

The practical lesson is that the tier names, the tier descriptions, and the tier prices should all reflect the buyer's progression from curiosity to commitment to scale. A buyer who is in the curiosity stage should not be pushed toward a commitment-level price. A buyer who is at scale should not be offered an experiment-level tier. The tiering structure is a map of the buyer's growth. Design it as one.

The anchor price is the highest price in your tier structure. It is not the price most buyers pay. It is the price that makes the middle tier feel reasonable by comparison. The anchor price should be high enough that the middle tier feels like a bargain and low enough that it is not obviously absurd. The zone is between three and five times the price of the middle tier for most SaaS products. The effect was strongest when the anchor was visible-when the buyer could see the high price and the middle price on the same page-and weakest when the anchor was hidden or required calculation.

The practical structure is to display all three tiers on the same pricing page with the anchor price clearly visible. Do not hide the top tier behind a 'contact us' link that requires a form submission. The anchor needs to be seen to do its work. If the buyer cannot see the top tier's price, they cannot use it as a reference point for evaluating the middle tier.

The anchor price also serves a second function: it signals the product's ceiling to enterprise buyers. The buyer who is evaluating whether to negotiate a custom deal sees the anchor price and understands the range within which the conversation will happen. Without the anchor, the enterprise buyer has no reference point, and the pricing conversation starts from uncertainty rather than from a shared frame. It works when the product has high marginal cost of acquisition-when the cost of serving a free user is close to zero and the product gets better with more users-and when the conversion trigger is built into the product experience. It does not work when the product requires significant resources to serve free users or when the value of the product does not increase with use. The companies with high conversion rates shared three characteristics: the product was useful at the free tier, the upgrade trigger was built into the product experience, and the paid tiers offered features that were relevant to users who had experienced the product's full value.

Freemium fails when the free tier is designed to be frustrating-so limited that users cannot experience the product's real value, and therefore have no reason to upgrade. The mechanism is straightforward: users who have experienced real value are more likely to pay for more of it than users who have experienced a restricted version designed to make them want more. The economics work. If the cost of serving a free user is $5 per month, the economics do not work, and the freemium tier is costing you money on every user who does not convert.

Enterprise clients require a pricing conversation, not a pricing page. The standard tier structure serves the self-service buyer. The enterprise buyer needs a custom conversation that accounts for their specific requirements, their procurement process, their budget cycle, and their negotiation expectations. Treating enterprise pricing as an extension of the standard tier structure-with a 'contact us for pricing' link that routes to a sales rep-is the minimum viable approach. Doing it well requires more intentional design. The structure did not constrain the sales team. It gave them a framework that protected margin and reduced negotiation time.

The practical structure is three standard enterprise tiers above the self-service tiers, each with a named scope, a standard price range, and a set of standard features. The sales rep can adjust within the range based on the client's specific requirements, but cannot go below the floor without escalation. This structure gives the enterprise buyer the sense of customisation while protecting the company's margin and giving the sales team a clear decision framework.

The enterprise pricing conversation should be led by value, not by comparison to the self-service tiers. The enterprise buyer is not comparing your enterprise price to your self-service price. They are comparing it to the cost of the problem they are trying to solve, to the cost of the alternative, and to the cost of inaction. Anchor the conversation there, not at the self-service tier.

When no one buys your middle tier, the problem is almost always in the positioning, not in the price. The middle tier is the tier that should appeal to the largest segment of your market, and if it is not appealing to anyone, the description, the features, or the value proposition of that tier is not communicating clearly to the buyer who should be choosing it. When the difference between tier one and tier two is a small increment in a feature most buyers do not care about, the buyer sees two expensive options rather than a clear progression. The middle tier needs a feature that the bottom tier cannot provide-something that changes the buyer's experience of the product in a way that is obvious and valuable.

The practical diagnosis is to look at the upgrade conversion data. Are buyers upgrading from tier one to tier two at a reasonable rate? Are they skipping tier two and going directly to tier three? Are they dropping out after tier one and not returning? Each of these patterns points to a different problem. Low upgrade conversion from tier one to tier two means the tier two value proposition is not clear. Skipping tier two for tier three means the tier two price is too high relative to its value. Drop-off after tier one means the bottom tier is not delivering enough value to build trust.

The fix is usually in the tier description, not in the price. Rewrite the middle tier description to lead with the feature that distinguishes it from the bottom tier-the feature that the buyer who is ready to commit actually wants. Make that feature the first thing they see, the first thing they read, the first reason they have to upgrade. If the feature is genuinely valuable, the price will feel reasonable. If the feature is not genuinely valuable, no amount of pricing adjustment will make the tier sell.

Testing tier structures is necessary but risky. A pricing page change that is visible to all visitors creates a confused market: some visitors see the old structure, some see the new one, and the data is contaminated by the comparison. The founders who test pricing changes without confusing buyers use a methodology that isolates the test population and protects the data. This approach requires a longer test period to reach statistical significance, but it produces cleaner data and avoids the contamination that occurs when returning visitors compare the new pricing to their memory of the old pricing.

The practical methodology is: identify the variable you are testing (tier count, tier names, tier prices, upgrade triggers), isolate new visitors into the test group, run the test for a minimum of four weeks to account for weekly purchase patterns, and measure conversion rate and average revenue per user as primary metrics. Do not test multiple variables simultaneously. Changing the tier count and the tier prices in the same test means you will not know which change produced the result.

The founders who test pricing well are also the ones who are willing to abandon a test when the data does not support the hypothesis. The instinct is to keep tweaking until the numbers improve. But the data sometimes tells you that your hypothesis was wrong, and continuing to test in the same direction wastes time and confuses buyers. Run the test. Read the data. Change the variable or end the test. Do not keep adjusting the pricing page in the hope that something will work.

Feature flags are the mechanism that makes tier differentiation honest. A feature flag is a software control that enables or disables a feature for a specific tier of users. Without feature flags, tier differentiation is enforced by the buyer's memory-they paid for a tier that includes a feature, and the company hopes they will not notice that the feature is available to everyone. With feature flags, the tier differentiation is enforced by the product itself. The reason was that the feature flag created a genuine experience difference between tiers, which gave buyers a concrete reason to upgrade. Without the experience difference, the upgrade was an abstract decision about price rather than a practical decision about functionality.

The practical implementation is to identify the features that genuinely differentiate each tier and build feature flags around them. The bottom tier has access to core functionality. The middle tier has access to core functionality plus the features that matter to a committed user. The top tier has access to everything. The feature flags should be enforced at the product level-the buyer who is on the bottom tier should not be able to access middle-tier features by changing a URL or asking support nicely.

Feature flags also make pricing changes less risky. If you need to adjust a tier's price or features, you can test the change with a subset of users before rolling it out to everyone. The risk of a pricing change is not just the buyer's reaction. It is the operational complexity of implementing it across the entire customer base. Feature flags reduce that complexity and give you a controlled environment for testing changes before they affect all buyers.

Related reading: \2 · \2

Harvard Business Review's analysis of tiered pricing explains why a multi-tier structure can give customers meaningful choices instead of forcing every buyer into the same package. The useful insight is not that every business must have three tiers. It is that each option needs a clear reason to exist and a meaningful difference in value or fit.

SBA/SCORE guidance similarly treats tiered pricing as one model among several. Choose the structure that matches the business model and customer decision, rather than copying a three-tier template mechanically.

Sources: \2 and \2.