I absolutely hate it when people think of pricing as a revenue lever. I see it as core to the product experience.
– Justin Farris, GitLab VP of Product Monetization (21:10)
In a recent episode of Unpack Pricing, Metronome CEO Scott Woody sat down with Justin Farris, VP of Product Management at GitLab, to talk about a rare feat: integrating product-led growth (PLG), enterprise sales, and monetization strategy under one roof. With GitLab’s unique model—anchored by a single price book, a unified product strategy, and deeply aligned teams—the discussion outlined a blueprint for companies looking to scale efficiently across customer segments.
Here’s a look at some key takeaways from the episode that we hope can help you unify product and sales under a single strategy, treat pricing as part of the product experience, and build a pricing model that scales from free to enterprise—without breaking your business.
Unify growth, pricing, and systems under product leadership
We centralized our growth function, our pricing function, and our core systems, and that all reports to the Chief Product Officer.
– Justin Farris (02:28)
At GitLab, growth, pricing, and billing all report into product—removing friction between functions that traditionally operate in silos. This structure makes it easier to connect pricing strategy directly to user experience, fulfillment systems, and monetization goals.
If your PLG motion and enterprise sales feel at odds, the problem might be org design—not execution. When pricing, growth, and packaging sit under different leaders, you create natural misalignment. Centralizing them under product helps you operate with speed and cohesion across GTM motions.
Action item: Rethink your org charts. If pricing and growth functions are scattered, you’ll always be negotiating priorities. Bring them under one roof to streamline strategy and align on a common goal.
Treat pricing like a feature—not a finance lever
You want the pricing to be so great that the customer wants to pay you. You want your pricing to be like a feature.
– Justin Farris (21:22)
Pricing at GitLab isn’t an afterthought—it’s designed into the product experience. As Justin warns, treating pricing as a revenue lever leads to short-term wins but long-term friction. Instead, pricing should feel intuitive and value-aligned at every step.
Your pricing model affects conversion, adoption, and retention as much as your onboarding flow. If pricing feels like a separate world from the product, your customers will feel the dissonance, and your growth will suffer.
Action item: Design pricing the same way you design features. Talk to customers, test your assumptions, and evaluate how pricing impacts UX and behavior.
One price book, many buyer types
It’s one price book for everyone, but we think of it through the lens of a buyer-based tiering model—who is the primary buyer, what size of organization they’re in, and what level of the company they’re in.
– Justin Farris (18:16)
GitLab’s transparent, public pricing works for both startups and Fortune 500s because it's built around the buyer’s role and needs—not just their company size. Tiers are aligned to buyer types (e.g. individual devs vs. CIOs), not just feature sets.
While maintaining one price book can be challenging, Gitlab’s buyer-based tiering model helps them scale with value and buying context. This proves that you don’t need different pricing models for SMBs and enterprises—just thoughtful packaging. A single price book also reduces confusion, increases trust, and builds pricing discipline.
Action item: Design tiers around buyer personas. Start by asking “Who’s buying?” and “What matters to them?” rather than asking how big the deal is.
If you’re curious about GitLab’s pricing model, check out their philosophy here in the GitLab Handbook.
Align product and sales around shared metrics
When you’re in an organization that has both PLG and SLG motions, you have to create metrics for both the growth team and the GTM team that align. Their goals are similar. And that drives a lot of alignment.
– Justin Farris (09:47)
GitLab’s PLG and sales motions don’t compete—they share first-order goals like new logo acquisition and ARR expansion. Even though comp structures differ, the north stars are the same.
When your growth team is optimizing activation and your sales team is chasing quota, misalignment is inevitable unless you agree on shared outcomes. Shared metrics can turn finger-pointing into partnership.
Action item: Pick a common goal like first-order revenue or product-qualified leads, and align every team’s KPIs around it, even if they get there in different ways.
Use packaging—not just pricing—to unlock value
Usually the right solution to revenue friction or that value mismatch is not a price-level problem. It’s a packaging problem.
– Justin Farris (22:32)
When GitLab saw  that non-developer users were interested in its ancillary project management capability, but not in their core offering, they created an Enterprise Agile Planning add-on to serve that use case. This preserved their core tiers while capturing new value.
Over-relying on price changes to monetize new features creates churn risk and friction. Smarter packaging lets customers grow organically into higher tiers or add-ons based on value—not just cost.
Action item: When adding a new feature or capability, ask: does this belong in a core tier, or is it an add-on opportunity? Consider the packaging before you touch your pricing.
Test pricing like you test product features
We’ll take a feature and won’t launch it GA—we’ll hold it back for a little bit and make it limited availability, and we’ll test into it. We’ll ask customers: What would you pay for this?
– Justin Farris (31:45)
GitLab pilots new pricing models and packaging strategies through limited availability programs, which lets them validate their customers’ willingness to pay before releasing a new feature or capability to the public.
Just like A/B testing UX, you can validate pricing in-market without a full launch. This approach can give product teams real feedback while also reducing risk.
Action item: Use gated releases, betas, or cohort-specific promos to test new pricing models before rolling them out broadly.
Study AI pricing models, but adapt for your buyer
AI pricing is evolving fast, and for me, it’s the first time in my career where I’ve seen the underlying unit economics evolving really quickly. The understanding of COGS is changing, and the usage patterns are changing. That’s driving a lot of conversations.
– Justin Farris (40:29)
Even with the rise of AI-specific pricing models—like pay-per-outcome or workflow-based pricing—not every customer is ready for high-complexity consumption models. Simplicity still wins for most buyers.
AI may change what your product does, and it will also change how you monetize. Pricing AI like traditional software may miss the mark. But blindly copying complex usage-based models can backfire too, especially for non-technical buyers.
Action item: Match your pricing to your buyer’s expectations. Engineers may prefer usage-based models, while execs may want value-based outcomes. Design your pricing and packaging based on who your buyer is.
In the end: Product, pricing, and packaging are the same job
If you own the product, you own the pricing. You own the package. You have to be an owner over that.
– Scott Woody (35:31)
While general pricing decisions are made by the CEO, the product team makes most decisions on a day-to-day basis about what feature goes into which plan based on the paid tiers. GitLab’s public handbook offers a great example of how this decision-making works in practice. This approach requires product to stay closely aligned with monetization, deeply understand how customers use the product, and continually evaluate the value each feature delivers.
If you're a product leader, you already own pricing, whether it’s explicitly in your job description or not. To drive growth, you need to be fluent in both customer needs and commercial models.
Action item: Involve product in every pricing decision. Don’t just “consult” them—hold them accountable. That’s how you build cohesive strategies that actually scale.
$2 per conversation handled by Agentforce (AI agent)
A conversation is defined as when a customer sends at least one message or selects at least one menu option or choice other than the End Chat button within a 24-hour period.
Number of support conversations handled by the AI agent
First major CRM to adopt a "semi"outcome-based pricing for AI; aligns cost with actual support volumes (clear ROI)
Addresses inefficiencies of idle licenses by charging only when value (a handled conversation) is delivered
Intercom (Fin AI)
Customer Support Software
$0.99 per successful resolution by "Fin" AI chatbot - clients pay only when the bot successfully resolves a customer query
Fees accrue based on AI-solved issues
Count of support conversations resolved by the AI agent
Early adopter of AI outcome-based pricing in 2023
Lowers adoption risk by charging for resolved queries instead of a flat rate; combines usage- and value-based pricing to tie cost directly to support effectiveness.
Zendesk (AI Answer Bot)
Customer Support
Per successful AI chatbot-handled resolution
No charge if the bot fails and a human must step in
Number of customer issues or tickets auto-resolved by the bot
Aimed at cost-conscious customers wary of paying for unproven AI
Aligns price with realized automation benefit; part of a broader industry shift from per-agent pricing to value-delivered pricing in support
Chargeflow
Fintech (Chargeback Management)
Charges a fraction of recovered funds on chargebacks
Example: ~25% fee per successful chargeback recovery
No fees for chargebacks lost
Alert service charges $39 per prevented chargeback
Value/count of chargebacks recovered (disputes won) and chargebacks prevented (for prevention alerts)
4Ă— ROI guarantee on recoveries
No contracts or monthly fees
Revenue comes only from successful outcomes; pricing directly aligns with merchant's regained revenue, meaning Chargeflow only profits when the client does (win-win model)
