Getting Started with Usage-Based Pricing
A step-by-step approach to testing usage-based and outcome-based pricing models for AI features.
DEAR STAGE 2: We’re revisiting pricing as we incorporate AI into our product. We’ve heard about consumption and outcome-based models, but how do we actually start exploring those without overwhelming our customers or our systems? ~THINKING THROUGH PRICING
DEAR THINKING THROUGH PRICING: As AI continues to reshape how we build and deliver value, it’s also disrupting the very foundations of pricing. More founders are trying to move beyond simple subscription pricing, but hitting that sweet spot between “strategic” and “operationally realistic” is easier said than done.
To help us think this through, I turned to Kyle Hart, a pricing expert who has worked with dozens of growth-stage companies on pricing strategy and implementation (along with his former colleagues at Price Intelligently). Most recently, Kyle developed the new product pricing playbook Toast uses and has driven the pricing strategy, experimentation and implementation for over 5+ new product lines from $0 to $100M ARR. He’s been deep in the trenches on this topic, especially as AI features force teams to rethink value delivery, packaging, and system readiness.
Here’s Kyle’s take on how to start exploring usage- or outcome-based pricing, especially for AI-driven features, without creating chaos.
1. Don’t default to usage, start with optional pricing
AI introduces huge variability. Some customers will barely use it. Others will 10x their volume overnight. You can’t assume a one-size-fits-all pricing model will work.
Kyle’s view: Many customers say they want usage-based pricing, but they often don’t want the variability that comes with it. “I like optionality in pricing wherever possible,” he shared. “It adds complexity, but it puts the decision in the customer’s hands.”
Instead of going all-in on consumption or outcomes:
Package AI features in a way that aligns with how customers buy today.
Layer in usage tiers or credit-based models that allow advanced customers to “graduate” into more flexible pricing.
Let fixed-price packages coexist with usage models so customers can choose what works for them.
2. Build a pricing hypothesis like a product hypothesis
Before you make any changes, build a structured hypothesis. Kyle recommends treating this like a product experiment, with steps you can follow using what you already have.
Step 1: Audit your current state
Start by digging deep into your own data:
Sales behavior: What are reps discounting most often? Which features or packages are they pushing?
CRM + usage data: What features are actually being used, and by whom? Are there clusters of usage that could inform new tiers?
Team input: Your sales team is your pricing front line. Kyle recommends developing deep relationships with sales and spending a lot of time with them in ideating on potential packaging/pricing models, especially to uncover what’s getting in the way of selling confidently.
Pro tip: Many pricing decisions can be made just from this internal audit. You don’t need a survey to tell you that all customers are clustering into one package or that usage far outpaces your current limits.
Step 2: Run competitive research
Don’t over-engineer this part, but don’t skip it either. Use an LLM to create a rough feature matrix:
Which features do your competitors highlight?
How are AI features packaged or priced?
What positioning are they using for usage-based options?
This exercise helps you understand both pricing mechanics and buyer psychology. Kyle notes: even when you’re leading with differentiated value, buyers are still benchmarking you against what they already know.
Step 3: Clarify your value prop and perception
You’ve likely talked to customers. Great. Now re-analyze those conversations specifically through a pricing lens:
Which features do customers describe as essential?
Where do they want to see investment or improvements?
Why did they buy your product in the first place?
Use LLMs again here, ask it to summarize interview transcripts, tag common themes, and stack rank areas of perceived value. You’re not asking “what would you pay?,” you’re asking “what matters most?”
Step 4: Form a testable hypothesis
Now pull it all together:
Where is your current packaging misaligned with usage?
Is one tier overstuffed while another is rarely sold?
What did you learn about competitors’ pricing? Are you underpriced for premium features?
Draft 2–3 “pricing hypotheses” as mock pricing pages. Each should show:
Clear tiering or modules
A value metric (even if you’re not charging on it yet)
Price points that align with perceived value
Success metrics: what would signal this is working?
Kyle calls this the “reformatting” phase. You’re not inventing new data, you’re organizing what you already have with a new lens.
3. Validating your Hypothesis
You’ve built your pricing hypothesis, now it’s time to test it. But the question that trips most founders up is: how?
Kyle’s advice: validation depends on the nature of your product, your price point, and how many customers you actually have. There’s no universal best practice. What works for a product with 5,000 users might be overkill, or simply impossible, for a team with three enterprise logos. Most firms will default to recommending a formal survey. But Kyle’s evolved his thinking over the years: “I’m increasingly moving toward alternative options, sales pilots, interviews, even using LLMs to validate through qualitative data, because most early-stage teams just don’t have the volume to make traditional surveys worth the cost.”
Which brings us to a key choice: who should you validate with?
Here’s how Kyle approaches validation:
Sales pilots: Give your team the mock pricing pages. See how prospects react in real calls.
Customer interviews: Ask which version of pricing best aligns with value delivered, not what they want to pay.
LLM-powered summaries: Use AI to extract patterns from feedback across teams.
Internal roleplay: If your team struggles to explain it, your customers definitely will.
Surveys: customer interviews vs. market panels
When it comes to surveys, there are two main audience paths: customer interviews or market panels. Both have pros and cons, and the right choice depends on what you’re trying to learn and who you’re selling to.
Kyle offers a simple decision tree here:
If you have a meaningful base of customers, start there. Especially for packaging feedback, feature value, or early reactions to pricing changes.
If you’re targeting a new segment, or don’t have enough customers to draw from, a market panel might be helpful, but expensive.
Customer interviews and small-scale surveys are often enough to get you to 80% confidence. And they come with the added bonus of being grounded in real context.
Market panels can work, but be prepared to spend $50–$120 per response. Kyle often partners with services that help founders get the survey design, platform hosting, and targeting done for a flat fee (especially when using your own list).
And when you’re ready to analyze results? Keep it simple and structured. Kyle recommends summarizing interview data with tools like Claude or GPT. For quantitative surveys, segment your data by business type or persona, group by 30+ responses where possible, and don’t rush to conclusions, build the visuals first.
From there, look for signals:
Which personas show a distinct willingness to pay?
Are there features consistently preferred by high-value segments?
Where pricing behavior varies, is there a usage metric that could guide a future consumption model?
4. Plan for flexibility, even if you’re not ready to use it
You don’t need to launch usage-based pricing right now, but you do need to prepare your systems for it.
Many founders go down the path of picking the “right” pricing model, but can’t implement it because their billing and packaging systems aren’t flexible enough.
Kyle’s suggestion: invest in pricing ops early. Tools like Schematic or Metronome can help, but even more importantly, make sure your systems don’t lock you into a rigid structure that can’t evolve as your product does.
Pricing AI features doesn’t mean you have to start charging by the credit or outcome right away. Instead:
Give customers optional paths to more dynamic pricing.
Use internal data, team insight, and existing interviews to form a pricing hypothesis.
Validate with real conversations, not expensive surveys.
And future-proof your stack, before your customers demand it.
Thanks again to Kyle Hart for sharing this framework and insights.
Until next week!