- Growth with Gary
- Posts
- Usage-Based Pricing in Product-Led Growth
Usage-Based Pricing in Product-Led Growth
Pros and cons of usage-based pricing in product-led growth strategies. Learn from real-world experiences with AI-powered features and get actionable insights on when this pricing model works best for B2B SaaS products

Lessons Learned: Usage-Based Pricing for AI-Powered Products
I want to share my experience with usage-based pricing in product-led growth, particularly when it comes to AI-powered features.
Usage-Based Pricing Example: Security Questionnaire Automation
Let me set the scene. In our compliance platform, we deal with security questionnaires - those tedious but necessary documents that businesses need to fill out when selling to enterprises. Whether you're selling to one enterprise or five, you need to complete these questionnaires each time, and each one is slightly different. This is where AI comes in, helping to understand your company and the enterprise's compliance needs to automate this process.
Our Usage-Based Pricing Experiment
We implemented usage-based pricing for our security questionnaires feature, primarily targeting startups and SMBs. Here's how we structured it:
We offered two free security questionnaires as part of our freemium model
Additional questionnaires required purchasing credits
Credits were available in various packages
We created flexible offerings: standalone credit packages, credits bundled with larger compliance packages, or paired with consultancy services
My Lesson Learned:
Looking back, I've realized some important lessons about usage-based pricing with AI features.
Low volume usage: For startups and SMBs, security questionnaires weren't frequently used. While we saw some adoption and used it as an upsell lever within larger packages, the sporadic nature of the task didn't align well with our product-led growth strategy.
High Op Cost: Our security questionnaires had a high operation cost, so we needed to ensure we were unlocking the right amount to get back ROI. Giving free AI credits didn't make sense for high-volume freemium plans.
Perceived Value: AI is not used once or twice, and you will see the benefits immediately. You must use it multiple times (imagine your ChatGPT usage). An end-user wants to try to understand what input and output look like, consider editing inputs, and understand the true value (time-saving) before the willingness to invest in more credits.
Usage-Based Pricing <> Usage Frequency π
Frequent Small Tasks Win π
UBP works best for products that users need regularly, ideally multiple times per month. This encourages habit formation, making the product an important part of the user's workflow. Secondly, it provides multiple opportunities for users to experience and recognize the value of the product. Additionally, when operational costs are lower for these smaller tasks, it becomes easier to offer generous trials or freemium tiers, further driving adoption.
The buying decision also becomes more straightforward when costs are lower and spread out over time. Users can easily justify the expense as part of their regular operational costs, rather than viewing it as a significant, one-time investment.
The buying decision also becomes more straightforward when costs are lower and spread out over time.
Challenges with Large, Infrequent Tasks π
In contrast, our experience with security questionnaires highlighted the challenges of applying UBP to larger, less frequent tasks. Our challenges included:
Higher operational costs, making it difficult to offer competitive pricing or generous free tiers.
The need for multiple attempts before users could fully appreciate the value, leading to potential churn before the "aha" moment.
Infrequent usage (e.g., once every few months) made it harder for users to build a habit or remember to use the feature.
Difficulty in justifying the cost for a tool used so sporadically.
The need for multiple attempts before users could fully appreciate the value, leading to potential churn before the "aha" moment.
The success of UBP is heavily dependent on usage frequency. When users need a feature multiple times per month, they're more likely to rely on the AI solution, see the value in bulk usage, factor it into their regular expenses, and maintain consistent engagement. However, for tasks needed only once or twice per quarter or year, the value proposition becomes harder to justify, and user retention suffers.
Characteristics for a Good ππΌ Usage-Based Pricing in PLG
Low Operational Costs: Products with low marginal costs per use are ideal for UBP in PLG. You can offer generous free tiers and trial periods, and the buyer feels low financial risk.
Frequent, Small-Scscale Usage: UBP works best for products that users need regularly, ideally multiple times per month. This encourages habit formation and demonstrates value consistently.
Clear Value Metrics: The usage metric should directly correlate with the value customers receive, making it easy for them to understand and justify the cost.
Affordability & Scalability for Small Teams to Large Enterprises: The product should offer low starting price point. Depending on volume usage, it is accessible to individual users, small teams, and large enterprises.
Quick Aha Value: Users should be able to see tangible benefits within the first few uses, encouraging continued engagement.
Transparent Pricing: Clear pricing helps the buyer and implementer budget and plan.
Alignment with Customer Success: If the customer continues to succeed, it reflect value gained from using the product
UBP works best for products that users need regularly, ideally multiple times per month. This encourages habit formation and demonstrates value consistently.
Characteristics to Avoid π ββοΈ for Usage-Based Pricing in PLG
High Operational Costs: Products with significant operational costs per use are challenging to offer with generous free tiers or low-cost entry points.
Infrequent or Large-Scale Tasks: UBP is less effective for products used sporadically or for major, infrequent projects.
Hard to Understand Value: If customers struggle to understand how their usage relates to pricing, it can create friction and reduce adoption.
Limited Scalability: Products that don't cater to a wide range of user types and sizes may struggle with UBP in a PLG context.
Delayed Aha Value Realization: If it takes many uses or a long time to see the product's benefits, users may churn before reaching the "aha" moment.
Taximeter Effect: Customers may feel anxious about costs increasing with every action, leading to reduced product usage.
Other Packaging and GTM Consideration π§
Hybrid Models: Consider combining UBP as part of the subscription tiers. We packaged our UBP into our Annual premium subscription tiers as another product line item. We mentioned the original price of the credits and the value the customer will be receiving. Now customers feel reassured with the usage-based feature "thrown in," and they feel prepared for the whole year. The challenge is it was still hard to showcase "actual" UBP value, without a high usage frequency.
We packaged our UBP into our Annual premium subscription tiers as another product line item.
Tiered Pricing: Volume discounts and number of credits per tier. We received hand-raisers and PQLs (Product-qualified leads) when customers used our UBP feature. We would auto-send emails asking if they need help or want more credits. We experimented with tiering credits as bundles with professional service offerings. This helped customers consider starting at a small package, and they can return to us to buy a bigger package. Start small and nurture relationships.
We would auto-send emails asking if they need help or want more credits.
Know when to make it Sales Led Motion: Consider testing GTM motions. It's important to recognize when UBP early might not be the best fit instead of shoehorning it in. If your product has attributes in the Avoid list above, then it's best to experiment with the GTM motion. In some cases, a sales-led motion might be more effective for these types of products or features.
If your product has attributes in the Avoid list above, then it's best to experiment with the GTM motion.
SaaS Usage Based Pricing examples using PLG π―
Several SaaS companies have successfully implemented Usage-Based Pricing (UBP) models, demonstrating the effectiveness of this approach. Here are some notable examples:
Amazon Web Services (AWS)
AWS is a pioneer in UBP for cloud computing services. Their model includes:
Pay-as-you-go pricing for various cloud resources
Free tier for new or low-usage customers
Reserved instances for discounted long-term commitments
Spot instances for flexible workloads at lower prices
My takeaway:
They lean into the self-serve documentation and ease-to-setup model, leading to higher adoption. It's pretty straightforward why AWS is the leading cloud computing and hosting provider. Developers can start low and, once things are proven out, ready to scale. And then, of course, pass it to the company credit cardβ¦ π³ π
β
Expect High volume usage / high frequent tasks
β
Low operational cost on each task
β
Users understand the value right away
β
It is low-cost to start and scale up to enterprises, that need a large volume
β
Pricing is transparent
Twilio
Twilio, a communication API platform, offers:
Metered usage "pay-as-you-go" pricing
Charges per API call
My takeaway:
Twilio is another example of selling to developers. In my early days, when I attended hackathons, Twilio would do a lot of marketing and sponsorships. And the goal is to get developers to try and build on free credits. Once they return to their company, they can automatically advocate using Twilio because the developers know how to set it up. And the company's usage will be high enough for Twilio to capitalize on.
β
Low operational cost on each task
β
Users understand the value right away
β
Pricing is transparent
β
It is low-cost to start and scale up to enterprises, that need a large volume
Expect High volume usage / high frequent tasks β
Zapier
This automation tool prices based on:
Number of "Zaps" or tasks completed
Tiered plans with specific task limits
My takeaway:
Now, we apply the UBP method to Makers, Products, Marketers, and Operations with Zapier. There are those few pesky tasks inside every org that need some sort of automating. The operations person just got to grab the bull by the horn and set up their own "zaps." Once they got the zap completed using their personal account, they just replicated it and passed it to the company credit cardβ¦ π³ π
β
Users understand the value right away
β
It is low-cost to start and scale up to enterprises, that need a large volume
β
Pricing is transparent
Slack
Slack uses a hybrid model combining subscription tiers with usage-based features:
Fixed monthly or annual subscription fees for core plans
Usage-based scaling for message storage and API call limits
My takeaway:
In the early days, Slack used UBP limits as a primary paywall. The initial "paywall" was after sending 2000 messages. According to the story, this is purely the CEO's decision. I advise you to try different UBP limits for your product. The free messages were just a paywall to get you onto the a-tier subscriptions. Because it is so low cost to operate and has a high frequency of use, it was perfect for UBP limitations.
β
Expect High volume usage / high frequent tasks
β
Low operational cost on each task
β
Users understand the value right away
These examples demonstrate that successful UBP models often focus on key value metrics directly tied to customer usage and value received. They also frequently offer flexibility through tiered plans, pay-as-you-go options, or hybrid models to cater to diverse customer needs.
Final Thoughts
Based on my experience, usage-based pricing works best when it aligns with frequent, smaller tasks rather than large, occasional ones. The key is to match your pricing model with your users' natural usage patterns and ensure they can quickly experience and understand the value proposition.
I write daily*** about my learning on launching and leading PLG. Feel free to subscribe.

I am Gary Yau Chan. 3x Head of Growth. Product Growth specialist. 26x hackathon winner. I write about #PLG and #BuildInPublic. Please follow me on LinkedIn, or read about what you can hire me for on my Notion page.