Product-qualified lead (PQL)

A product-qualified lead (PQL) is a lead whose in-product behavior indicates high buying intent, such as reaching a usage threshold or completing a key workflow.

PQLs represent users or accounts that have demonstrated value realization through their actions, not just interest through form fills or content downloads.

MQLs (marketing-qualified leads) are based on marketing engagement: downloading whitepapers, attending webinars, or visiting pricing pages. They indicate interest but not necessarily product understanding or buying readiness.

SQLs (sales-qualified leads) are based on sales judgment after discovery calls or demos. They are further down the funnel but rely on subjective human assessment rather than usage data.

PQLs are based on actual product usage data, making them the most reliable indicator of intent in a PLG model. A user who has integrated your API into their production environment is a stronger signal than one who downloaded a whitepaper.

The key difference is signal quality. MQLs tell you someone is researching a problem. SQLs tell you someone is open to a conversation. PQLs tell you someone has already experienced value and is likely ready to pay for more.

Many PLG companies use a combined approach: MQLs feed the top of the funnel, PQLs identify the best conversion opportunities, and SQLs confirm readiness for enterprise deals.

Start by analyzing your existing converted customers. Look at the actions they took in the product before they converted to a paid plan. Common patterns include reaching usage limits, inviting team members, or using specific high-value features.

Separate your users into two groups: those who converted and those who did not. Identify the behaviors that appear significantly more often in the converted group. These are your candidate PQL signals.

Validate your criteria by testing them against historical data. If your proposed PQL definition would have correctly identified 70-80% of your past conversions while flagging fewer than 30% of total users, you have a useful model.

Consider both positive signals (actions that indicate buying intent) and negative signals (actions that indicate the user is not a fit). A user who hits API rate limits but has a free email domain may not be a good PQL.

Review and update your PQL criteria quarterly. As your product evolves and your customer base changes, the behaviors that predict conversion will shift.

A binary PQL model uses a simple threshold: if a user does X, they are a PQL. This is the simplest approach and works well for products with a clear activation event. For example, "any user who invites 3+ teammates is a PQL."

A weighted scoring model assigns points to different behaviors and triggers PQL status when the score crosses a threshold. This allows you to combine multiple weaker signals into a strong composite signal. For example, inviting a teammate (10 points) + creating a project (5 points) + returning 3 days in a row (15 points) = PQL at 25 points.

A predictive model uses machine learning to identify which combination of behaviors best predicts conversion. This is the most sophisticated approach but requires enough historical conversion data to train a reliable model—typically at least a few hundred conversions.

Most teams should start with a binary model, graduate to weighted scoring as they learn which signals matter most, and consider predictive models only when they have sufficient data and engineering resources.

Collaboration tools: Adding 5+ team members, creating shared workspaces, or integrating with other tools the team already uses. These signals indicate the product is becoming embedded in team workflows.

Analytics products: Creating multiple dashboards, setting up scheduled reports, or connecting production data sources. These actions show the user is moving beyond evaluation into real usage.

Developer tools: Making production API calls, exceeding free-tier rate limits, or deploying to production environments. These are strong signals that the tool has become part of the development workflow.

Design tools: Sharing designs with external stakeholders, creating a team library, or exporting assets for production use. These indicate the tool has moved from personal experimentation to professional use.

Communication platforms: Daily active usage across multiple channels, integrating with workflow tools, or having a high percentage of the team active. These show the platform has become the default communication channel.

Negative signals matter too—accounts that reach PQL thresholds but then go dormant may need nurturing rather than sales outreach.

A useful PQL model combines quantitative usage thresholds (such as number of projects, events, or seats) with qualitative fit data such as role or company size.

Over time you can refine your PQL model by comparing which behaviors show up most often in accounts that convert or expand.

Start simple—a single behavior threshold—and add complexity only when you have data to justify it.

Route PQL alerts to sales in real-time so they can reach out while the user is actively engaged.

Provide sales with context: what the user has done, what plan limits they are approaching, and what their company profile looks like.

Track PQL-to-opportunity and PQL-to-close rates to validate and refine your PQL definition.

Create a feedback loop between sales and product. When sales reaches out to PQLs and they convert (or do not), record the outcome and use it to refine your PQL criteria over time.