A product-qualified lead, or PQL, is a user who has shown buying intent through what they did in the product: used a key feature, invited a teammate, hit a usage limit. It replaces form fills and job titles with behaviour, which is why product-led companies trust it over a marketing-qualified lead. It also means the lead score is only as accurate as the event tracking behind it, and nobody in sales can see that tracking.

How it works

A PQL model combines a few behavioural signals with a threshold: two or more teammates invited, the core feature used on three separate days, or the free plan's limit reached. When a user crosses the threshold, the CRM creates or promotes a lead and someone in sales gets a task.

The signals fire in the product and the score lives in the CRM, so at least three systems sit between a user's action and a salesperson's call: the product code, the analytics or data pipeline, and the CRM sync. A break in the first is invisible from the last. Sales sees fewer leads and has no way to tell a quiet market from a missing event.

What it assumes your events already do

Event	What the framework uses it for	What it reports when the event breaks
Invite sent and accepted `invite_sent, invite_accepted`	A common PQL signal.	An untracked invite path means teams that grew through it never become leads, and sales concludes those accounts are not interested.
Plan limit reached `limit_hit`	The strongest upgrade-intent signal.	If the limit event stops after a pricing change, the warmest leads never reach the CRM.
Core value action `report_viewed`	Depth of use.	A double-firing event inflates usage, and sales calls accounts that tried the feature once.
User-to-account join `account_id on every event`	Rolls users up to the company sales will call.	Users with no account property become orphan leads, or one company's score splits across duplicates.

Event names are illustrative; yours will differ. The dependency map shows which other frameworks share each event.

The month the pipeline dried up

Illustrative example. The company and the figures are invented to show the mechanism.

A team moves its invite flow from a settings page into a modal. The modal sends invites through a new endpoint that never fires invite_sent, and PQL volume falls by a third.

Sales leadership reads it as a softer market and approves more outbound headcount. The product was producing as many qualified teams as before. The lead score had stopped seeing them.

Checks before you trust it

List every signal in the PQL definition and the exact event behind each.
Watch each signal's daily volume separately; one signal going to zero is a tracking break, not a market shift.
Confirm that every signal carries the account identifier the CRM joins on.
Review the definition whenever the flows behind its signals change, not on a quarterly schedule.

What Dave Boyce adds in Freemium

Dave Boyce's Freemium moves the unit from the person to the account, the product-qualified account. Its fit score keeps sales away from accounts outside the ideal customer profile, and a guard blocks any sales contact before the account reaches First Impact (Ch 14).

Heard in The Question

Interviews in The Question that bear on this framework:

Niko van Eeghen: one metric, three meanings at Evondos. The number is rarely the hard part: one metric means different things to different people, and in parts of the economy you cannot or may not collect it.

Check the events under it

Before Product-qualified lead (PQL) goes into a plan, find out whether the events it needs exist and still fire the way it assumes. The free audit maps what your product collects today: sign in, connect a GitHub repository or Supabase, and Skene returns one audit, with no card. On Pro, Skene Cloud reviews every pull request on a linked GitHub repository for removed or broken tracking, so a pull request that removes or renames one of these events is flagged before it merges.