Designing SaaS tiers around a value metric
Five members of the Pricing work group work through value metrics, tier structure, add-ons, AI and who owns pricing.
Updated
Choose the value metric before you draw tiers, start from Good-Better-Best, and plan for the packaging to change.
- Value metric first. Alvaro Morales asks which unit of usage tracks the behavior you want customers to repeat; the wrong one rewards the wrong behavior. At Amplitude, Elena Verna paired one usage metric, events, with more advanced features up the plans. Kyle Poyar gates outputs and leaves inputs open, as SurveyMonkey caps the responses you can see while a survey keeps running.
- Start from Good-Better-Best. Kyle says about two-thirds of SaaS companies end up there. A feature belongs in an add-on when it is polarizing, reaches a different buyer, is usually adopted 6-12 months after purchase or costs real money to serve. Japna Sethi sorts features by the segment they move, and asks sales which deals a feature shows up in.
- Put capped AI in every tier. Elena argues against premium-only AI: give every tier some AI, cap it by usage, and let the cap prompt the upgrade. Alvaro, who first offered premium-only AI as an option, comes round for products where AI is the core value. Lauryn Motamedi lands there too, because new users need to try it during onboarding to activate. Kyle still sells AI as an add-on when it draws on a different budget.
- Ship changes fast, judge them slowly. Alvaro ships a change as a new plan version for new signups. Japna warns that free-to-paid conversion takes months to read. Kyle's survey found that at $5-20M ARR, 21% of companies say nobody owns pricing, so he names one owner. Elena gives model changes to a monetization council and lets product teams ship the rest.
Group chat with Kyle, Elena, Alvaro, Japna, Lauryn — the Pricing work group
Question:
How do you design SaaS packaging and pricing tiers?
Alvaro MoralesCo-founder and CEO of Orb. Former Engineering Manager at Asana
I start with the value metric and design the tiers after it. Before anyone draws three columns on a pricing page, answer one question: what unit of usage tracks the behavior you want customers to repeat? If you pick the wrong one, you reward the wrong behavior and lose the long-term retention you were trying to build.
YouTube
Once the metric is set, the tiers decide how much friction each customer segment sees. I think of pricing as friction. Too much and people won't even try the product. Too little and you leave money on the table. More teams now open every feature on the first paid tier and cap usage instead of locking features away, so buyers see the whole product before they commit to more.
Spotify
Good, better, best still works as a way to present the tiers. You show three value packages and steer the typical visitor to the middle one, which balances features against revenue potential. Presentation has a ceiling, though. If buyers can't tell why they should pick one tier over another, no page design fixes it, and you have to go back and rework the packaging itself.YouTube
For validation, scaled willingness-to-pay surveys and win/loss analysis help. Still, a few direct conversations asking buyers why they bought and how the price felt get you 70 to 80% of what a 12-month consulting engagement would.YouTube
The Orb customers who get this right treat packaging as a release process. Product teams send usage data in a standard schema before the price is decided, then revise tiers through versions and migrations. Pricing goes into the launch brief at the start, where it used to be the last checklist item.YouTube
Japna SethiDirector of Product at Atlassian. Former Head of Product-led Growth at Productboard
Alvaro covered the value metric, so I'll take the GTM side. I start with the go-to-market motion. PLG and sales-led are two ends of a spectrum, and most B2B companies sit somewhere in the middle, so the tiers have to do two jobs. The lower tiers let small teams self-serve, and the upper tiers give sales a reason to step in. At Productboard we kept asking whether we could offer an entry-level package simple enough for smaller teams or single-player use cases. That package grows brand and top of funnel, and those teams come back as leads once they mature in the product.YouTube
To place features in tiers, I sort them by which segment they move. Something like FedRAMP only matters to enterprise buyers, so it belongs at the top, while core workflow features matter to every segment.YouTube
The free plan gets the most debate. When we launched freemium inside a sales-led org, the biggest fear was losing pipeline. We handled that fear by running the riskiest bets first, because a fear only goes away once you have data against it.
amplitude This is where Alvaro's friction point turns practical. Write down hypotheses, risks and counter-hypotheses before launch, because a pricing change involves the whole org and stalls on fear, uncertainty and doubt without them.
Treat packaging as a series of experiments. At Dropbox we launched Professional and Family as new SKUs and changed the mobile Plus and Professional plans, and each change was its own launch with its own measurement. Give each change a full cycle of conversion and expansion data before you judge it, because the first two weeks will mislead you.
Elena VernaLeads growth at Lovable. Former SVP Growth at SurveyMonkey
I tier on complexity of use. Each plan up the ladder should match a customer whose problem got more complex, so the plan names themselves tell the story: Free → Starter → Business → Enterprise.
At Amplitude we broke the model into three parts. Scale is what you monetize on (events). Amount is how much you charge. Timing is when you charge. The free Starter plan capped at 10M events with basic analytics, and every plan above it anchored on that same event metric plus more advanced features. So you get one usage metric and one feature metric working together.YouTube
Then, for every feature, decide whether it goes free or paid:
- Commodity features (storage, notes, video calls) go free. Your competitors give them away, so you can't charge for them.
- Features that drive retention or virality lean free, because gating them slows down the growth loop.
- Exception: high-complexity or niche features can sit behind the paywall even when they're viral. Miro gives you unlimited users on free but charges for external sharing, because collaborating outside your org is a more complex use case.
A few lessons I learned the hard way:
Most companies end up with 3-5 plans, but showing the enterprise plan everywhere backfires. In emerging markets, the big enterprise numbers create pricing anxiety, and your entry plan starts to feel expensive too. Simplify plans by region.
elenaverna
Your packaging will be wrong, so build for iteration. At Lovable, in year one of credit-based pricing, we launched a team plan and then killed it. We also made collaboration free with unlimited users, added a business plan, shipped credit rollovers, and moved to local currency in the EU and GB. We run on Stripe Billing, so packaging changes ship in days. At older SaaS companies I watched simple changes take six months because of homegrown billing.elenaverna
Use pricing page conversion as your scorecard. At least 15% of pricing page visitors should click through to checkout.elenaverna
P.S. Paywalls on teamwork? Nah. Gate complexity and keep collaboration free.
Alvaro MoralesCo-founder and CEO of Orb. Former Engineering Manager at Asana
Japna's point that the tiers do two jobs, self-serve at the bottom and a sales trigger at the top, shows up in how the usage limits are built. Most packaging I see now is hybrid. A seats-plus-consumption model, or usage limits inside feature tiers, gives the self-serve buyer a predictable entry price and gives sales a natural upsell moment when a team hits the limit.Spotify
Teams underinvest in what happens past the limit. Overage design decides whether hitting a cap feels like a penalty or an upgrade path. Punitive overages, at-cost overages, upfront prepay discounts and volume discount curves all change retention and expansion differently, so each needs its own experiment. Renaming "overages" to "on-demand spend" works surprisingly well, and prepaid credits are a good fit for AI products.
X
New capabilities such as AI can usually be folded into the tiers you already have. You can add AI only to premium tiers, which pulls lower-tier customers up and keeps current premium customers happy because they got a free upgrade. You can also reserve AI for enterprise and charge a separate fee, or use it as a lever in renewal negotiations.
LinkedIn The catch is cost. When every inference costs real compute, a flat feature unlock in a fixed-price tier can lose money on your heaviest users, so pair it with a usage cap.
Bundles have a similar trap. Teams often present a bundle only as a discount, which teaches buyers that the separate products are overpriced. Present the bundle as a complete workflow and tie its price to the same value metric as the tiers.Spotify
Japna SethiDirector of Product at Atlassian. Former Head of Product-led Growth at Productboard
Elena's "keep collaboration free" rule matches how I think about team products. When someone asked me whether a referral program made sense for a team meeting product, my answer was to look at invite and expansion loops first. Referral incentives work for a while and then plateau. Dropbox's space race gave you 2 GB for every referral, lots of people did it, and then it flattened out. An invite that comes from real collaboration keeps working because the product itself is generating it, which is why I'd keep that invite path out of the paywall.YouTube
On speed, I agree with Elena's point about billing and want to separate two speeds. Shipping a packaging change in days is great. Judging it in days is a mistake. Free-to-paid conversion and expansion take months to play out, so a team that can ship weekly needs to be disciplined about holding each change long enough to read it. If you change the free plan limit, the new paid tier and the pricing page in the same month, you can't tell which one moved the number.
I'd also add a sales check to the feature sorting. Before you move a feature into a higher tier, ask the sales team which deals it shows up in. A feature that enterprise reps already use to close deals belongs at the top. If self-serve users hit it in their first week, gating it slows activation and costs you the PQLs that sales would have gotten later.
Alvaro MoralesCo-founder and CEO of Orb. Former Engineering Manager at Asana
Japna's two-speeds point is why we built versions and migrations at Orb. A packaging change ships as a new plan version to new signups first, while existing customers stay on the old version until you decide to migrate them. That gives you a clean cohort to read over a full conversion and expansion cycle, and you can still move the installed base later without rebuilding invoices by hand.YouTube
The other gap I see in tier design is usage visibility at the top of the ladder. A $20/month self-serve customer often gets a live usage portal, while a $2M/year enterprise customer gets a quarterly CSM meeting with an Excel file. The customers paying the most get the worst view of what they're paying for. Show every tier its usage clearly, including enterprise. The renewal conversation then starts from data both sides already trust, and buyers are running that over-utilized or overpaying analysis themselves anyway.YouTube
Timing matters too. If your biggest risk is whether anyone will pay, design partners who pay you very little won't tell you much. Test willingness to pay before you write the product code.YouTube
Kyle PoyarFounder of Growth Unhinged. Former Operating Partner at OpenView
Start with Good-Better-Best and only move off it if you have a strong reason.
About two-thirds of SaaS companies end up there (Salesforce, Figma, Airtable, Slack, Notion). One-size-fits-all leaves you with no upsell path (think the classic Bloomberg Terminal). Build-your-own à la Twilio causes decision paralysis, and it hands procurement more line items to pick apart in a discount negotiation.
Substack
Here's how I'd sequence the work:
1️⃣ Value metric first. I agree with Alvaro on the order. For PLG limits specifically, gate outputs and leave inputs open. SurveyMonkey caps the responses you can see while the survey keeps running, so there's always a clear path to more value for more money.
mucker
2️⃣ Tier by customer sophistication and willingness to pay. Each step up should map to a customer who has gone deeper into the product. That gives sales an easy story and gives new products somewhere to get monetized.
3️⃣ Be picky about add-ons. A feature belongs outside the tiers when:
- it's polarizing (a few customers love it, the average one doesn't need it)
- it taps a different buyer or budget
- customers already pay another vendor for it
- adoption usually comes 6-12+ months after the initial purchase
- it carries real cost to serve
The average customer shouldn't need more than one or two add-ons at the initial purchase.
4️⃣ Check that seats still track value. Alvaro covered AI cost. The revenue side worries me just as much. In my look at 40 AI apps, 70% ran on subscriptions and most charged per user. If those apps work as advertised, they need fewer seats per customer, so revenue shrinks as they add more value.
TL;DR: get the value metric right, then let Good-Better-Best and a short list of add-ons do the packaging work.
Japna SethiDirector of Product at Atlassian. Former Head of Product-led Growth at Productboard
Versioning plans for new signups is the right default, and the migration of existing customers still needs its own launch plan. At Dropbox I led the GTM launch for a new revision of the Plus SKU, and moving the installed base took comms, support readiness and a clear story about what customers got for the change, on top of the billing work.
Channel is a packaging constraint people forget. Mobile plans at Dropbox ran through App Store and Play Store billing, so before we could change mobile Plus and Professional plans or support people moving between plans, we had to refactor the back end and build a new API to integrate with both stores. If a meaningful share of your revenue comes through app stores or a marketplace, check what those channels let you do with upgrades, downgrades and plan transitions before you lock a tier design. A tier structure that works on web and can't be expressed on mobile ends up as two different products with two different prices, and customers notice.
Alvaro MoralesCo-founder and CEO of Orb. Former Engineering Manager at Asana
I agree with Kyle on seat compression, and I'd treat it as a reason to change what the top tiers meter. In Orb's 2025 State of AI Agent Pricing report, which covered 66 companies, 92% combined multiple pricing components. In practice that usually means seats stay as the access fee and usage or completed work becomes the metric that grows with value. When an agent replaces work a person used to do, the seat count falls but the usage metric keeps rising.
A lot of pricing experimentation right now is about whether packaging can move closer to outcomes the customer can see. Buyers are used to paying for outcomes when they pay for labor, and agentic software is starting to deliver that kind of result.YouTube Outcome pricing only works when both sides can measure the outcome and agree on it. If you can't define a resolved ticket or a qualified lead in a way that holds up on an invoice, you'll spend more on disputes than you gain in value capture.
Nobody knows yet exactly where this lands, so build it as a hybrid that you can reweight.Spotify Keep the seat component, add the usage component inside Good-Better-Best, and shift weight between the two as your data shows which one tracks value.
Question:
Lauryn, Kyle says a feature belongs in an add-on when it's polarizing, reaches a different buyer, gets adopted 6-12 months after purchase, or has real cost to serve, and he names Notion and Airtable as Good-Better-Best examples. Alvaro suggests putting AI into premium tiers to pull customers up. From your Notion and Airtable work, how do you decide between an add-on and bundling a capability into a tier, and what happened to upgrades after that choice?
Elena VernaLeads growth at Lovable. Former SVP Growth at SurveyMonkey
I'd push back on Alvaro's option of putting AI only in premium tiers. A lot of products are locking every AI feature behind a paywall like it's 2014 SaaS again, and in a new category that kills conversion. Most people don't wake up wanting a multi-agent workflow. They wake up wanting coffee. You can't explain AI value on a pricing page, so people have to feel it first. That's why I think freemium in AI is the most rational irrational strategy we've got.elenaverna
Alvaro is right that cost is real, though. The zero marginal cost era of software ends the minute you touch LLM APIs, and a user writing a novel costs you far more than one asking for a pumpkin soup recipe.elenaverna So in packaging terms: give AI to every tier, cap it by usage, and let the cap be the upgrade trigger. Don't hide AI behind a feature wall in premium.
Credits are how most of us handle that cap today, Lovable included. I openly hate them. Credits are an abstraction customers have to translate back into value, and that adds friction at the exact moment you want them to upgrade. But they're a necessary evil for now, because they stop usage costs from spiking out of control.elenaverna If you go with credits, make them less punishing. That's why we shipped credit rollovers at Lovable and are testing top-ups.
One more lever for tiers: reverse trial your free base on a schedule. Every six months, or with each big launch, give everyone the full paid plan for 30 days. Tesla did this with Autopilot and got a ton of upgrades. When someone hits a feature wall, unlock the whole paid tier, not only the feature they bumped into.elenaverna
Kyle PoyarFounder of Growth Unhinged. Former Operating Partner at OpenView
Every iteration tactic in this thread, from Alvaro's plan versions to Japna's launch plans for migrations to Elena's shipping changes in days, assumes somebody owns pricing. Usually nobody does.
From my 2025 State of B2B Monetization data:
- <$1M ARR: the founder/CEO owns pricing 71% of the time
- $1-5M ARR: still the founder/CEO (69%), with an assist from sales
- $5-20M ARR: it's a hot potato between the founder/CEO (38%), product (18%) and sales (12%), and 21% say nobody owns it
- $20-150M ARR: it moves to product (43%) and becomes a team sport with sales, marketing and finance
That $5-20M band is where I see packaging go sideways. Tiers pile up because each team tacks on a SKU for its own launch, and nobody stays around for the full conversion and expansion cycle Japna described.
So before you redesign tiers, I'd do two things:
1️⃣ Name one owner whose job is to collect data on costs, competitors and customer value. That person runs the versioning cadence and decides when a change has been measured long enough.
2️⃣ Bring finance and ops in early. Alvaro's point about compute cost in fixed-price tiers belongs here. Finance should model what your heaviest users of a new AI feature cost to serve before you decide which tier gets it. My data also shows AI spend mostly comes out of the same tech budget as SaaS (70% of respondents said so), so your new AI tier is competing with your existing tiers for the same dollars.
Japna SethiDirector of Product at Atlassian. Former Head of Product-led Growth at Productboard
Kyle's single owner works early, and past that $5-20M band I'd split ownership by stage of the customer journey. When I was interim Head of Monetization at Otter.ai, the first thing I built was a monetization strategy and roadmap, and I ran monetization and expansion as two teams. Monetization owned the free-to-paid step: plan limits, the paywall, the pricing page. Expansion owned what happens after the first purchase: seat growth, tier upgrades, add-ons. Splitting them that way gave Kyle's add-on criteria and Alvaro's overage design a clear home, because each one sits on a specific team's metric. It also stopped the SKU pile-up Kyle describes, because a new tier or add-on had to fit one of the two roadmaps with a hypothesis attached before it shipped.
Alvaro MoralesCo-founder and CEO of Orb. Former Engineering Manager at Asana
Elena's version is closer to what I'd recommend for a product where AI is the core value. It matches the pattern from my first answer: open every feature on the first paid tier and cap usage, so buyers see the whole product before they commit.Spotify Premium-only AI fits a narrower case, an established product where AI improves a workflow customers already pay for and the inference cost per account is small next to the tier price.LinkedIn
I'm less down on credits than Elena. Customers mostly react to how a credit system is presented. Calling usage past the cap "on-demand spend" instead of "overages" works surprisingly well, and prepaid credits give the buyer the budget predictability a CFO or procurement team asks for.X Credits cause the friction Elena describes when nobody can translate a credit back into work done, so show it in units the customer recognizes, like messages, builds or minutes.
Japna SethiDirector of Product at Atlassian. Former Head of Product-led Growth at Productboard
Elena's reverse trial fits the two-jobs idea from the start of this thread. At Productboard the free trial was our largest source of product-qualified leads. We activated trial users on a few key features, qualified them on firmographic and usage data, and routed the strong ones to sales with context on their use case.YouTube So when you schedule a reverse trial, decide up front which in-trial behaviors count as a PQL and what sales gets told about them. Otherwise the 30-day unlock produces a spike in upgrades on the self-serve side and leaves the larger deals on the table.
Kyle PoyarFounder of Growth Unhinged. Former Operating Partner at OpenView
Alvaro and Elena now agree on capped AI in every tier, and my data from 40 AI apps backs that up: 50% had a free plan and another 20% offered a free trial. AI apps usually have a fast time to value, and people need to try them before they believe the pitch.
So I'd use the add-on criteria to decide what gets sold separately, and keep a usage-capped taste of AI in every tier. An AI capability earns add-on status when it pulls in a different budget, for example an agent that replaces services or headcount spend. That matters because 70% of companies told me AI spend currently comes out of the same tech budget as SaaS. If your AI feature only competes for the existing software line item, bundling it into tiers with a usage cap is the cleaner choice.
Elena VernaLeads growth at Lovable. Former SVP Growth at SurveyMonkey
Japna splits ownership by journey stage. I split it by type of decision, because one owner for everything turns every paywall copy tweak into a committee meeting.
Lane one covers optimizations that touch how customers interact with the model: pricing page redesigns, in-app upgrade prompts, reverse trials, defaulting to yearly billing, adding payment methods and currencies, and targeted discounts for students or at-risk customers. Growth and product teams should own those outright and ship them without approval, the same way they ship any other product change.
Lane two covers model changes: price points, the value metric, the number and names of plans (freemium included), which features go in each package, usage limits and add-ons. Those go to a monetization council with product, growth, sales and finance at the table. PMM or strategy teams often volunteer to own this, but they don't carry revenue targets, so they produce a nice deck and sales and product get stuck executing it.elenaverna
On Japna's and Alvaro's migration point, I land on the aggressive side. Engineering will push you to clean up legacy SKUs because every one adds maintenance and QA. Once a new price is validated, move everyone onto it, and make the move benefit the customer. Customers paying more than the new price get upgraded to a higher plan instead of a refund conversation. Grandfathering forever is how you end up with 40 SKUs that nobody can reason about.
Lauryn MotamediFormer VP Growth and Product at Notion and Head of Growth at Airtable
I can't put upgrade numbers from Notion or Airtable on the table here, so I'll give you the test I use and the Airtable evidence behind it. I decide by where the capability sits in a new user's journey. If people need it to reach their aha moment and form a habit, it goes in a tier, and new users should get to try it. If it gets adopted months after purchase or by a different buyer, Kyle's add-on criteria fit well.
The reason is activation. Overhauling Airtable's onboarding lifted activation by 20%, and so much downstream flows from that first experience: converting to paid, closing a deal, spreading across an org.
lennysnewsletter A separate SKU puts an extra purchase decision in front of a new user before they have found value.
The reverse trial is how a tiered capability earns the upgrade at Airtable. A new user starts on the premium plan for 7, 14 or 30 days, uses the advanced features, then either pays or drops to free-forever. That only works if the capability lives in the premium tier. An add-on sits outside what the trial shows unless you build a separate trial for it. Elena's idea of rerunning the reverse trial for the whole free base after big launches gets the same benefit for existing users.YouTube
Either way, the packaging decision will leak into onboarding, and you have to guard against that. If a paid capability correlates with conversion, teams get tempted to push it on day one. At Airtable, automations were the example: a tooltip naming the feature doesn't help someone who doesn't yet know whether it fits their use case. The same risk applies to AI today. Teach users what they need first and let the upgrade follow the value they find.YouTube
So for AI I land with the group on a capped amount in every tier, because my test says new users need to feel it during onboarding to activate.
Alvaro MoralesCo-founder and CEO of Orb. Former Engineering Manager at Asana
I agree with Elena on migrating, and that's why Orb's feature is called versions and migrations. Versioning to new signups gives you a clean cohort to measure. Once the new price is validated, you migrate the installed base so you don't accumulate legacy SKUs.YouTube Most teams grandfather forever because a migration on homegrown billing means hand-editing contracts and invoices, so they avoid it. When moving customers is a scheduled plan change, teams actually do it.
On Elena's lane two, a council can only decide on the value metric or usage limits if product teams have already sent usage in a shared data schema before the feature ships.YouTube Without that data, the council is guessing at what the heaviest users cost and use.
Ask a follow-up
+2Pricing
Ask Pricing anything...
Frequently Asked Questions
How should a consultant or agency price its services?
By the shape of the work: a fixed fee for a defined deliverable, a retainer for ongoing access, prepaid units for variable requests. Add a performance fee only once the metric, baseline and client duties are agreed.
How does a young startup or community choose a business model?
Find the behavior that creates value and charge where it does the least damage to it. Test a small paid offer with real buyers, then check they keep paying after the first purchase.
Should a transaction fee be flat or a percentage?
Flat when the work and value per transaction are about the same, a percentage when value or risk grows with order size, and volume tiers when each extra transaction is worth less.
How do you present a pricing change to executives?
Open with the decision, show each account's price change next to its health, and ask for a staged test with a return date and stop rules agreed in advance.
How do you break down a competitor's pricing?
List each plan's model, value metric and upgrade triggers, use the product yourself, then work out where the revenue sits and whether a high price pays for sales or is margin.
How should AI features and agents be priced?
Bill for a unit customers can verify, such as a resolved ticket, check it against the cost of heavy users, and let people finish a real task before they pay.
How do you move existing customers to a new pricing model?
Simulate each account's first bill, test the model on new buyers, then move existing customers in cohorts with notice, a fallback plan and a migration date that respects renewals.
How long should a free trial be?
Long enough for retained customers to reach the paid value. For a simple self-serve product, start with 14 days as a test, then compare 14 and 30 days on revenue and retention at the same cohort age.
What makes people pay at a paywall?
A wall that stops them partway through a job they care about, a limit on the unit they value, an offer that fits their usage, and copy and checkout that don't leak buyers.
