Starter, Pro, and Enterprise are not tier names. They're a confession that the pricing page got built before anyone decided who the tiers were for. A buyer arrives at a three-column grid labeled with the generic ladder and is asked to self-select into a bucket defined by feature density and a dollar sign. That is not positioning. That is sorting.
The tier name is the first positioning decision the buyer sees. Before the feature list, before the call-to-action, before the price — three words that should answer the question "which one is me." Starter, Pro, Enterprise answer the question "how expensive am I." Those are different questions.
What tier names should do
A tier name has three jobs. It should route the buyer to the right tier in one read. It should anchor the expectation of what's included before the feature list is scanned. And it should reinforce the positioning — the same ICP, the same unique claim — that the rest of the site is making.
The generic ladder fails at all three. Starter routes nobody; it implies "new," which offends the founder who runs a twelve-person team and doesn't want to be called a starter. Pro anchors to "more features" rather than "different use case," which turns every upsell into a feature-count argument. Enterprise has degraded into "call us," which routes the buyer to a contact form instead of a tier.
A tier name doing real work tells the buyer who it's for before the feature list is read. The feature list confirms the signal; it doesn't create it.
Four patterns that work
The replacements divide into four patterns. Pick the one that matches where your buyer variation concentrates.
1. Persona-based
Name the tier after the buyer it serves. Works when the product has distinct buyer personas with different decision criteria.
- Figma's version: "Professional" for individual designers, "Organization" for design teams at companies, "Enterprise" for security-heavy buyers. The persona is the tier.
- Fictional example: A sales engagement tool could tier as "SDR Team" (individual rep features), "Sales Ops" (admin and reporting), "RevOps" (pipeline modeling and integrations). A new buyer knows which one they are before they read the features.
The risk with persona naming is outgrowing the persona. A company that starts in the SDR tier and grows into Sales Ops wants the upgrade to feel natural, not like a re-pitch. Persona naming works best when the personas are sequential — one tier's buyer often becomes the next tier's buyer — rather than orthogonal.
2. Use-case-based
Name the tier after the job the buyer is hiring the product to do. Works when the product has one persona but different use cases with different willingness-to-pay.
- Illustrative pattern: A spreadsheet-database hybrid could tier as "Experiments" (read/write for a small team), "Workspaces" (shared databases with permissions), "Operations" (automations and integrations), "Regulated" (audit logs, SSO, data residency). The tier names the job the buyer is hiring the product to do.
- Fictional example: An analytics tool could tier as "Dashboards" (read-only reporting), "Exploration" (ad-hoc analysis), "Modeling" (transformation and metrics). The buyer knows which tier fits based on what they're trying to do on Tuesday, not how senior they are.
Use-case naming fails when the use cases aren't actually distinct. If 80% of buyers do all three jobs, the tier is arbitrary and the naming reads as marketing. The pattern works when the use cases map to different weeks in the buyer's life.
3. Scale-based
Name the tier after the size of the operation, not the size of the feature set. Works when the product's value scales directly with volume (seats, records, events).
- Linear's approach: Tiers named by company scale signals — solo founder, small team, growing team — rather than feature tiers. The name tells the buyer where they are on a scale axis, not where they are on a capability axis.
- Fictional example: A fintech tool could tier as "Solo" (one-person LLC), "Startup" (under 25 employees), "Growth" (25 to 250), "Scale" (250+). The buyer self-selects on a fact they already know about themselves.
Scale naming is the closest to the generic ladder but avoids its main failure: it signals who the tier is for rather than how expensive it is. "Growth" routes a 75-person company; "Pro" leaves them guessing.
4. Capability-based
Name the tier after the capability it unlocks, when the capability is the point. Works when the product has a headline feature that the buyer is explicitly trading up to.
- Example pattern: A CRM could tier as "Contacts" (contact database only), "Pipeline" (adds deal tracking), "Forecast" (adds pipeline modeling and reporting). The tier is named for what the buyer gets that they didn't before.
- When it shines: The upsell conversation is "you came for contacts, now you need pipeline" rather than "you're a bigger customer now." The tier name is the argument.
Capability naming works when the product has a genuinely tiered capability stack. It fails when the tiers are feature-gated for monetization reasons rather than capability reasons — in that case, the name reveals the gating and the tier reads as punitive.
Side-by-side
The generic ladder column is included to make the point honestly: it's not always wrong. Some products really are the same tool with more seats and more features, and a scale-adjacent label like "Free/Team/Business" is serviceable. But most products picking it are picking it by default — nobody decided, so the default showed up.
The test
Before shipping a new pricing page, show the three tier names — without the feature list, without the prices — to five people in the ICP. Ask one question: "which one is you, and why." If four out of five correctly route themselves to the tier you'd route them to, the names are doing their job. If the five answers cluster around "I can't tell," the tier names are labels, not positioning.
The test takes fifteen minutes. Most teams skip it because the pricing page is already live and the tier names have been in the deck for two years. That's not a reason they're working. That's the reason the page is under-converting.
The bigger move
Renaming tiers is usually a downstream fix. The upstream question is whether the product has distinct tiers at all, or whether the three-column grid is hiding the fact that the company hasn't segmented its buyer yet. If renaming exposes that — if the team can't agree on what each tier is for — the pricing page isn't the problem. The positioning brief is.
A pricing page reveals the positioning underneath it. When the tier names are generic, the positioning usually is too. Fix the brief, and the tier names start to suggest themselves. Fix the tier names without fixing the brief, and the new names will drift back toward the generic ladder within two quarters.
Positioning Brief
A living, one-page positioning document the Analyst re-writes as pillars, signals, and decisions change.
See how it worksOne sharp positioning read, most Thursdays.
Field-tested frameworks, teardowns, and pattern notes from our working library. No "Top 10" lists. No launch roundups. Unsubscribe whenever.
Keep reading
Pricing Page Psychology: 9 Tactics to Signal Value (Not Premium)
Pricing pages do two jobs: convert and signal. Most do the first and botch the second. Nine tactics that communicate value without slipping into premium-positioning territory.
7 Pricing Page A/B Tests That Failed (And What Worked)
Seven pricing-page A/B tests from a single mid-market SaaS company's year-long optimization program — the ones that lost money, the one that saved it, and the pattern that explains both.
How Competitor Pricing Changes Should Influence Your Positioning
The discount-reflex is the wrong response to a competitor's pricing move. Here's the four-question diagnostic that tells you what the pricing change actually signals — and the narrative response, not the pricing response, that usually wins.