For a $100M+ ARR developer platform with millions of sign-ups, the problem isn't growth. It's efficiency.
The open-source projects are thriving, and the free tier is packed with engaged users. But when the board asks, "What is the revenue mix?" the answer is often uncomfortable: 90% of ARR still comes from expensive, 6-9 month enterprise sales cycles run by a large sales team.
The free tier acts as a marketing channel, but it is unclear how to systematically convert those users into self-serve revenue or identifying the "diamonds in the rough" for the sales team.
Revenue Channel | Current State | Target State | Why It Matters |
Sales-Led (Enterprise) | 90% | 60% | Currently, too reliant on adding sales headcount to grow. Needs to focus only on high-ACV "Whales." |
Sales-Assisted | 5% | 30% | High Efficiency. This is where you capture mid-market deals efficiently without expensive field sales rep time. |
Self-Serve | 5% | 10% | Needs to become a predictable engine for capturing smaller users and startups automatically. |
To get to this targeted revenue mix, the organization needs a signal-first operating system that automatically sorts traffic, allowing smaller users to self-serve immediately, while identifying and routing high-value "mid-market and enterprise" signals directly to the sales team.
So Sales can focus only on qualified opportunities, and improving efficiency (Revenue per Employee) instead of cold calling everyone. At the same time, it captures the long tail of self-serve revenue automatically. An efficient system that separates Signal from Noise.
There is a cultural dynamic happening inside the org. It feels like Sales-led vs. Product-led. I have experienced that environment before.
This misalignment is why I advocate for a Revenue Council, a dedicated weekly sync where self-serve and sales leaders align on efficiency. It stops the Product vs. Sales “war".
Table of Contents
How to measure success and efficiency with your PLS routing system?
Efficiency is about speed. A signal-first engine optimizes three specific clocks:
Time-to-Value (Activation): How fast does a generic signup become an active user?
Goal: Shorten this via "Signal Traps" (product nudges).
Time-to-Signal (Qualification): How fast does an active user generate a buying signal (Team Invite, SSO click)?
Goal: Move users from "Free" to "Sales-Assist" automatically.
Time-to-Close (Monetization): How fast does a qualified signal become revenue?
Goal: Use Sales-Assist to unblock friction, not just "sell."
Why Large Free User Bases fail to generating Enterprise Pipeline?
There is a Signal-to-Noise ratio challenge. For every 10,000 signups:
9,500 of those users are noise. They're students, hackers, freelancers, one-off experiments, side projects that never go live.
500 are signal. They're real teams, real workloads, real intent to pay.
When Sales got tired of being handed "PLG leads" (which turned out to be 95% hobbyists), they stopped trusting the pipeline. They went back to outbound, founder meetings, and hand-shaking at conferences, which is predictable and under their control. But to the org, it's expensive and slow.
The organization wants PLG to work, but without a mechanism to distinguish a hobbyist from a buying team, Product and Sales remain misaligned. The goal is to separate the noise from the signal and build the machinery to route each segment to the right outcome.
Why Is My Self-Serve volume So Unpredictable?
The problem is not having a mechanism to tell the difference between a hobbyist who will use your product forever and never pay, versus a team that's about to hit a real constraint and become a paying customer.
Why setting Volume Limits might not be a good PQL signal in Self-Serve?
Most developer platforms use "Volume" as their paywall (e.g., "Free up to 1 million API calls"). This creates two problems:
95% of your free users (hobbyists) will never hit 1M calls, so they never pay you a dime.
The 5% who do hit the limit usually hit it by accident (e.g., a load test or a traffic spike). They get a surprise bill or a service cutoff. It feels like a punishment, not an upgrade.
Why is Collaboration as a PQL signal predictable?
Instead of waiting for a user to accidentally hit a usage limit, gate the features that signal a business: Inviting Team Members.
Free: Unlimited API calls, but strictly 1 User Seat.
Paid: Unlimited API calls, 5+ User Seats & Shared Workspaces.
A user doesn't "accidentally" invite a colleague. It is a deliberate action. When a developer invites their boss or co-founder, they are choosing to upgrade. By moving the paywall from "Volume" (invisible) to "Collaboration" (visible), you make self-serve revenue predictable rather than accidental.
How I manufacture signal capture: When I was selling compliance SaaS, we often said compliance is a “team effort”. We encouraged developers and engineers to invite the team because not every aspect of compliance is something they can handle alone.
There are business requirements and documentation that require their co-founders or other business staff. When they invites others onto the platform, that signaled to us that there was urgency, that the team was engaging and moving forward, and it was time for us to reach out.
How to detect a Real Buyer from the PLG motion?
Once the packaging is aligned to value-capture, now build out a system to find the people ready to pay it. Most companies try to do this with a single score ("If usage > X, it's a lead"), which might be overly simplistic. Let’s look at detecting real buyers through the 4 PQL dimensions:
Identity Signal, aka "Who are they?"
Are they using a corporate email or a Gmail account? Do they have a company enriched in your system? Are they at a Fortune 500 or a 5-person startup?
It's a starting point. Corporate domains are more likely to convert than personal emails.
Team Signal, aka "Are they multi-player?"
Did this user invite teammates? Did they set up shared workspaces or configure roles? Have multiple people from the same company domain been active?
This is the most powerful signal. Solo developers, even serious ones, often stay on free plans. Teams need governance, coordination, and audit trails. Teams have budgets. Teams convert.
Intent Signal, aka "Is there a buyer in the loop?"
Are executives logging in? Is the economic buyer (Director, CTO, CEO) active or just devs? Have they triggered sales-assist features like pricing calculator views, demo requests, or "contact sales" CTAs?
Scale Signal, aka "Is the pain acute and growing?"
Are they constantly hitting usage limits? Clicking repeatedly on advanced/locked features? Escalating support tickets for paid-only issues or scale problems? A hobbyist might tinker within free tiers forever. Real buyers feel friction, they breach limits, probe upgrades, and seek relief. Pain converts.
This closes the loop from usage to revenue. End-users activate features; buyers reveal intent through procurement motions. Buyers don't just use—they evaluate, compare, and commit. They convert.
How to speed up Time-to-Signal?
We want to increase time to value, time to signal, and time to close. We established the signals, now we need to create "signal traps" product experiences that nudge users into behaviors that signal real intent.
The Team Trap
Make collaboration the path of least resistance after your user activates.
Once someone has done their first meaningful action (tested their first API, deployed their first integration, etc.), the next prompt should be: "Want to invite a teammate to review this?"
Not because you're being pushy, but because multi-user collaboration is genuinely the next logical step in the product. And when they hit it, you know something shifted: from solo exploration to team adoption to high likelihood push to production.
The Enterprise Feature Tease
If your enterprise differentiation is security, governance, and compliance (SSO, RBAC, audit logs), then these buttons and settings should be visible in the free product.
Show them. Don’t hide them behind the Settings page. Let them be discoverable. Gate them behind a "Request Access" or "Talk to Sales" flow.
A person who goes looking for audit logs or SSO configuration is signaling something real: "I care about compliance. I care about control. I'm thinking about this as production."
How to route PQLs to the sales team?
Orchestrate the routing
Efficiency comes from matching sales effort to account potential. You cannot route a $50K prospect and a $500 prospect through the same pipeline.
Route | Who Fits (The Matrix) | Owner | Action | Goal |
Sales-Led (High Identity Signal) | High Identity + High Scale (Fortune 500 domain, hitting production limits) | Account Executive | Instant calendar booking link (e.g., Chili Piper). No forms. Goal: Book within 24h. | Hand-holding adoption |
Sales-Assist (High Team / Scale Signal) | Mid-Market + High Team Signal (50-500 employees, invited 3+ colleagues) | Sales Assist | Helpful 1:1 outreach: "I saw you invited your team. Want 15 mins to set up permissions correctly?" | Unblock technical friction to accelerate the deal. |
Self-Serve (Low Signal) | Low Identity + Low Scale (Gmail address, low volume) | Automation | Nurture campaigns, in-app guides, and transparent credit card checkout. | Automated credit card purchase (or incubate until they hit a scale signal) |
The routing logic is fundamental to the PLS operation. It ensures that we deliver efficiency to all our customers coming through the door.
It's about providing the optimal path with the least resistance, maximizing predictability in their closing. As the Head of PLG, this is the revenue operation you need to own.
Read more about the Year in the Life as the Head of PLG.
How to speed up time-to-close in the PLG motion?
Alerting the Sales-assist team of a qualified lead. Then supplying them with battle cards and assets so they can speed up time-to-close.
The "Why You Hit This Limit" One-Pager
When a user hits a paywall or activates an enterprise feature, don't show them a form. Generate a personalized one-pager.
"Your team is processing 50K API calls per hour. Here's what breaks at 10x that scale. Here's how we handle it."
The ROI Calculator Widget
Build it inside the product. Show actual value realized. "Your team saved 40 engineering hours on auth this month. At $150/hour, that's $6K in value. Our Team tier is $2K/month."
This isn't a sales tactic. It's a fact. And it lives in the product, not in a sales deck. When the AE joins the call, they're not debating value—it's already visible.
Context-Aware Battlecards
Your analytics tell you when a user is comparing you to a competitor. They visited "/vs-competitor-X". They imported configs from a known alternative.
When that happens, don't just log it. Automatically generate a competitive battlecard for that specific account. Push it to the rep before the call.
How to build the feedback loop with Sales on converting PQLs?
If PQLs aren't converting, the answer is never "get better salespeople." It's "debug the system." Trust is built in the trenches, not in dashboards.
You need a ruthless weekly ritual: The PQL Review.
Every week, the Head of Growth and the Sales Ops manager review every PQL that didn't become an opportunity. You are debugging the machine. Ask two questions:
1. Was this a bad signal? (False Positive)
Example: "This account spiked to 100K calls, so we routed it. But it turned out to be a student running a load test script for a class project."
The Fix: Tighten the PQL definition. Add a "Business Domain" filter or require "Sustained Usage > 7 Days" to filter out one-off spikes.
2. Was this bad execution? (False Negative)
Example: "The signal was perfect—a mid-market company invited 5 users. But the AE reached out once, got no reply, and closed it as 'Unresponsive'."
The Fix: Update the Sales Assist playbook. Require a multi-channel sequence (Email + LinkedIn) or mandate that Sales Assist warms up the lead before the AE ever sees it.
Sell Alongside the Team
Don’t just be the "dashboard guy" sending leads over the fence.
Shadow the Calls: Join the Sales Assist calls as a "Solutions Engineer." Hear the objections firsthand. Why did they hesitate on the price? Why didn't they understand the value?
Close Deals Yourself: In the early days, the Head of PLG should personally carry a small bag or own the first 10 PQLs. There is no faster way to earn respect from Sales than to say, "I closed these 5 deals using this playbook. Now I'm handing it to you."
The Outcome:
When you do this, you stop pointing fingers. You start validating signals together. It changes the conversation from "Marketing sends us junk" to "How do we tune the engine to get more of the good stuff?"
Sell alongside the sales team so that you don’t have the reputation of just sending junk signals. I joined calls as a solutions engineer with the sales team to diagnose questions, urgency signals, and understand why customers push back on our pitches.
Then I led the PLS team, ran product-led onboarding, close deals myself to validate those product-qualified signals. Together with the sales team, we validate the signals as a team. It's not just a baton handoff, we are running the tracks together.
What Metrics Prove This PLS routing system works?
All of this is great in theory. But the board wants numbers. Build a shared scoreboard that Product and Sales co-own.
Metric | What It Measures | What This Matter | Owner |
PQL Acceptance Rate | The signal quality. % of routed PQLs does Sales accept as "worth pursuing" | If this is <30%, your signal is too loose (too much noise). If >60%, you might be too strict (leaving money on the table). | PLG + Sales Ops |
PQL→Opportunity Rate | Handoff effectiveness. Did Sales Assist turn the signal into a qualified deal? | Are we effectively warming up the leads? | Sales Assist |
PQL→Closed-Won Rate | Revenue closed. Did the AE close it? | The ultimate truth. If this is low, either the signal was false, or the AE playbook is wrong. | AE + PLG |
Sales Cycle Length (PQL vs. Cold) | Velocity. How much faster are PQL-originated deals? | PQL deals should close 30-50% faster than cold outbound because the user is already educated and active. | Sales + PLG |
Blended CAC Payback | Efficiency. Self-serve supporting enterprise? | The "North Star". Self-serve efficiency should support expensive Enterprise motion, bringing the total average down to <12 months. | Finance + PLG |
Building a PLS Routing Operating System, Not a Lead List
PLG is not just a marketing channel. PLG is an operating system.
When you simply hand a list of unverified “qualified” signups to Sales, you destroy efficiency. You ask expensive humans to do the job of a filter. But instead building a Signal-First Routing System, flips the filter.
Develop Sales Efficiency: By routing the 95% of noise to automation and only the 5% of signal to humans.
Build Trust: By proving to Sales that “Product-qualified Leads" are high confidence and verified.
Capture Revenue: Monetizing users (from the solo hobbyist to the Fortune 500 Architect) in the most efficient way, with the lowest operational overhead.
Read more:
I write weekly about my learning on launching and leading PLG. Feel free to subscribe.
I am Gary Yau Chan. 3x Head of Growth. 2x Founder. Product Led 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.
![LTV CAC Ratio Payback Formula [Free Download Template]](https://media.beehiiv.com/cdn-cgi/image/format=auto,width=720,fit=scale-down,onerror=redirect/uploads/asset/file/44a1862d-a0e4-478c-b87f-038cdd79daef/Screenshot_2024-09-18_at_3.44.16_PM.png)
