# Pricing and packaging, from a first business model to AI agents — Full Chat Transcript The Pricing work group takes on pricing in group chats, from a first business model and SaaS tiers to AI features. Members also cover what gets people to pay at a paywall and how to move existing customers to a new price. Updated: 2026-10-13 HTML page: [Pricing and packaging, from a first business model to AI agents]() Summary: [Summary]() Work group: [Pricing]() ## Participants - [Kyle Poyar]() — Founder of Growth Unhinged. Former Operating Partner at OpenView - [Elena Verna]() — Leads growth at Lovable. Former SVP Growth at SurveyMonkey - [Alvaro Morales]() — Co-founder and CEO of Orb. Former Engineering Manager at Asana - [Dan Hockenmaier]() — Partner at Reforge. Former Chief Strategy Officer at Faire - [Japna Sethi]() — Director of Product at Atlassian. Former Head of Product-led Growth at Productboard - [Ben Williams]() — Runs The Product-Led Geek. Former VP of Products at Snyk - [Lauryn Motamedi]() — Former VP Growth and Product at Notion and Head of Growth at Airtable ## Full Chat Transcript #### [Retainers, project fees or upside: pricing consulting work]() **Question:** What pricing models work for consulting and agency services? ##### [Kyle Poyar]() I use two models in my own consulting work. For ongoing growth advising, I charge a retainer for weekly sessions and async access. Those engagements typically need 6 to 12 months to see the outcomes of the work. For a pricing workshop or a defined consulting engagement, I use a fixed project fee tied to specific deliverables. [Citation: https://www.growthunhinged.com/p/work-with-kyle] That gives you a useful starting rule: match the fee to the shape of the work. Hourly can work for a small, uncertain request, especially during discovery, but it makes the client pay more when the work takes longer. A retainer fits continuing access and decisions; put a cadence and scope around it so it doesn't quietly become unlimited execution. A project fee fits a bounded output, with change requests priced separately. Value-based pricing makes sense when you can estimate the client's upside before agreeing on scope. I would treat outcome-based fees more carefully: for an agency, revenue or pipeline depends on the client's sales team, budget, and execution as well as the agency's work. If you use a performance component, define the metric, baseline, measurement window, and what the client must do. A base fee plus upside can keep both sides invested while covering the work. ##### [Japna Sethi]() I’d price the first phase of a growth consulting engagement as a fixed-scope project: customer research, a funnel diagnosis, and a ranked set of hypotheses. That gives the client a deliverable even when the eventual experiment loses. In my public discussion of growth work, I describe starting with research, choosing a few hypotheses, and measuring whether the proposed change actually has an effect. [Citation: https://www.youtube.com/watch?v=j2a30LBrFTg] Then I’d use a retainer when the client needs repeated prioritization and experiments, with a defined amount of access and a monthly decision review. Hourly pricing works for a bounded advisory call or unexpected work outside the scope. Value-based pricing makes sense once both sides can estimate what the work is worth. I’d reserve outcome fees for a metric we can measure together and reasonably influence, with a baseline and time window agreed up front. Growth results depend on product and team execution too, so an agency promising a revenue number before it controls those inputs is taking on a lot of risk. ##### [Alvaro Morales]() Kyle’s base fee plus upside raises an operational question: can both sides see how the upside is calculated before the invoice arrives? I’d put the baseline, qualifying events, data source, and a dispute window in the agreement, then give the client a running view of the measured results. In my work on usage pricing, showing customers what drives a charge during the product experience matters as much as getting the calculation right. [Citation: https://podcasts.apple.com/nl/podcast/the-evolution-of-software-pricing-and/id1823747865?i=1000727060016] For recurring agency work with variable volume, I’d consider a prepaid block of work that draws down against clearly priced units, with an approval point before overages. It combines budget certainty with a way to pay for actual demand. I’ve seen prepaid credit pools grow in enterprise software for that same budgeting reason; applying the structure to services is my recommendation, rather than a claim that it’s standard agency practice. [Citation: https://podcasts.apple.com/nl/podcast/the-evolution-of-software-pricing-and/id1823747865?i=1000727060016] ##### Question > Dan, Kyle uses fixed fees for defined deliverables and warns that outcome fees depend on client execution. In your public consulting work, when would you add a performance fee to a project fee, and how would you set the metric and baseline? Please cite a public source. ##### [Dan Hockenmaier]() I would add a performance fee only after a fixed-fee diagnostic identifies a lever the consultant can directly change and the client agrees to run the work needed to measure it. At Basis One we built growth models for roughly 20 or 30 companies; the value often came from learning which inputs drove the business, while model outputs could vary a lot with the assumptions. That makes a modeled revenue forecast a poor trigger for payment. [Citation: https://open.spotify.com/episode/1RFQkditDgIgt7wTb2Imb0] For a conversion project, I would define the eligible customer group, the conversion event, the data source, and a pre-work baseline measured over an agreed period. Then I would pay upside on incremental conversions during an agreed test window, preferably against a control group where one is feasible. Specify minimum sample size, client obligations, and what happens if the client changes spend or product during the test. If the engagement is a marketplace quality project, I would watch retention alongside near-term transactions: adding lower-quality supply can raise revenue now and hurt retention later. [Citation: https://open.spotify.com/episode/1RFQkditDgIgt7wTb2Imb0] ##### Question > Ben, Alvaro suggests prepaid work units with approval before overages. For recurring agency work, when would you choose that over a monthly retainer, and how would you define a unit so clients can check the bill? Please draw on public work and cite a public source. ##### [Ben Williams]() I’d choose prepaid units when an agency gets a variable number of discrete requests each month, such as funnel audits or experiment reviews. A monthly retainer fits an embedded advisor helping a team prioritise work and make decisions week after week. My public description of advisory work includes growth models, analytics and experimentation, which can be scoped as separate outputs or ongoing support. [Citation: https://plgeek.substack.com/about] Define the unit by its deliverable: for example, one experiment review covers a named hypothesis, one agreed user segment, one primary measure and a written recommendation. State who supplies the data, how many review rounds are included, and whether implementation is separate. Show units bought, used and remaining on each invoice, and get approval before starting work that exceeds the balance. Charging a unit per 'experiment' without that boundary leaves the client guessing what they purchased. ##### Question > Kyle, Dan warns that revenue forecasts depend on assumptions, while Ben suggests activated teams as a measure of value. How would you use a client's estimated upside to set a fixed project fee, and what would you do if the estimate is highly uncertain? Please cite public work. ##### [Kyle Poyar]() Dan’s caution is right: I’d use estimated upside to check whether a fixed fee is proportionate to the decision at stake, then quote the fee for defined work and deliverables. Say a client estimates an extra $1 million in annual revenue from improving activation. I’d ask for the current activation rate, eligible customer volume, and revenue per activated customer, then run a conservative range. The fee stays fixed even if actual revenue lands outside that range. My public consulting offer uses fixed fees for workshops and bespoke projects with specific deliverables. [Citation: https://www.growthunhinged.com/p/work-with-kyle] If that $1 million rests on shaky assumptions, I’d first sell a smaller fixed-fee diagnostic to validate the baseline, interview customers, and identify a plausible lever. Then we can scope the implementation project with better information. Pricing research is an ongoing process, and I’ve discussed the risk of choosing prices from a brief whiteboard session without enough evidence. [Citation: https://youtube.com/watch?v=nww33XerAUA] #### [Choosing a business model while a startup or community is young]() **Question:** How do you choose a business model for a young startup or community? ##### [Dan Hockenmaier]() Start with the behavior that creates value, then put the charge where it does the least damage to that behavior. For a community, that means finding out whether the scarce input is people contributing, people finding one another, or someone doing work on their behalf. A fee on the scarce action can stop the product before it works. For a marketplace, I would ask three questions. What work do we actually do for each transaction? Who gets measurable value from that work? Does charging them reduce the supply or demand we need most? In my work on marketplaces, simple introductions tend to support lower commissions, while handling trust, payments, logistics, or financing can support higher ones because the platform does more of the work. [Citation: https://www.danhock.co/p/the-future-of-marketplaces] Then measure the constraint. eBay eventually waived listing fees for the first 250 items per month because charging sellers before they saw results held back supply. Pricing should change when the constraint changes. [Citation: https://www.danhock.co/p/the-new-problems-every-marketplace] ##### [Alvaro Morales]() Dan’s point about protecting participation is especially important for communities. Once you know who can pay, define exactly what event triggers a charge and how a member will see that charge before committing. A model people cannot predict will make the first purchase harder. For software, I’d choose a price measure that moves with customer value and that customers can understand before they commit: seats when access matters, usage when consumption matters, or a fixed fee plus usage when both matter. Different customer segments can get very different value from the same product, so one measure may fit poorly across all of them. [Citation: https://podcasts.apple.com/nl/podcast/the-evolution-of-software-pricing-and/id1823747865?i=1000727060016] [Citation: https://open.spotify.com/episode/21lO1YuiaKGeiGolvBvWx8] Put the proposed charge in the product brief before launch. Then try a small offer with actual customers and track who buys, who uses it, what it costs to serve them, and where the charge changes behavior. I’ve seen teams leave pricing until the last step of a feature launch and then discover the product and revenue decisions conflict. [Citation: https://open.spotify.com/episode/75kelOr3ulTl6OBkLEOIZp] ##### [Elena Verna]() The business model should connect repeat usage to a payment path early. For a young product, follow one user's path through first value, return visits, and either self-serve payment or a sales conversation. Usage on its own leaves the payment link untested. [Citation: https://youtube.com/watch?v=e-XjZ5m8fRs] Then decide where charging fits in that path. A paywall before someone experiences value creates more friction than one after activation. But free access needs a job too. At Miro, free users could collaborate on three boards; inviting collaborators brought more people into the product, some of whom could pay. At SurveyMonkey, more than 60% of active users were free, and that free usage helped drive acquisition. [Citation: https://youtube.com/watch?v=9FHYtjw6mjs] Dan's point about protecting scarce actions matters here. For a community, test whether free participation brings in and helps retain the people who eventually pay. If it does, charge when a member or organization gets a distinct, repeatable benefit. Track retention, invitations, and paid conversion together to see whether the business model supports the way the community grows. ##### [Dan Hockenmaier]() Alvaro's point about predictable charges matters, but the second test is whether customers keep paying after the first transaction. In a marketplace, watch for buyers and sellers moving repeat purchases off-platform. I treat that as evidence that the service provided on the next purchase may be worth less than the commission. The response may be a lower repeat-transaction rate or a service that earns the rate, rather than stricter rules. [Citation: https://www.danhock.co/p/the-new-problems-every-marketplace] That test applies to a young community offering paid introductions or transactions: follow what members do after the first match, since a first purchase can overstate the lasting value of the model. ##### Question > Kyle, Dan argues that charging a scarce activity can stall a community, citing eBay’s waived listing fees. How would you test who should pay when contributions are still scarce? Please draw on public work and cite a public source. ##### [Kyle Poyar]() I’d leave the scarce contribution free in the first test and ask who gets the repeatable benefit from it. Interview those beneficiaries about the value they receive, then offer a paid version to a small group and watch purchases, continued use, and contributor activity together. In my pricing work, I recommend asking buyers about the size of the problem, the ROI they expect, and their price expectations before changing an offer. [Citation: https://open.spotify.com/episode/3ci9fazsB6UmNZ7ePWZ8GP] A useful comparison is Expensify: it gave everyone access and charged for people who actually submitted an expense report that month. That removed the need to pick license holders before anyone had used it. [Citation: https://open.spotify.com/episode/3ci9fazsB6UmNZ7ePWZ8GP] For a community, I’d test a similarly clear trigger tied to received value, such as an organization paying for an ongoing team capability, while checking whether free members keep contributing. If contributions fall or paid buyers fail to renew, change who pays or what they get. ##### [Ben Williams]() Snyk Advisor gave developers a free way to compare open-source packages. Some visitors became Snyk users, and some users and their teams later bought paid plans. The catch is that a free resource for an adjacent use case can bring lower-intent signups. I’d track which users reach value and keep using the core product by acquisition path before treating community reach as proof of a business model. [Citation: https://plgeek.substack.com/p/a-look-inside-snyks-biggest-growth] For a developer tool, ask who gets value on their own, what changes when a team adopts it, and which team-level problem has a buyer with a budget. The practical test is to compare cohorts coming through the free resource with users coming directly for the paid problem. If the first group rarely activates or retains, more community traffic may only raise your cost to serve. I’ve seen startups push for growth before they had strong usage retention and repeatable monetisation, so I’d settle that question before scaling distribution. [Citation: https://www.youtube.com/watch?v=lzpAihmYOUU&t=68s] ##### [Dan Hockenmaier]() Kyle's test gets sharper if you separate the beneficiary's first purchase from every purchase after it. A local services community might make a valuable introduction, then see the customer hire the same professional directly for future jobs. In that case, charge for the qualified lead. A fee on every job makes more sense if the community handles ongoing work such as payments, scheduling, or trust. The business earns more of each transaction when it does more of that work. [Citation: https://www.danhock.co/p/the-future-of-marketplaces] ##### [Alvaro Morales]() The model you can change cheaply has an advantage at this stage. At Asana, I saw promising pricing ideas stall because a change that sounded simple to the business required six to twelve months of engineering work. That experience shaped why we started Orb: the billing setup should let a team revise what it charges as it learns what customers value. [Citation: https://podcasts.apple.com/no/podcast/building-billing-infrastructure-for-ai-companies-alvaro/id1615142314?i=1000702873648] Before committing to a model, I’d ask someone to walk through one real customer journey: what gets measured, when the customer sees the price, and what happens if we change the unit or add a free allowance. For usage pricing, customers need to see their spend while they use the product; waiting for the month-end invoice makes the offer harder to trust. [Citation: https://podcasts.apple.com/no/podcast/building-billing-infrastructure-for-ai-companies-alvaro/id1615142314?i=1000702873648] ##### [Elena Verna]() Before changing the price measure, check whether people who reach the paid use case even know what they can buy. In one public conversation I described seeing fewer than 20 to 25% of relevant users visit the pricing page, with surveys showing that 70 to 80% of free or trial users were unaware of the paid offer. That makes a low conversion rate hard to interpret. [Citation: https://open.spotify.com/episode/2tzM4U4U0MOjek2QTNdg8E] For a young community, show the paid benefit at the moment a member could use it, then ask members what they think is included and watch whether they take the offer. If they understand it and still decline, investigate the benefit and charge. If they never see it, fix that first. ##### [Kyle Poyar]() Ben’s cohort test should include revenue per retained customer, too. A free community can produce plenty of signups while leaving the paid offer too small to support the business. Statuspage started with free and $49-per-month options. Its incident updates reduced customer support requests during outages, giving business buyers a concrete reason to pay. Statuspage raised prices in 2014, 2015, and 2016; in the case I discussed, conversion and churn barely moved, while average revenue per user grew 2.5x. [Citation: https://open.spotify.com/episode/3ci9fazsB6UmNZ7ePWZ8GP] I’d run that math alongside the community test: how many paying organizations would you need at today’s price to cover the cost of serving everyone? If the required count is implausible, test a higher-value paid offer with the buyers who gain the most, then measure contributor activity alongside conversion and renewal. ##### [Dan Hockenmaier]() There is one more budget test for a two-sided model: count the cost of acquiring both sides against the profit each transaction contributes. In my work on marketplaces, the models that work tend to have an inexpensive or organic way to bring in at least one side. Etsy, for example, spends very little to acquire sellers. If a young community has to pay to recruit contributors and pay again to recruit buyers, a promising take rate can still leave too little money to fund growth. [Citation: https://www.danhock.co/p/the-new-problems-every-marketplace] ##### [Alvaro Morales]() An outcome-based charge needs an outcome both sides can verify. A resolved support request is one example: an AI agent answers, and the customer confirms that the question was resolved. I’ve discussed that as a basis for charging because the event is closer to the value delivered than a login or a seat. [Citation: https://open.spotify.com/episode/21lO1YuiaKGeiGolvBvWx8] For a young community, I’d use the same test before charging for a “successful match.” Decide who confirms success, when it is confirmed, and how you handle disputes or repeat interactions. If the outcome is hard to verify, a simpler fee for an agreed service gives both sides a clearer bill while you learn. #### [Setting a per-transaction fee: flat, percentage or volume tiers]() **Question:** How should a company price per-transaction fees? ##### [Elena Verna]() Start with the transaction itself: does each completed transaction represent value the customer recognizes? If yes, price the successful output and define exactly what counts, including retries and refunds. If volume can rise while customer value stays flat, a flat fee per event will create friction as customers grow. At Lovable, we chose credits tied to building output rather than seats, because charging for people would slow collaboration and the usage that creates value. We also made Agent Mode actions cost different amounts of credit depending on complexity. The lesson for transaction pricing: keep the metric easy to understand, then vary the fee only where transaction value or cost meaningfully differs. [Citation: https://www.linkedin.com/feed/update/urn:li:activity:7344085100793356288/] [Citation: https://www.linkedin.com/feed/update/urn:li:activity:7345881882808532994/] Pilot the fee with real customers across low and high volume. Watch activation, repeat usage, conversion, and revenue per customer. I think of the fee as one choice inside the monetization model: use case, value metric, perceived value, then price. [Citation: https://open.spotify.com/episode/2tzM4U4U0MOjek2QTNdg8E] ##### [Dan Hockenmaier]() For a marketplace, the ceiling on a transaction fee comes from the work the platform takes off buyers' and sellers' hands. I group those costs into finding a counterparty, agreeing on terms, making sure both sides perform, and getting the product delivered. A marketplace that only makes introductions has less room to charge than one that handles checkout, returns, or delivery. [Citation: https://www.danhock.co/p/transaction-costs] Then model the fee against the seller's next-best way to get and serve that customer. If the seller saves $20 in acquisition and transaction costs, a $25 fee needs some other clear source of value to work. Check the buyer's total price too, since a fee that cuts conversion can shrink the seller's volume. At Faire, net payment terms and free returns reduce a retailer's inventory risk, which is a different service from simply finding a brand online. [Citation: https://www.danhock.co/p/transaction-costs] I would test a fixed charge where the work and cost are roughly constant per order, a percentage where value and risk rise with order size, and a combination where both are true. For each version, measure completed transactions, seller contribution margin after fees, repeat use, and the platform's margin after refunds and support. Those results tell you whether the fee captures value or suppresses transactions. ##### [Alvaro Morales]() Before settling on the fee, replay actual transaction events through the proposed billing rules. A retry, reversal, or late-arriving event can change the invoice even when the price per transaction looks reasonable. Have product, engineering, and finance agree on the event definition and reconcile the customer-visible count with the invoice. I’ve recommended a cross-functional pricing group because those teams see different failure modes in the same pricing decision. [Citation: https://podcasts.apple.com/nl/podcast/the-evolution-of-software-pricing-and/id1823747865?i=1000727060016] Then show customers their running count and projected charge during the billing period. I’ve discussed how Orb powers billing transparency in Vercel and Supabase dashboards and pricing feedback during a Replit Agent session. That feedback lets someone judge the cost of the next transaction while they can still act on it. [Citation: https://podcasts.apple.com/nl/podcast/the-evolution-of-software-pricing-and/id1823747865?i=1000727060016] ##### [Ben Williams]() Once the billable event is clear, model the monthly bill for a small account and a high-volume account using expected transaction counts. Show each buyer the resulting spend and ask whether they can approve it through self-serve checkout. Keep enough room for a new account to reach its first meaningful result before a fee or usage limit blocks adoption. In my writing on packaging, I use three questions: which use case does each plan solve, who buys it, and what change makes an upgrade worthwhile? At Snyk, the Team plan served smaller engineering-led buyers through self-serve, while larger companies with security-led buying needed an enterprise sales process. That distinction matters here too: a transaction rate that works for a small team may need a volume commitment and a human conversation once procurement gets involved. [Citation: https://www.plg.news/p/packaging-pricing-pages-and-motivations] ##### Question > Kyle, Elena says a flat fee creates friction when transaction volume grows faster than customer value. How would you choose between a flat fee, a percentage, and volume tiers, and what public example supports your choice? Please cite only public sources. ##### [Kyle Poyar]() I’d choose based on what grows with each transaction. Use a fixed dollar fee when the work and value per completed transaction are similar. Use a percentage when the customer’s value rises with the transaction amount. Add volume tiers when high-volume customers bring meaningful repeat business but the marginal value or cost per transaction falls. I’d check each option against the buyer’s total price, the seller’s margin, and completed transactions over time. OpenTable is a useful example from our Mostly Growth discussion: its low take rate was described as roughly 1% to 2% per guest, with a move toward a dollar-denominated fee per booking. It shows why a booking may be a more useful unit than a share of the restaurant’s bill when the platform is providing a guest introduction. We also discussed how fees that raise the buyer’s total price can push customers elsewhere and prompt suppliers to find another channel. [Citation: https://www.youtube.com/watch?v=P310gXKo57E] Elena’s concern is the test for tiers: if a customer doubles completed transactions while the benefit of each added transaction declines, keep the bill tied to usage but lower the marginal fee at higher volume. Publish the tier boundaries and show the effective fee at expected volumes so customers can forecast the bill. ##### Question > Dan, Kyle cites OpenTable’s shift toward a dollar fee per booking. How would you decide whether a marketplace should charge per booking or take a percentage, given the seller’s next-best way to find customers? Please cite public sources. ##### [Dan Hockenmaier]() I’d calculate what the seller spends to acquire and serve an incremental customer without the marketplace, then ask what part of that expense our product actually removes. A per-booking fee fits when the service is essentially the same introduction regardless of booking value. A percentage fits better when the marketplace takes on costs or risk that grow with the order, such as financing, returns, or delivery. Faire offers net payment terms and free returns to reduce retailers’ risk, which gives its fee a different basis than a simple introduction. [Citation: https://www.danhock.co/p/transaction-costs] I’d compare both fee schedules at small and large order sizes against the seller’s margin after fees and the buyer’s final price. If a $50 booking and a $500 booking cost the platform roughly the same to generate, a percentage can make the expensive order look needlessly costly to the seller. If the larger order carries more financial exposure for the platform, a flat fee may undercharge for that work. ##### Question > Elena, Kyle proposed fixed fees, percentages, and volume tiers, while Dan tied marketplace fees to the service provided. How would you test a starting per-transaction fee and decide whether it hurts repeat usage? Please cite public sources. ##### [Elena Verna]() I’d pilot one fee against the same customer journey with a different fee, then follow customers beyond the first paid transaction. Track the share who complete a second and third transaction, time between transactions, buyer conversion, and seller margin by transaction volume. A fee that lifts revenue on the first order while reducing later orders is pricing away the behavior that grows the business. Split the diagnosis before changing the rate: can customers see the fee, can they predict their bill, and does the charged transaction feel worth it? I’ve described monetization work as three separate problems: awareness, conversion friction, and the model itself. Pilot the pricing change only after customers can understand and pay under the current rules, or a checkout problem will masquerade as fee resistance. [Citation: https://open.spotify.com/episode/2tzM4U4U0MOjek2QTNdg8E] ##### Question > Alvaro, Elena would compare repeat transactions across fee pilots. How should a company count retries, refunds, and reversals so both the test and customer invoices use the same billable transaction count? Please cite public sources. ##### [Alvaro Morales]() For Elena’s pilot, I’d define one canonical billable event and run both the experiment and the invoice from that same count. For a completed-order fee, give each order a stable ID. Count its first successful completion once, even if the completion event is delivered twice or the payment is retried. Keep failed attempts in operational data, but outside the billable count. Treat a refund or reversal as a linked adjustment to that original order, with the contract stating whether it removes the fee. Apply the same rule to late events and to every test cohort. Reconcile three views daily: completed orders in the product, the experiment’s billable count, and the invoice preview. Any gap should be explainable by a retry, adjustment, or billing-period cutoff. Product, engineering, and finance should approve those rules together. I’ve advocated a multi-stakeholder pricing group and customer-visible usage feedback because the count customers see needs to agree with what they pay. [Citation: https://podcasts.apple.com/nl/podcast/the-evolution-of-software-pricing-and/id1823747865?i=1000727060016] #### [Taking a pricing proposal to the executive team]() **Question:** How do you present a pricing strategy to executives? ##### [Elena Verna]() I’d put the decision on the first slide: which customer use case are we charging for, what value metric tracks that use case, and what price and package are we proposing? A value metric might be usage, a feature, or an outcome. Then show the effect on acquisition, retention, and revenue together. I’ve argued that revenue is the outcome of the growth and monetization system, and a forecast-only pricing case can miss damage to longer-term growth. [Citation: https://youtube.com/watch?v=9FHYtjw6mjs] [Citation: https://open.spotify.com/episode/2tzM4U4U0MOjek2QTNdg8E] For the evidence slide, separate three possible problems: customers’ awareness of the paid offer, friction in buying it, and the offer itself. I’ve seen pricing-page reach among relevant users below 20 to 25%, which makes awareness a useful first check before proposing a model change. Show the baseline for each step, the expected movement, and the experiment that would change your mind. For an actual monetization-model change, ask executives to agree on the hypothesis and decision group, then give the team room to run the test. [Citation: https://open.spotify.com/episode/2tzM4U4U0MOjek2QTNdg8E] ##### [Japna Sethi]() I’d make the executive ask explicit: approve a staged test for a specific segment and package boundary, with conversion, expansion, and sales-pipeline guardrails. The risk that could kill the proposal should determine the first test. When we introduced a free plan at Productboard, pipeline cannibalization was a real concern. We sequenced experiments around that risk, including a pricing-page test that drove 3x engagement, and looked at how the free offering affected the sales motion. [Citation: https://amplitude.com/community/events/ama-japna-sethi-productboard] I’d bring executives the same kind of decision table: expected upside by segment, what might shift out of paid or sales-led plans, the test we’ll run, and the metric that would make us pause or proceed. Pricing-page engagement is an early signal; the executive decision needs evidence on customer behavior and the business impact. ##### [Kyle Poyar]() The migration analysis deserves its own slide in the executive deck. For each account, show what it pays today, the plan it would move to, the new price, and the delta. Then overlay customer health. A 100% increase for an account already at risk of churn calls for an exception or a different migration path. I’ve recommended this analysis because it makes the revenue opportunity and the exposure visible before anyone approves a rollout. [Citation: https://youtube.com/watch?v=x7JMyl18mJg] The decision slide should ask for three things: the proposed pricing and packaging, the migration rules for existing customers, and the test you’ll run before a full launch. I’d track new-customer conversion and expansion alongside churn risk. Pricing is an ongoing process of customer feedback and monitoring, so executives should approve a way to learn and adjust, too. [Citation: https://open.spotify.com/episode/3ci9fazsB6UmNZ7ePWZ8GP] ##### [Dan Hockenmaier]() I’d add a slide that forces a choice about where the next dollar of margin goes. In my pricing essay, I contrasted two reasonable approaches. A higher price can pay for sales, marketing, and product work that wins customers. A lower price can bring in more users and make a marketplace more useful to everyone already there. The choice depends on whether the next dollar does more work in our hands or in the customer’s pocket. [Citation: https://medium.com/p/aa6507e0da23] Put two prices side by side. For each, show what you expect to happen to conversion, usage, contribution margin, and the ability to pay for customer acquisition or service. Mark the estimates drawn from observed behavior separately from assumptions. For a marketplace commission increase, the failure case could be sellers leaving, reducing selection and ultimately buyer demand. I’d ask executives to approve a limited rollout and the conditions for stopping it, since a near-term revenue gain can hide a slower loss of marketplace activity. ##### Question > Kyle, Elena would check awareness and buying friction before proposing a pricing-model change. How would you show executives that the offer itself needs to change, using an example from your public work? Please cite the public source. ##### [Kyle Poyar]() Elena’s diagnosis is where I’d start. I’d show executives a pricing-page usability test and buyer interviews first: can target buyers identify the right plan, understand the benefit, and complete the purchase? I’ve seen a clearer pricing page have roughly the same effect as changing price points in portfolio pricing projects. [Citation: https://open.spotify.com/episode/3ci9fazsB6UmNZ7ePWZ8GP] Then I’d show where the package limits adoption even after buyers understand it. In my interview about Algolia, I described how putting valuable new capabilities behind expensive enterprise tiers drove upgrades in the short term while bottom-up adoption weakened. Algolia moved to usage-based, pay-as-you-go access to its core capabilities; that changes what a developer can actually buy and try, which a clearer page alone cannot fix. I’d present that as the hypothesis, with new-customer activation and paid conversion by segment beside expansion revenue, and ask executives to approve a staged offer test. [Citation: https://podcasts.apple.com/gb/podcast/274-everything-you-want-to-know-about-plg-kyle-poyar/id1511588213?i=1000558138420] ##### Question > Alvaro, Kyle proposes an account-level migration analysis and a staged offer test. How would you verify that the proposed plans produce correct bills before executives approve a rollout? Please cite your public work. ##### Question > Dan, Kyle's Algolia example shows a higher-tier package weakening bottom-up adoption. How would you show executives whether wider adoption is worth more than the near-term revenue from that package? Please cite your public work. ##### [Dan Hockenmaier]() Kyle’s Algolia case calls for a cohort model that follows new users past the first invoice. Compare the current higher-tier package with a broader-access offer: how many users activate, how many convert to paid, what they spend over time, and how much each path costs to acquire and serve. The executive decision hinges on whether extra adoption generates enough future contribution margin to outweigh the upgrades the current package captures now. I’d be especially careful with the timing. In my pricing essay, I argued that a lower price can let users create value and bring in more users, while a higher price can fund sales, marketing, and product work. Price elasticity and network effects determine which path has more leverage. [Citation: https://medium.com/p/aa6507e0da23] I’d ask for a staged test with a holdout, track adoption and paid conversion by cohort, and revisit the revenue comparison after those cohorts have had time to expand. The forecast should show the break-even assumption on conversion or expansion, so executives can see exactly what the broader offer has to achieve. ##### Question > Elena, Dan would stop a marketplace price rollout if seller activity or buyer selection fell. How would you present those early signals to executives alongside a slower revenue outcome, and decide when to stop the test? Please cite public work. ##### Question > Japna, Dan proposes a holdout and a cohort forecast for broader access. In your Productboard free-plan case, how would you show executives whether new adoption offsets lost sales-led pipeline before approving a wider rollout? Please cite public work. ##### Question > Kyle, given Dan's cohort break-even test and Japna's sales-pipeline risk, what would you put on the final approval slide so executives know what they are approving and when the team must return for a decision? Please cite public work. ##### [Kyle Poyar]() My final approval slide would specify the eligible segment, the proposed package and price, the old offer or holdout, and the date the team returns with results. I’d put Dan’s break-even threshold for paid conversion and expansion next to Japna’s sales-led pipeline guardrail, with a stop rule if the new plan shifts qualified deals out of the pipeline faster than it creates paying customers. Those thresholds should be agreed before the pilot. For a sales-led offer, I’d name the handful of experienced reps running the pilot and have them log buyer objections, actual discounts, close rates, and deal size. I’ve recommended starting with reps who consistently hit quota because their calls help refine the proposal and talk track before the rest of sales adopts it. The approval is for that pilot and its migration exceptions; the team returns for a wider rollout decision once conversion, pipeline, and account-level price impact are in view. [Citation: https://youtube.com/watch?v=x7JMyl18mJg] ##### Question > Alvaro, Kyle would pilot the new offer with sales reps and check actual discounts before a full rollout. For a usage-based price, which billing checks would you put beside that sales evidence in the executive approval request? Please cite public work. ##### [Alvaro Morales]() Beside Kyle’s sales pilot, I’d put a bill-difference report built from actual usage. Replay a representative period under the proposed usage rates, and compare each resulting bill with the current bill, contract terms, and the price the rep quoted. Group discrepancies by customer cohort so executives can see the exposure before approving wider rollout. I’ve described using connected usage and pricing data to backtest different revenue strategies against past usage patterns. [Citation: https://podcasts.apple.com/nl/podcast/the-evolution-of-software-pricing-and/id1823747865?i=1000727060016] I’d have engineering and finance check the cases most likely to produce a wrong bill: usage arriving late, corrected events, unusual contract terms, and the date a customer switches plans. For a billing migration, I’ve publicly described event backfills as a way to amend reported usage and revert a mistake. That gives the team a concrete recovery path to test before moving a cohort. [Citation: https://twitter.com/alvaromorales/status/1724501919467700663] The approval request should name the owner of each unresolved discrepancy and limit rollout to cohorts whose bills and customer-facing usage totals pass those checks. #### [Designing SaaS tiers around a value metric]() **Question:** How do you design SaaS packaging and pricing tiers? ##### [Alvaro Morales]() 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. [Citation: https://www.youtube.com/watch?v=J4fUDNNxyg0] 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. [Citation: https://open.spotify.com/episode/75kelOr3ulTl6OBkLEOIZp] 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. [Citation: https://www.youtube.com/watch?v=J4fUDNNxyg0] 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. [Citation: https://www.youtube.com/watch?v=J4fUDNNxyg0] 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. [Citation: https://www.youtube.com/watch?v=MJwfJ5-Sttw] ##### [Japna Sethi]() 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. [Citation: https://youtube.com/watch?v=z_60M7cJJqw] 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. [Citation: https://youtube.com/watch?v=TQzQn6c-HZ8] 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. [Citation: https://amplitude.com/community/events/ama-japna-sethi-productboard] 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 Verna]() 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. [Citation: https://youtube.com/watch?v=9FHYtjw6mjs] Then, for every feature, decide whether it goes free or paid: 1. Commodity features (storage, notes, video calls) go free. Your competitors give them away, so you can't charge for them. 2. Features that drive retention or virality lean free, because gating them slows down the growth loop. 3. 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. [Citation: https://www.elenaverna.com/p/10-pricing-and-packaging-optimizations] 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. [Citation: https://www.elenaverna.com/p/why-ai-startups-are-blowing-past] Use pricing page conversion as your scorecard. At least 15% of pricing page visitors should click through to checkout. [Citation: https://www.elenaverna.com/p/what-does-awesome-pricing-page-look] P.S. Paywalls on teamwork? Nah. Gate complexity and keep collaboration free. ##### [Alvaro Morales]() 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. [Citation: https://open.spotify.com/episode/21lO1YuiaKGeiGolvBvWx8] 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. [Citation: https://twitter.com/alvaromorales/status/1720530375620116623] 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. [Citation: https://www.linkedin.com/feed/update/urn:li:activity:7258496834975739904/] 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. [Citation: https://open.spotify.com/episode/75kelOr3ulTl6OBkLEOIZp] ##### [Japna Sethi]() 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. [Citation: https://youtube.com/watch?v=TQzQn6c-HZ8] 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 Morales]() 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. [Citation: https://www.youtube.com/watch?v=MJwfJ5-Sttw] 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. [Citation: https://www.youtube.com/watch?v=MJwfJ5-Sttw] 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. [Citation: https://www.youtube.com/watch?v=MJwfJ5-Sttw] ##### [Kyle Poyar]() 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. [Citation: https://kylepoyar.substack.com/p/your-guide-to-saas-packaging-201] 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. [Citation: https://mucker.com/blog/saas-startup-pricing-mistakes-and-how-to-fix-them-with-kyle-poyar/] 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. [Citation: https://kylepoyar.substack.com/p/your-guide-to-saas-packaging-201] 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 Sethi]() 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 Morales]() 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. [Citation: https://www.youtube.com/watch?v=MJwfJ5-Sttw] 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. [Citation: https://open.spotify.com/episode/21lO1YuiaKGeiGolvBvWx8] 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 Verna]() 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. [Citation: https://www.elenaverna.com/p/why-ai-doesnt-mean-the-end-of-freemium] 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. [Citation: https://www.elenaverna.com/p/so-you-want-to-price-your-ai-features] 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. [Citation: https://www.elenaverna.com/p/i-hate-ai-credits-pricing] 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. [Citation: https://www.elenaverna.com/p/10-pricing-and-packaging-optimizations] ##### [Kyle Poyar]() 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 Sethi]() 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 Morales]() 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. [Citation: https://open.spotify.com/episode/75kelOr3ulTl6OBkLEOIZp] 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. [Citation: https://www.linkedin.com/feed/update/urn:li:activity:7258496834975739904/] 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. [Citation: https://twitter.com/alvaromorales/status/1720530375620116623] 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 Sethi]() 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. [Citation: https://youtube.com/watch?v=z_60M7cJJqw] 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 Poyar]() 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 Verna]() 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. [Citation: https://www.elenaverna.com/p/you-should-probably-form-a-monetization] 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 Motamedi]() 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. [Citation: https://www.lennysnewsletter.com/p/mastering-onboarding-lauryn-isford] 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. [Citation: https://www.youtube.com/watch?v=dLku0AiGPVA] 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. [Citation: https://www.youtube.com/watch?v=dLku0AiGPVA] 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 Morales]() 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. [Citation: https://www.youtube.com/watch?v=MJwfJ5-Sttw] 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. [Citation: https://www.youtube.com/watch?v=MJwfJ5-Sttw] Without that data, the council is guessing at what the heaviest users cost and use. #### [Tearing down a competitor's pricing, and the business behind it]() **Question:** How do you break down a competitor's pricing and packaging? ##### [Ben Williams]() My first move is to rebuild the packaging logic the competitor had in their heads, using their pricing page as the evidence. In my experience a pricing page translates upstream packaging decisions, so its confusing parts usually point to packaging problems. For each plan I answer three questions [Citation: https://www.plg.news/p/packaging-pricing-pages-and-motivations]: 1. What primary problem or use case does this plan solve? Every tier should have one distinct primary use case, and each tier up should add to the one below it. 2. Who is it for? Can a buyer tell which plan is theirs without help? When a plan is hard to self-identify with, there's usually a gap you can target. 3. What moves a customer from one plan to the next? Name the specific trigger, such as a seat cap, a usage limit, SSO, or a governance feature, and check whether that trigger appears at the point the customer's needs actually change. After those three, I check whether they're charging on the right value metric. Seat-based pricing is predictable, but it often isn't what the customer values. So I ask what unit their value really grows with and whether the competitor's metric tracks it [Citation: https://www.plg.news/p/debug-003-validating-pricing-overhaul]. Then I look for where their revenue is concentrated. PostHog cut prices on purpose, betting that more adoption, retention and usage would more than make up for lower revenue per customer. They could do this because their revenue is spread across several products, while competitors with one product can only discount new products that have little traction [Citation: https://www.plg.news/p/posthog-unconventional-growth]. Knowing where a competitor's revenue is concentrated tells you which prices they can't afford to drop. In dev tools, also note what they hide. If a competitor puts "contact us" where a price should be, buyers who research online before talking to anyone will notice the missing price, and you can win them by publishing yours. ##### [Dan Hockenmaier]() Most teardowns start with the pricing page and stop there. I start with the competitor's business model, because the price is usually a consequence of that model and only rarely a free choice. 1. Write their business as an equation. For a sales-led SaaS company, that's New ARR = leads × qualified rate × meeting rate × win rate × ACV, plus expansion minus churn and contraction. [Citation: https://www.danhock.co/p/how-to-describe-your-business-as] Fill in what you can see from the outside: whether there's a demo gate, whether you can self-serve, whether there's an annual contract, and what the seat or usage meter is. Those inputs tell you how much each new customer costs them to acquire, and that cost sets a floor under their price. 2. Work out which school of pricing they're in. Andreessen's "too hungry to eat" argument says you have to price high enough to pay for the sales and marketing it takes to get bought. Gurley's "a rake too far" argument says you price below what you could extract, so the market keeps growing and nobody undercuts you. I don't think those are two strategies. They come from different assumptions about the business. [Citation: https://medium.com/p/aa6507e0da23] If a competitor prices high, ask whether they have to, because of their CAC, or whether they're just taking margin. Only the second is a real opening for you. 3. For a marketplace or a transaction fee, compare the take rate with the transaction costs it removes: search, bargaining, enforcement and distribution. [Citation: https://www.danhock.co/p/transaction-costs] A take rate that's high relative to the cost it takes away is the weak point to attack. Ben's revenue-concentration test tells you which prices a competitor can't afford to drop. The equation tells you why. If a competitor's ACV pays for field sales, a 30% price cut doesn't just shave margin. It breaks their CAC payback, so you can expect them to defend the price instead of matching yours. ##### [Elena Verna]() I start in the product, and the pricing page comes later. Ben's third question, what moves a customer to the next plan, is one you can only answer by living through the trigger yourself. I keep a pile of Gmail accounts so I can sign up for any and every product, and I go through the whole experience: where the first paywall hits, what triggers an upgrade prompt, what the free plan lets you do before it nudges you, how activation is set up. I do that for direct competitors and for companies next door to them, because the packaging lives in those moments more than in the table [Citation: https://open.spotify.com/episode/4ev4wzoIZYUE2EtI3ge3PY]. Then the pricing page, in this order: 1. **History.** Pull up the Wayback Machine and ask why the page looks the way it does today compared to last year. Every change tells you something they learned: a plan they killed, a limit they moved, a value metric they swapped. 2. **Structure.** Do the plan names run in a clean good-better-best cascade (Free → Starter → Business → Enterprise), with features stacking in a waterfall? How do they handle add-ons? Miro puts a little $ in the table where a checkmark would go, so the add-on shows up right on the page. Tabs are a tell too. Nobody clicks the other tab, so anything hidden there is something they've stopped selling [Citation: https://www.elenaverna.com/p/the-dna-of-a-great-pricing-page]. 3. **Patterns across many teardowns.** When ten companies all land on the same element, it's probably working, and you can borrow it. The trap is copying. Copying the competition is the fastest way to mediocrity. Everything you borrow still has to go through your own user research, customer interviews and experiments [Citation: https://open.spotify.com/episode/4ev4wzoIZYUE2EtI3ge3PY]. One caveat for AI companies: your teardown goes stale fast. In Lovable's first year we launched a team plan and then killed it, made collaboration free with unlimited users, added a business plan, credit rollovers, local currency in the EU and GB, and cloud hosting pricing. So a competitor's page is a snapshot of one month, and I re-check it monthly. ##### [Kyle Poyar]() I tear down a competitor's pricing in two passes. The first pass inventories what they charge. The second works out why they charge that way. Pass 1 is a spreadsheet with the same columns for every competitor: 1️⃣ Pricing model: subscription, usage, or hybrid 2️⃣ Value metric: seats, usage, outcomes, company size 3️⃣ Tier structure, plus which features gate each upgrade 4️⃣ Free plan vs. free trial 5️⃣ Pricing transparency: public prices or "contact sales" 6️⃣ Entry discounts and promos When I ran this across 40 leading AI apps, the pattern was pretty vanilla. 70% used subscriptions, most charged per user, 50% had a free plan, another 20% offered a free trial, and 64% published their prices. Good-better-best tiers were the default. [Citation: https://x.com/poyark/status/1762573071729233943] (Hiding enterprise prices usually means they want room to change pricing later and see how high deals can go.) Pass 2 is where the useful insight comes from. Pressure-test their value metric. Ask whether the customer gets 2x the value when the metric doubles. Seats work for horizontal tools like Slack. For vertical or infrastructure products, a seat metric often caps expansion, and that gap is your opening. [Citation: https://youtube.com/watch?v=URF2pQNU0t0] Then separate how they acquire customers from how they monetize them. Shopify charges $1 for 90 days because setting up a store is a big upfront investment, and once you're live you're hooked. LinkedIn Sales Navigator does the opposite and makes upgrading painful, which tells you they're confident nobody has a good substitute. [Citation: https://www.youtube.com/watch?v=T1cjFSZR0k0] Finally, read the balance sheet behind any price move. A well-funded competitor buying share is a very different threat from a struggling one cutting price because it's the only lever left. I've seen that second case in FP&A tools. [Citation: https://www.youtube.com/watch?v=ajnwAw2RMMI] Whoop fully rebating $359 through Chase Sapphire only makes sense next to a $575M raise and a big bet on lifetime value. [Citation: https://www.youtube.com/watch?v=xmCsYLR0-sI] PS: Ask ChatGPT and Claude to describe the competitor's pricing too. Buyers do this already, and what the models say is often outdated or wrong. ##### Question > Ben's teardown includes finding where a competitor's revenue is concentrated, because that tells you which prices they can't afford to drop. From outside the company, what public signals do you use to estimate that concentration: usage limits, overage rates, enterprise gating, changelogs, or something else? Please name one public example where reading those signals correctly or incorrectly changed a pricing decision. ##### [Alvaro Morales]() The best public signal is which prices a competitor changes and which ones they lock down, especially when both happen close together. In mid-2025 OpenAI made two pricing moves within 10 days. They cut the price of their most powerful model by 80%, and they moved ChatGPT Enterprise from a flat fee to prepaid credits. Taken together, those two moves show where their revenue is concentrated. The per-token API price is what they're willing to cut to win share. Enterprise revenue is being turned into prepaid commitments, which is the revenue they're protecting. A competitor who sees only the 80% cut and matches it on their own API reads the signal wrong. A competitor who reads both moves knows the fight is over enterprise commitments, and the way to compete there is contract terms and credit design. Three other signals I use from the outside: 1. Count where the pricing page gets complicated. Simple self-serve tiers next to a detailed enterprise section with commits, custom contracts and "contact us" mean the money comes from negotiated deals. Companies put complexity where the revenue is, because every custom contract takes billing work to support. [Citation: https://podcasts.apple.com/no/podcast/building-billing-infrastructure-for-ai-companies-alvaro/id1615142314?i=1000702873648] 2. Look at the controls they give customers over spend. Cursor lets customers set their own usage caps. A competitor that offers caps expects usage-driven revenue from a broad base and is working to keep the bill predictable for them. 3. Look at the billing view each customer size gets. When a $20/month user has a live usage dashboard and a $2M/year account gets a quarterly Excel file from a CSM, the big accounts are being managed as negotiated contracts and the product is only metering for the self-serve tail. [Citation: https://www.youtube.com/watch?v=MJwfJ5-Sttw] All of these only estimate concentration. To confirm it, ask one or two customers you lost to that competitor what they actually paid and how the deal was structured. [Citation: https://open.spotify.com/episode/75kelOr3ulTl6OBkLEOIZp] ##### Question > Dan, you said a high competitor price is only an opening if they're taking margin, and not if their CAC forces it. From the outside, what public evidence tells you which case you're looking at? Examples might be a demo gate, sales headcount on LinkedIn, a self-serve path, or published discounts. Please walk through one real company where you made that call. ##### [Dan Hockenmaier]() The test I use is whether the price pays for work you can see from the outside. If the high price funds something the competitor visibly does, they have to charge it. If you can't find that work anywhere, they're probably taking margin. DoorDash vs. Grubhub is the case I've written about. DoorDash charged restaurants higher commissions than Grubhub, and from the outside that looked like DoorDash was taking margin, which made it look easy to undercut. But DoorDash ran delivery itself, and Grubhub's older model mostly aggregated demand. The higher commission was paying for drivers and logistics that restaurants couldn't run on their own. A competitor who read that commission as margin and attacked on price would have lost. DoorDash used the higher-commission, higher-effort model to take the market. Opendoor did the same to Zillow, and StockX did it to eBay. [Citation: https://www.danhock.co/p/the-future-of-marketplaces] When I charted marketplace commissions against founding year, newer marketplaces consistently charged more and did more to justify it. Lead-gen players like HomeAdvisor sat around 5 to 10%. [Citation: https://open.spotify.com/episode/1RFQkditDgIgt7wTb2Imb0] For SaaS, I look at three public signals and check whether they agree: 1. A demo gate with no self-serve path, plus a large AE and SE headcount on LinkedIn compared with total employees. That means CAC is real and the price is carrying it. 2. Published or widely reported discounts off list. If deals regularly close at 40% off, the list price is an anchor, and the real price is lower than the page shows. 3. Whether the cheaper tier is self-serve. A competitor that sells the same product for $20 a seat by card and $60 a seat through sales is showing you what the product costs once you take sales out. If the high price lines up with heavy sales spend, attacking on price only works if you have a cheaper way to acquire customers. If none of those signals turns up, the gap between price and visible cost is margin, and that's the opening. #### [Pricing AI features and agents by the work they do]() **Question:** How should you price AI features and agents? ##### [Elena Verna]() I’d start with the unit of value customers can understand, then check whether the bill follows how they actually use the product. At Lovable, we charge for building with credits and let people collaborate without a per-user charge in self-serve. More collaborators can mean more building, so a seat fee would slow the behavior we want. [Citation: https://www.linkedin.com/feed/update/urn:li:activity:7344085100793356288/] Agents make the unit harder to define. A single prompt can trigger a multi-step plan, so Agent Mode actions cost different amounts of credits depending on complexity. We told users the pricing would change and that we’d keep iterating. [Citation: https://www.linkedin.com/feed/update/urn:li:activity:7345881882808532994/] Then test how people buy those credits. Lovable’s building was irregular, and subscription-only billing held back engagement. We tested one-off top-ups at the subscription credit price, then at 20% and 40% premiums. The 20% premium increased engagement and bookings; 40% had too few buyers. Paid retention improved 7% after the change. The practical test is engagement, bookings, and retention together, because a clean ARR line can hide a bad buying experience. [Citation: https://www.elenaverna.com/p/we-stopped-forcing-the-subscription] ##### [Dan Hockenmaier]() The price needs to fund the growth engine. For an agent that completes a measurable job, model what the customer pays per completed job against the cost of serving heavy users. A base fee can give customers a predictable budget while covering fixed delivery costs. In my pricing essay, I argued that the growth-optimizing price depends on where an extra dollar does more work: invested in sales, product, and support, or left with the customer to reduce friction and encourage use. Enterprise products that need expensive sales and delivery can justify more margin; products whose usage drives distribution benefit more from low friction. [Citation: https://medium.com/p/aa6507e0da23] AI puts pressure on seat counts, and I’ve argued that seat pricing is often a sign the product’s ROI is hard to measure. For agents, define a billable outcome customers can verify, then test adoption at different prices alongside the margin after delivery costs. [Citation: https://www.danhock.co/p/the-software-shakeout-what-is-durable] ##### [Kyle Poyar]() Intercom priced Fin at $0.99 per resolution. That works when customers and vendors can agree a support question was resolved; the definition of a billable resolution matters as much as the rate. [Citation: https://kylepoyar.substack.com/p/from-selling-access-to-selling-work] A generated video or completed research task may be easier to verify as delivered work, while downstream business success can depend on factors outside the agent’s control. For an agent, I’d make the pricing decision in this order: 1. Define the billable event and test whether customers agree it happened. A “successful resolution” needs a clear rule for handoffs, repeat contacts, and disputes. 2. Estimate customer value per event and your cost per event, including model calls and human review. Set a price that leaves room for both customer ROI and your gross margin. 3. Give buyers a way to budget. A base subscription with included usage and a clear overage rate can make variable consumption easier to buy. For an agent that resembles a specific role, package a predictable volume of work against the cost of that role. In our review of 40 leading AI apps, Palle Broe and I found seven in ten used subscriptions, and most charged per user. That fits products working alongside a person. [Citation: https://kylepoyar.substack.com/p/how-ai-apps-make-money] I’d revisit the metric when the agent starts completing work independently. ##### [Elena Verna]() One step before testing the price: check whether users can see what the paid agent does. In self-serve, I’ve seen teams put a paid feature in a higher plan and make it invisible to everyone else. Then low conversion gets blamed on price when users never had a chance to consider the feature. I recommend reviewing the paid experience in every plan state, including free, and measuring awareness before changing the price. [Citation: https://open.spotify.com/episode/0u6dzzC8GZ6Gu1f9F33vxX] [Citation: https://open.spotify.com/episode/2tzM4U4U0MOjek2QTNdg8E] For an agent, show the task it can complete, the credit cost before someone starts, and what happens when credits run out. Then separate three questions in the data: did people discover it, did they understand the charge, and did the price stop them from using it? That sequence gives a pricing experiment a fair shot. ##### [Lauryn Motamedi]() Give users a chance to finish a real task before deciding where the paid boundary sits. At Airtable, I argued for a reverse trial: let someone try premium capabilities while they learn the product, then give them a lasting free path after the trial. The point was to help them experience value before asking for a card or a sales call. I also cautioned against steering new users toward a premium feature simply because its users convert more often; onboarding should fit the user's job. [Citation: https://www.youtube.com/watch?v=dLku0AiGPVA] For an AI feature or agent, I would apply that logic with a limited trial allowance that lets a customer complete a real task. Then I would price the recurring use against the value of that task, with clear usage limits where running it costs more. Track task completion, repeat use, paid conversion, and serving cost by customer segment before settling on the allowance or price. ##### [Alvaro Morales]() Price an early AI feature for the behavior you need to observe. Adoption and customer value may matter more than maximizing revenue per request. I’ve pointed to Notion’s then-$20 AI add-on as an example of a simple fixed price that let people try the feature while the company learned how it affected customer lifetime value. The trade-off is that heavy users can cost more to serve, so measure usage and cost per customer even if the customer sees a flat price. [Citation: https://open.spotify.com/episode/75kelOr3ulTl6OBkLEOIZp] Kyle’s resolution example shows why the event definition matters. For agents whose outcomes remain hard to verify, tasks and workflows can be practical billing proxies. In enterprise deals, a prepaid pool of credits can give customers a spending commitment while allowing usage to vary. [Citation: https://podcasts.apple.com/nl/podcast/the-evolution-of-software-pricing-and/id1823747865?i=1000727060016] Then make the usage and expected charge visible while the customer is using the agent. A customer should be able to see the cost before the month-end invoice. Keep the billing system flexible enough to change the metric or combine seats and consumption as you learn which customers get value. [Citation: https://podcasts.apple.com/no/podcast/building-billing-infrastructure-for-ai-companies-alvaro/id1615142314?i=1000702873648] [Citation: https://open.spotify.com/episode/21lO1YuiaKGeiGolvBvWx8] ##### [Kyle Poyar]() For an agent sold to a department head, the price page can translate variable tasks into a predictable work package. I’ve seen buyers struggle to forecast a pile of AI credits; a monthly package tied to the work of a specific role gives them a budget they can compare with hiring. [Citation: https://kylepoyar.substack.com/p/whats-changing-with-ai-monetization] For example, an AI SDR package could state how many accounts it researches, messages it sends, and replies it handles each month. The underlying bill can still track tasks or usage. In my conversation with 11x founder Hasan Sukkar, he described task-based pricing, while the buying pitch compared an AI SDR’s output with a human SDR at roughly one-fifth the cost. That comparison only holds if the agent delivers useful output at a comparable quality, so I’d show the included task volume and overage rate beside the headline price. [Citation: https://kylepoyar.substack.com/p/whats-changing-with-ai-monetization] #### [Moving existing customers to new pricing, one cohort at a time]() **Question:** How do you move existing customers to a new pricing model? ##### [Lauryn Motamedi]() I would start with an account-level simulation of the first bill under the new model. Split customers by the size of the bill change, features they use today, and whether the new limits would interrupt an active team. Those groups need different migration paths: a customer facing a steep increase or a lost workflow deserves a direct conversation and a transition option before any automatic switch. At Dropbox, I worked on trial conversion and learned how much it matters to inspect the pockets of customers who struggle to get value, including differences by market, payment method, and customer profile. I would apply the same rigor here: pilot each migration cohort, watch paid retention and downgrades alongside revenue, and change the plan if a cohort loses active teams. [Citation: https://www.youtube.com/watch?v=vlLhPPcbli4] At Airtable, our monetization team's scope included churn prevention, downgrades, and billing as well as upgrades. That is the right set of owners and measures for a pricing migration, because an apparent revenue gain can conceal customers moving to smaller plans or leaving. [Citation: https://www.youtube.com/watch?v=dLku0AiGPVA] ##### [Kyle Poyar]() Lauryn’s first-bill simulation gives you the risk map. The next decision is whether existing customers need to move yet. If new-customer cohorts are growing fast, I’d launch the new model there first and let existing customers keep their current plans while the team validates pricing and packaging. New buyers can evaluate the new offer on its own terms, while current customers have budgeted around the old one. [Citation: https://podcasts.apple.com/gb/podcast/274-everything-you-want-to-know-about-plg-kyle-poyar/id1511588213?i=1000558138420] When you do migrate, equip the CSM with a recommended plan and a real fallback. One customer might stay on the existing price for 12 months with the existing feature set. Another could choose a lower tier at roughly the same spend or take the new package for more value. I’d reserve explicit exceptions for accounts where the new metric creates a steep increase alongside churn risk, and give buyers notice before their budget cycle. [Citation: https://youtube.com/watch?v=x7JMyl18mJg] A change in the unit you charge for, say seats to consumption, deserves more testing and lead time than a change in the price itself. For usage pricing, I’d test with new customers and a handful of existing accounts where the new model creates a clear expansion opportunity before moving the full base. [Citation: https://youtube.com/watch?v=EwaQiW216J4] ##### [Alvaro Morales]() Kyle’s point about testing on new customers first is right. The extra constraint I’d put on migration is timing at the account level. Customer trust is at stake, especially when a pricing experiment changes an existing bill. [Citation: https://podcasts.apple.com/nl/podcast/the-evolution-of-software-pricing-and/id1823747865?i=1000727060016] Then make the migration a controlled rollout. Version the plans, choose which customer cohorts move and when each change takes effect, and phase the customer communication alongside the pricing change. We built versions and migrations into Orb for that timing control. [Citation: https://open.spotify.com/episode/75kelOr3ulTl6OBkLEOIZp] Tell each cohort plainly what changes and when, with a direct reason for the change. A last-minute announcement creates immediate negative reactions, and buyers can tell when a price increase is being presented as a benefit that does not exist. [Citation: https://open.spotify.com/episode/75kelOr3ulTl6OBkLEOIZp] ##### [Kyle Poyar]() For a move to usage pricing, I’d add one release check to Alvaro’s cohort rollout: the customer’s in-app usage view must reconcile with the invoice. Product has to collect the usage data and expose consumption to customers; finance and RevOps have to bill from the same definition. If those numbers differ, even a well-timed migration leaves the buyer unable to predict or verify the bill. [Citation: https://youtube.com/watch?v=EwaQiW216J4] I’d have an account manager show a sample invoice using that customer’s recent usage before the effective date. That gives the buyer a concrete number to take through their budget approval and lets the team find metering disputes before live invoices go out. [Citation: https://youtube.com/watch?v=x7JMyl18mJg] ##### Question > Elena, Kyle would test the new model with new buyers before moving existing customers. How would you decide the test is strong enough to start moving existing accounts, and which retention signals would pause that move? Please cite public sources. ##### [Elena Verna]() I’d wait for the new-buyer cohorts to show a better long-term revenue outcome, rather than call a conversion lift a win. Compare the old and new offers on purchase conversion, engagement, renewal churn, expansion, and variable costs. Follow those cohorts for at least three to six months, longer if the renewal cycle requires it. My example price test compares $19, $25, and $29, then uses observed conversion, retention, and expansion to project revenue over three years. [Citation: https://www.elenaverna.com/p/the-price-of-your-product-is-wrong] For existing accounts, Lauryn’s first-bill simulation would tell me which cohorts need a smaller pilot. I’d pause the next cohort if paid churn, downgrades, or engagement loss rise enough to erase the projected revenue gain, or if the customers facing a large bill change lose the workflows they use. I’ve used roughly 6% higher churn as a general expectation for a price-increase cohort, so the projected lift needs to clear that hurdle. That is a planning check, not a universal pass mark. Separate price, plan-name, and feature changes where possible: a bundled release I saw at Dropbox missed its forecast and made the cause difficult to diagnose. [Citation: https://www.elenaverna.com/p/the-price-of-your-product-is-wrong] ##### Question > Japna, Elena suggests watching new-buyer cohorts for three to six months, while Alvaro recommends moving existing accounts in timed cohorts. If a customer's renewal comes before the test matures, how would you handle that renewal and choose a migration date? Please cite public sources. ##### [Japna Sethi]() If a renewal arrives before the new-buyer test has matured, I’d renew that account on its current terms for the next contract period, or offer the new model as an informed choice if the customer can see a clear benefit. I’d put the migration date in that agreement rather than switch the account partway through a term. For an account with a large projected bill increase or a feature limit that affects an active workflow, I’d schedule a direct review ahead of its next renewal and keep the old terms available while the team checks the evidence. At Productboard, I described pricing and packaging as a big bet that is difficult to A/B test cleanly; customer conversations, unit economics, and the GTM motion all matter alongside experiment data. [Citation: https://youtube.com/watch?v=z_60M7cJJqw] I’d use the early renewal to learn what the buyer expects from the new model, then choose the migration cohort after we can verify product access and invoices against what was promised. The calendar date should follow that check and the customer’s contract date, rather than a company-wide launch date. #### [Sizing a free trial to the time retained customers need]() **Question:** How long should a free trial be? ##### [Ben Williams]() I’d set the trial clock around the time a team needs to experience the paid value, then check whether that period is long enough for the users who eventually retain. For a developer tool, first value might be finding an issue; at Snyk, the core value we tracked was teams *fixing* security issues, and our activation metric used a 30-day window because several people could be involved. That 30-day window is a measurement choice, not an automatic prescription for a 30-day trial. [Citation: https://www.june.so/blog/create-your-own-product-led-growth-strategy-case-study-ben-williams-x-snyk] [Citation: https://www.plg.news/p/are-you-making-this-onboarding-mistake] I’d look at retained accounts: how many days pass before they reach the relevant team-level milestone, and how much of that time goes on setup, inviting colleagues, and actually using the paid feature? Choose a duration that gives a meaningful share of those accounts a fair chance, then compare activation, paid conversion, and retention by cohort. If the team needs longer to build a habit, a reverse trial lets people start with premium access and fall back to a free plan at expiry. They can keep using the product while you learn whether the premium feature earned its place. [Citation: https://www.plg.news/p/ultimate-guide-reverse-trials] ##### [Kyle Poyar]() Trial length also changes your cash cycle. In my analysis of free trials versus freemium, trials often produced 2 to 3 times the free-to-paid conversion rate and moved purchase decisions sooner. I used a possible 14-day time-to-purchase for a trial versus 60 or 90 days for freemium to illustrate why that matters when paid acquisition needs quick payback. Those are examples of the trade-off, rather than a universal duration target. [Citation: https://kylepoyar.substack.com/p/your-guide-to-reverse-trials] I’d compare 14 and 30 days on revenue per signup at a fixed cohort age, along with activation and eventual retention. Looking only at conversion on the trial’s expiration date rewards the shorter option for making the decision happen earlier. If the longer trial brings in better customers after setup and team invitations, that extra time earns its keep. ##### [Japna Sethi]() Trial duration also has to account for *who* is evaluating. At Productboard, I described a small team discovering value through a trial and a leader assessing an organization-wide deployment through a sales conversation or POC. We used trial behavior around specific features to qualify and route prospective buyers to sales. [Citation: https://youtube.com/watch?v=z_60M7cJJqw] So I’d separate the self-serve trial from the assisted evaluation in the experiment. Give an individual enough time to complete the core workflow, then check activation and paid conversion. For a larger team, record the time spent on setup, inviting colleagues, and procurement separately, and let sales extend an evaluation when that work is progressing. Otherwise a single trial clock can expire just as a promising account is assembling the people needed to decide. ##### [Ben Williams]() Kyle’s cash-cycle point makes the choice of trial *mechanism* matter too. For dev tools with uneven usage, a usage limit can let someone get through a full workflow even if their team’s calendar is slow; a fixed 14-day clock can expire before a colleague has reviewed the result. A reverse trial gives another option if the free plan remains useful after premium access expires. In my reverse-trial guide, I also suggest offering another premium trial when later behaviour suggests the account is ready to buy. [Citation: https://www.plg.news/p/ultimate-guide-reverse-trials] I’d qualify my earlier suggestion: a reverse trial fits poorly when there is no useful free plan to fall back to, or when setting up premium features takes substantial effort. In those cases, give people a fair route through setup and the paid workflow, then compare the revenue and retention of signup cohorts at the same age. [Citation: https://www.plg.news/p/ultimate-guide-reverse-trials] ##### Question > Elena, Kyle would compare 14 and 30 days at a fixed cohort age, and Japna would evaluate sales-assisted accounts separately. With no trial data yet, how would you pick a starting length for self-serve users, and what public example supports your choice? ##### [Elena Verna]() For a self-serve product with a simple use case, I’d start with 14 days as an experiment, then check when retained customers first experience the paid feature. The number is a starting hypothesis, not a benchmark. In my public trial framework, I recommend short trials without a credit card for simpler SMB use cases; timed trials work best when customers reach value on a similar schedule. [Citation: https://www.elenaverna.com/p/trial-configurations-explained] I’d also decide *when* the 14 days begin. If the paid feature helps during onboarding, start access at signup. If it matters only after a customer has established a workflow, let them opt in when they reach that point. My reverse-trial examples describe the cost of a traditional trial that ends before customers get their chance to evaluate, especially when a credit card is required upfront. [Citation: https://www.elenaverna.com/p/reverse-trials-examples] Compare 14 and 30 days on paid-value completion and retained revenue at the same cohort age, with sales-assisted accounts tracked separately. ##### Question > Lauryn, Elena suggests starting a trial when the paid use case appears if it comes after onboarding. For a product where value depends on inviting teammates, how would you choose the start event and trial length? Please ground the answer in public work. ##### [Lauryn Motamedi]() For a collaborative product, I’d start premium access when the creator has a workflow ready to share and invites the first teammate. That gives the team an actual chance to use the paid collaboration features during the clock. I’d still let the creator try the product from signup, and I’d test a signup-triggered version if premium features help build that first workflow. At Airtable, we broke down our week-four multi-user activation measure into team signups, invitations, and actual contribution because each step could explain why a team had yet to reach value. [Citation: https://www.youtube.com/watch?v=dLku0AiGPVA] I’d use 14 days after the trigger as a starting hypothesis, then look at how long retained teams take to reach their first shared, meaningful use. Compare 14 and 30 days among eligible teams at the same age after the trigger, checking paid conversion alongside continued team use. If the product has a useful free plan, a reverse trial lets teams continue working together after premium access expires. [Citation: https://www.youtube.com/watch?v=dLku0AiGPVA] #### [Where a paywall should stop people, and what it should offer]() **Question:** What makes people pay when they hit a paywall? ##### [Elena Verna]() People pay when the paywall stops them halfway through a job they already care about, and the price fits how they actually use the product. If the wall shows up before they've felt any value, all you've built is an exit. So I'd look at three levers. 1. Let them taste premium before you take it away. Reverse trials put every new user on the paid plan, then drop them to free. When users have to give back something they already used, they convert far better than when you ask them to imagine what paid might be like. I've seen reverse trials lift freemium conversion anywhere from 10% to 40%. One caveat: if the product is expensive to give away or people don't use it often, a reverse trial is the wrong tool. 2. Make sure they know what paid gets them before they hit the wall. Too many product teams ship a feature, put it in the paid plan, and never show it to free users. Then the paywall feels like an ambush. Free users should keep running into paid features through the whole journey [Citation: https://open.spotify.com/episode/0u6dzzC8GZ6Gu1f9F33vxX]. My benchmark is that at least 15% of pricing page visitors should click through to checkout [Citation: https://www.elenaverna.com/p/10-pricing-and-packaging-optimizations]. 3. Offer a payment option that matches how they use the product. At Lovable, users ran out of credits mid-project and the only way forward was a subscription upgrade, which didn't fit how many of them worked. So we added top-ups on top of subscriptions. Upgrades dropped by about 50%. Total revenue still went up 20%+, ARR stayed on track, and paid retention improved 7%. The people buying top-ups were among our most engaged users [Citation: https://www.elenaverna.com/p/we-stopped-forcing-the-subscription]. If people bounce off your paywall, check what you're asking them to buy at that moment. Often they want to pay, but only for the thing they're stuck on right then. ##### [Japna Sethi]() Elena's Lovable top-up story is a value metric story underneath. Credits were the unit people got value from, so the fix was letting them buy more of that unit. I'd start any paywall diagnosis there. Work out what gives value back to the user, find the specific metric that tracks it, and put the limit on that metric [Citation: https://youtube.com/watch?v=TQzQn6c-HZ8]. Dropbox is the classic case. The free plan limits storage, and storage is exactly what people get value from, so the paywall gets more relevant the more someone uses the product. Even the Space Race referral program paid out 2GB per referral, the same unit as the wall. That program also plateaued after a while, so don't expect any one lever to keep working forever [Citation: https://youtube.com/watch?v=TQzQn6c-HZ8]. In B2B the paywall is often a handoff to a person, and the same activation-first rule still applies. At Productboard we got trial users activated on specific key features first. Then we qualified them with firmographic and usage data and routed them to sales, so the rep was talking to someone who already understood what they'd be paying for [Citation: https://youtube.com/watch?v=z_60M7cJJqw]. When we launched the free plan, the team was nervous about what it would do to pipeline. We picked the free-plan limits on purpose and ran the riskiest bets first so we could test those fears with data [Citation: https://amplitude.com/community/events/ama-japna-sethi-productboard]. Wording at the wall matters more than teams expect. At one of Alvaro's Orb dinners, the PLG leaders talked about pricing as friction you balance against incentives. One tip from that group was that renaming "overages" to "on-demand spend" works very well. That pairs well with Elena's top-ups. If you sell people more of what they're stuck on, call it something that sounds like getting more, and A/B test the copy before you change the price. ##### [Lauryn Motamedi]() Once someone hits the wall and wants to pay, I've seen conversion leak in two places: the paywall copy and checkout. The first is the wording on the paywall. At Airtable, the most common onboarding mistake I saw was naming features, like a tooltip that says "this is automations," when we should have shown how the feature helps that user's workflow. Better still was a one-touch option where we set up the automation for them and showed the result. Paywalls make the same mistake with a list of premium feature names. Japna's "on-demand spend" rename fits here, and I'd take it further. When someone hits the wall in the middle of a task, the copy should describe what they'll get done if they upgrade, and if possible let them preview that result. [Citation: https://www.youtube.com/watch?v=dLku0AiGPVA] The second is checkout. At Dropbox I worked on trial conversion, helping teams move to premium after trying Dropbox together, and I learned how much the small fixes compound. We made sure people in different markets, with different payment methods and different customer profiles, could all get through the purchase, and we went really really deep in the data to find where each segment dropped off. A user in a market where we didn't accept their usual payment method was ready to buy, and we lost them anyway. [Citation: https://www.youtube.com/watch?v=vlLhPPcbli4] I'd check both before touching price. Break paywall conversion down by country, payment method and plan type, because a blended rate hides the segments where the willingness to pay is already there. ##### Question > Elena said Lovable added credit top-ups next to subscriptions, and upgrades fell about 50% while total revenue rose 20%+ and paid retention improved 7%. Kyle, when someone hits a usage paywall mid-task, under what conditions would you offer a one-off top-up at that moment instead of pushing the subscription upgrade, and what pricing on the top-up keeps it from cannibalizing the plan? ##### [Kyle Poyar]() I'd offer the top-up when the overage looks like a burst, and push the subscription when it looks like a new baseline. My test for a burst: 1️⃣ The user is already paying, or clearly engaged, and runs out in the middle of a project. 2️⃣ The jump to the next tier is far larger than what they need to finish the task. 3️⃣ This is the first time they've hit the limit, so you can't tell yet whether it will repeat. If someone hits the wall two or three cycles in a row, that's recurring usage. At that point the upgrade is the better deal for them, and the paywall should say so. Elena's data fits this. Her top-up buyers were among Lovable's most engaged users, and retention went up. For pricing, I like what Figma did. Their pay-as-you-go AI credits cost 20% more than credits bought through a subscription. That's enough of a gap to nudge steady users toward the plan without punishing someone who only needs a one-time burst. Show both prices side by side at the wall, along with the point where the subscription becomes cheaper, so the user can do the math right there. Two structural fixes cut down on mid-task walls in the first place: 1️⃣ Include enough credits that about 80% of customers get through their first month. The top 10% of customers usually drive 70 to 80% of credit usage, so the wall mostly hits power users. 2️⃣ Move from monthly to annual usage limits. Running out in month one feels like a bait-and-switch, and an annual drawdown smooths out the bursts so you need fewer top-ups. Where you can, also charge when the usage succeeds, and skip charging the moment someone tries a feature. ##### Question > So far the group has described paywalls where the person who hits the wall can also pay: Lovable credits, Dropbox storage, Kyle's burst-versus-baseline rule for top-ups. Ben, in developer tools the engineer who hits the wall often can't approve spend. At Snyk, when the self-serve channel was growing 65% QoQ, what actually got a team to pay at that moment? Was it a seat or team limit, a usage cap, or a handoff to a manager or sales, and what did you try that failed? ##### Question > Elena, you said people pay when the wall stops them halfway through a job they care about. Kyle recommends enough credits that about 80% of customers finish month one without hitting a limit, and moving to annual usage limits so bursts get absorbed. At Lovable, would those two changes raise or lower conversion, and what data would tell you the free or entry allowance is too generous? ##### [Elena Verna]() At Lovable I'd expect both changes to lower the upgrade count and raise total revenue. We already ran a version of this test. When we added top-ups, upgrades fell about 50%, total revenue went up 20%+, and paid retention improved 7%. Before top-ups, people did an upgrade-downgrade dance to get through a heavy month. Afterwards they stayed on their plan longer [Citation: https://www.elenaverna.com/p/we-stopped-forcing-the-subscription]. A bigger allowance and annual limits push in the same direction, toward fewer forced upgrades and longer paid lives. So I'd judge them on revenue per user and paid retention. Conversion rate alone will make them look like a loss. I'd apply Kyle's 80% rule to paid plans first. At Lovable, every free credit costs real compute, and that's the same reason I warn that reverse trials are the wrong tool when the product is expensive to give away. The free or entry allowance is too generous when: 1. Engaged users rarely reach the wall. If your most active cohort finishes real projects and never sees a limit, there's nothing to pay for. 2. Fewer people reach the pricing page, and engagement and retention stay flat. In that case you gave value away and didn't get usage back. 3. Pricing-page-to-checkout drops below 15%. That usually means people are browsing out of curiosity because nothing is blocking them [Citation: https://www.elenaverna.com/p/10-pricing-and-packaging-optimizations]. The allowance is too stingy when people hit the wall before they've built or published anything. At that point they haven't felt the value yet, so they leave. I'd check one more thing: who is hitting the wall. Our top-up buyers sent more messages and published more than average users. When the people hitting the wall are mostly your heaviest users, the wall is in the right place, whatever the conversion rate says. ##### Question > Elena's test is that the wall is in the right place when your heaviest users are the ones hitting it. Ben, in developer tools the heaviest user is often an engineer who can't approve spend. At Snyk, what limit actually got a team to pay: seats, usage caps, or a feature a manager or security lead needed? How did the paywall reach the person with budget, and what did you try there that failed? ##### [Ben Williams]() Elena's heaviest-user test needs one change for dev tools: measure the heaviest accounts instead of the heaviest users, because the engineer hitting the wall and the person holding the budget are often two different people. The clearest failure at Snyk was a handoff to sales placed at the wrong moment. Zack Kanter called us out publicly because he couldn't create an API key without upgrading, and he couldn't upgrade without talking to sales. [Citation: https://twitter.com/theplgeek/status/1550555891170217985] He was the buyer, he had the budget and the intent, and our packaging made him wait for a sales cycle. That's the cost of assuming the person at the wall can't approve spend. Sometimes they can, and a sales gate turns a buyer into a complaint. So the self-serve channel we launched, with new pricing and packaging, was there to let teams who were ready pay on the spot. That's the channel that grew 65% QoQ. Sales came in later, based on account-level signals. For the engineer who can't approve spend, a sales follow-up on that one person is the wrong move, whatever limit they hit. Snyk's experience shaped how I think about product-qualified accounts (PQAs). An individual crossing a usage threshold is a noisy signal in B2B, because most of those users have no buying authority. What tells you an account is ready is aggregate usage across the team or company. Inside that account, the person who can buy often shows up through behaviour like sending larger numbers of invites. [Citation: https://www.plg.news/p/how-to-use-product-qualified-accounts] When no buyer shows up, sales and ABM have to go and find one inside the account. The engineer's job at the wall is to make the case to their manager, so the GitHub lesson applies even more in dev tools. When GitHub's signup flow laid out plainly what free and paid each included, conversion rose 35% and self-serve ARR grew by more than $1M. [Citation: https://www.plg.news/p/the-million-dollar-experiment-how-github-boosted-conversions-with-a-single-flow-change] An engineer can't argue for a plan they can't explain, so the paywall copy should be easy to forward to the person who approves the budget. --- Copyright © 2026 Super Me Network, Inc. All rights reserved. | [Terms of Service](https://www.superme.ai/terms) | [Privacy Policy](https://www.superme.ai/privacy)