For years, product-led growth came with a wonderfully seductive story: build a product people love, make it easy to try, let users invite their colleagues, and watch revenue arrive while your sales team does something relaxing with its newfound free time.
Reality has been less Zen.
Slack added a direct sales force. Atlassian built enterprise sales capabilities around its famously self-service model. Figma hired its first salesperson only a few years after launching and eventually created Organization and Enterprise plans. Zoom grew a giant online business and a separate enterprise motion. The great product-led companies did not eliminate sales. They changed when sales enters the picture, what information sellers have when they arrive, and what job sales is expected to perform.
That distinction matters enormously for product managers.
Product-Led Sales, or PLS, is often presented as a GTM tactic: identify Product-Qualified Leads, throw them into Salesforce, and have an AE call them before lunch. But the better way to think about PLS is as a product system. The product must detect when individual experimentation has become organizational adoption, recognize when that organization is running into problems that self-service cannot elegantly solve, and hand the resulting context to a human who can help.
The product is no longer merely the thing being sold.
It becomes part of the sales infrastructure.
And that puts PMs squarely in the middle of the enterprise funnel.
The strange new B2B buyer: “Please leave me alone. Also, I need your help.”
The case for PLS begins with an apparent contradiction in modern B2B buying.
According to Gartner’s 2025 survey of 632 B2B buyers, 61% preferred an overall buying experience without a sales representative. Even more strikingly, 73% said they actively avoid suppliers that send irrelevant outreach. Gartner analyst Robert Blaisdell summarized the danger rather nicely:
“Bad prospecting actively damages relationships with potential customers.”
That should probably be printed above the door of every SDR bullpen.
Yet eliminating humans is not the answer either. (Gartner)
By 2026, another Gartner survey found that 69% of B2B buyers preferred using sales reps to validate AI-generated insights. Buyers used an average of seven information sources during a recent purchase, while 45% had used generative AI during the buying process. In other words, customers increasingly want to research independently—but they still want knowledgeable humans when risk, ambiguity or organizational complexity enters the deal. (Gartner)
McKinsey found a similar pattern in its 2024 B2B Pulse research across nearly 4,000 decision makers. Roughly one-third of customers preferred in-person interactions, one-third remote interactions and one-third digital self-service at any given stage. Even high-dollar purchases are increasingly comfortable online: some buyers reported willingness to conduct transactions worth $500,000 or more remotely. (McKinsey & Company)
The implication is not “sales is dead.”
It is that forced sales is dying.
The winning model increasingly looks like this:
Let the product handle discovery, education and proof of value. Introduce humans when humans can genuinely reduce friction.
That is Product-Led Sales.
PLS is not PLG with an SDR duct-taped to it
Pocus, one of the companies that helped popularize the term, defines Product-Led Sales as:
“A go-to-market approach that relies on existing users of the product to drive revenue.”
That revenue can come from initial conversion, expansion, cross-sell or upsell.
Early benchmark research showed how quickly hybrid models were becoming normal. In Pocus’s 2022 survey of more than 200 PLG companies, 49% already had a Product-Led Sales motion, 52% of sales teams were reaching out to Product-Qualified Leads, and 52% had signals that triggered human involvement for enterprise opportunities. Only 7% allowed customers to self-serve all the way onto enterprise licenses. A later 2023 benchmark covering more than 170 PLG companies found that more than half were using PLS and that blended self-service, sales-assist and enterprise motions had become the dominant pattern. (Pocus)
But there is an important trap here.
A mediocre PLS program simply replaces one kind of spam with another.
Traditional demand generation says:
“Someone downloaded our AI transformation ebook. CALL THEM.”
Bad PLS says:
“Someone clicked the export button six times. CALL THEM.”
Neither is particularly intelligent.
A good PLS system asks a different question:
What evidence suggests that this organization has experienced meaningful value, has a problem worth solving at greater scale, and would benefit from human assistance right now?
That is a much harder problem—and a much more interesting one for product management.
Figma shows what the model looks like when it works
Figma is almost a textbook illustration of the evolution.
Its product spread bottoms-up because collaboration was inherently viral: someone shared a Figma URL, another person opened it, another team joined, and adoption expanded before procurement necessarily knew what was happening.
But Figma did not conclude that salespeople were obsolete.
Its IPO filing explains that it hired its first salesperson in 2018, the same year it introduced an Organization plan. In 2022 it launched Enterprise, adding things such as advanced security, team workspaces and administrative capabilities.
More importantly, Figma disclosed that during 2024 and early 2025, roughly 70% of new Organization and Enterprise customers included at least one user who had previously belonged to a Professional-plan account. Approximately 70% of revenue during those periods came from Organization and Enterprise customers.
That is the PLS flywheel in unusually clear numbers:
individual adoption → team value → organizational spread → enterprise requirements → assisted expansion.
And the engine kept scaling. Figma’s 2025 Form 10-K reported 1,405 customers generating more than $100,000 in ARR at the end of 2025, up from 963 a year earlier—a 46% increase. Its net dollar retention rate reached 136%, while revenue grew 41% year over year. (SEC)
Figma explicitly describes two parallel purchasing paths: an “automated and highly efficient” self-service option and a direct sales process for setting up, upgrading and expanding accounts. (SEC)
That is the critical idea.
PLS is not a funnel that eventually replaces self-service. It is a routing system that decides which journey each customer needs.
Atlassian learned the same lesson from the opposite direction
Atlassian is especially interesting because its historical identity was almost aggressively anti-enterprise-sales.
Its early model revolved around transparent pricing, free trials and online purchasing. No armies of quota-carrying reps performing ceremonial PowerPoint demonstrations of Jira.
By 2025, however, Atlassian’s model had evolved.
Its 2025 Form 10-K describes a deliberately hybrid approach. New customers still land primarily through an automated self-service flywheel. But Atlassian says it increasingly relies on direct sales once a customer reaches sufficient scale, with sales focused on expanding into more teams, selling additional apps and moving accounts into higher-value editions. (SEC)
This is an important economic principle for PMs designing PLS systems:
Sales attention is a scarce resource.
A $150,000-a-year account can support things a $49-a-month account cannot: discovery calls, solution engineers, procurement negotiations, security reviews, custom rollout plans and executive engagement.
The product therefore needs to do more than detect “interest.”
It needs to detect economic justification for human involvement.
Zoom offers an unusually concrete example. In 2024, the company moved approximately 26,800 lower-MRR customers away from direct sales, reseller or partner coverage and back into its Online category. Zoom said the change did not have a material impact on the percentage of revenue coming from Enterprise versus Online customers, net expansion or online churn. Zoom disclosed the change in its SEC filings. (SEC)
Think about what that implies.
Having a salesperson attached to an account is not automatically better.
Sometimes the sophisticated GTM decision is to remove the salesperson.
Stop obsessing over PQLs. Enterprise software is bought by accounts.
One of the first mistakes companies make when implementing PLS is building everything around the individual user.
That makes sense in consumer products. It often makes much less sense in B2B.
Suppose one engineer from a Fortune 100 company signs up, logs in every morning and uses your product obsessively.
Interesting? Absolutely.
Enterprise opportunity? Maybe.
Now suppose 43 people from the same company have appeared within two weeks. They span engineering, product, security and operations. Five separate teams exist. Three admins have visited your SSO documentation. Usage has doubled week over week. The account is approaching a free-tier limit.
That is a rather different animal.
Enterprise purchasing happens at the organizational level, which is why the more useful abstraction is often a Product-Qualified Account, or PQA.
Even in the 2022 Pocus data, only 17% of respondents were tracking PQAs, reflecting how immature account-level PLS measurement still was at the time. (Pocus)
Modern B2B analytics tooling increasingly reflects this shift. Mixpanel’s Account Analytics model, for example, aggregates individual behavior into account profiles so companies can measure adoption, active-user counts, feature usage, retention and revenue at the company level rather than treating every user as an isolated organism floating through cyberspace. (Mixpanel)
For a PM, this means your PLS architecture starts with identity.
You need to know which users belong together.
Build the enterprise signal graph
The basic PLS data model should combine four kinds of evidence: fit, value, momentum and intent.
Fit tells you whether the organization resembles the customers you can serve economically: employee count, industry, geography, technology environment, regulatory requirements and potential contract size.
Value tells you whether users are actually accomplishing something meaningful. Ignore vanity activity such as logins whenever possible. Instead track behaviors associated with customer outcomes: publishing a project, running a production workload, collaborating with teammates, creating a dashboard that gets reused, processing transactions, deploying an integration—whatever “value received” means for your product.
Momentum measures organizational spread. Are active seats climbing? Are invitations accelerating? Are new departments appearing? Is usage becoming more frequent? A 50-person account with rapidly accelerating adoption can be much more interesting than a 5,000-person corporation containing one lonely enthusiast.
Intent captures behaviour suggesting that self-service may soon become insufficient: repeated pricing-page visits, approaching usage limits, viewing enterprise documentation, attempting to configure SSO, exploring permissions, requesting invoices, examining audit logs, asking about data residency or clicking “contact sales.”
This is where product telemetry gets genuinely useful.
A simple starting score might look like this:
Signal family
Example evidence
Illustrative weight
Product value
Core workflow completed repeatedly
30%
Organizational breadth
Multiple active users, teams or departments
25%
Adoption momentum
Rapid seat or usage growth
15%
Enterprise intent
Pricing, SSO, security, admin or limit signals
20%
ICP fit
Size, industry, geography, expected ACV
10%
Those weights are deliberately illustrative. Copying somebody else’s PQA formula is roughly as sensible as copying somebody else’s eyeglass prescription.
Your job is to discover which signals predict your outcomes.
Mixpanel recently published a particularly useful real-world account of how it built its own product-led data infrastructure. The company connected product behavior with Salesforce account IDs, identified product milestones correlated with value, detected usage caps and signup surges, and pushed qualified accounts back to its sales systems. Its later analysis joined sales, marketing and product data in BigQuery and compared conversion across ICP and non-ICP accounts. (Mixpanel)
That is far closer to the architecture PMs should be thinking about than “add a field called PQL Score to Salesforce.”
The most valuable PLS signals are often product problems
Here is where the PM role gets especially interesting.
The strongest enterprise buying signals frequently appear when bottoms-up adoption collides with organizational complexity.
Twenty employees have independently created accounts using the same corporate domain.
Suddenly IT wants centralized control.
Five teams are sharing sensitive information.
Suddenly security wants auditability.
Employees keep joining and leaving.
Suddenly administrators want SCIM provisioning.
Data is crossing borders.
Suddenly legal wants residency controls.
Teams are buying seats on individual corporate cards.
Suddenly finance wants consolidated billing.
These are not merely “sales signals.” They are product requirements.
Look at Figma’s Enterprise plan: SAML SSO, SCIM provisioning, workspaces, administrative controls and security capabilities sit alongside the core creative product. Its organization administrators can control domains, login methods, provisioning, seats, billing and access. (Figma Help Center)
Slack followed a similar pattern. Its original S-1 said:
“We complement our self-service strategy with a focused direct sales effort targeted at organizations with existing organic adoption of Slack.”
Slack then invested in Enterprise Grid capabilities such as administration, security and compliance. Its current enterprise offerings include controls around audit logs, data loss prevention, information barriers, domain claiming, retention and other enterprise requirements. Slack’s plan comparison shows how those capabilities increase with organizational complexity.
That suggests a useful PM principle:
Your enterprise roadmap should solve the problems created by successful bottoms-up adoption.
That is much more strategic than compiling a list of features requested by whichever enterprise prospect shouted loudest last quarter.
Build the “seller cockpit,” not just the alert
Once you identify a strong PQA, resist the temptation to send sales a notification reading:
HOT PQL — SCORE 87
That conveys roughly the same strategic insight as a smoke alarm.
The seller needs context.
A good PLS handoff should explain what is happening inside the account: how many active users exist, which teams are growing, who appears to be the internal champion, which workflows have reached value, which enterprise features have been explored, whether the account is approaching a limit, whether usage is accelerating or declining, and why the system believes human intervention might help.
Imagine an AE opening an account and seeing:
Acme Corp: 47 weekly active users, up 81% in 14 days. Five teams active. Three users visited SSO setup. Workspace at 92% of plan limit. Sarah Chen invited 19 users and appears to be the internal champion.
Now the opening conversation can be:
“Would it help if we showed you how other companies centralize provisioning before adoption spreads further?”
Instead of:
“Hi Sarah! I noticed you use our product. Do you have 30 minutes for a quick chat?”
Nobody has ever believed that call will be quick.
The difference is not cosmetic. The first approach is sales-assist. The second is surveillance with Calendly attached.
Give customers a hand-raiser everywhere friction appears
The best PLS systems do not depend entirely on sellers deciding when to intervene.
Let customers summon help.
A PM can add contextual human escalation at exactly the moments where complexity increases: upgrading a large workspace, configuring SSO, reaching a usage limit, inviting dozens of users, requesting security documentation, setting up multiple departments, evaluating migration tools or trying to understand enterprise pricing.
The CTA should match the problem.
“Talk to sales” is generic.
“Plan a company-wide rollout” is useful.
“Discuss security requirements” is useful.
“Get help consolidating 14 workspaces” is extremely useful.
The product knows what the customer is trying to accomplish. Use that context.
This also reconciles the apparently contradictory buyer research. Customers can remain happily self-directed when self-service works and request expertise when they encounter a problem where expertise creates value.
Sales becomes an optional product capability.
That is a much healthier relationship.
The dangerous metric nobody talks about: assisted revenue that would have happened anyway
Suppose your PQA model identifies 1,000 highly engaged accounts.
Sales contacts them.
Thirty percent purchase.
Champagne! Gong! LinkedIn post!
Except perhaps 28% would have purchased anyway.
This distinction is enormously important.
A PQA model can be excellent at predicting who will buy while being useless at determining who needs sales assistance to buy.
Those are different questions.
From a product experimentation perspective, the second is the more interesting one.
Where operationally feasible, hold out a percentage of qualified accounts from proactive outreach and compare outcomes. Test different score thresholds. Test timing. Compare product-only conversion against sales-assisted conversion. Examine contract value, sales-cycle duration, retention and expansion—not merely meeting-booked rates.
You are trying to measure incremental lift:
Sales-assist value = outcome with assistance − expected outcome without assistance.
If extremely high-intent customers convert equally well without help, leave them alone.
If medium-intent enterprise accounts convert dramatically better when a solution engineer appears after a security signal, invest there.
This is where a mature PLS team moves beyond lead scoring into resource allocation.
The goal is not to create the maximum number of PQLs.
The goal is to deploy scarce human attention where it changes the outcome.
Metrics: measure the system, not the vanity funnel
A PM running PLS should refuse to accept “number of PQLs” as the primary success metric.
You can increase PQL volume tomorrow. Lower the score threshold. Congratulations—you have invented MQLs again.
The more meaningful scorecard connects product behaviour to economics.
At the top of the funnel, measure the share of qualified accounts that reach genuine product value, the precision of your PQA model and how frequently sellers accept versus reject the opportunities generated.
Through the sales funnel, measure PQA-to-meeting conversion, PQA-to-opportunity conversion, assisted win rate, average contract value and sales-cycle length.
Then follow customers after purchase: expansion, net dollar retention, adoption breadth and churn.
Finally, measure the cost side. How many seller hours did the motion consume? What proportion of customers would probably have converted without human involvement?
A powerful north-star candidate is therefore something like:
Incremental gross profit generated per hour of sales-assist capacity.
It is not as Instagram-friendly as “10,000 PQLs this quarter,” but CFOs tend to recover remarkably quickly from the disappointment.
PM and Sales need a feedback loop, not a weekly argument
The final component is organizational.
Sales must be able to tell Product why a PQA was wrong.
Product must be able to see why qualified accounts were lost.
Customer Success must report what happened after the contract.
Marketing must know which accounts arrived with meaningful intent.
RevOps must ensure the data survives the journey across systems without becoming an archaeological expedition.
And PM should regularly examine patterns in lost enterprise deals.
If 40% of promising accounts hit a security requirement you cannot satisfy, that is roadmap data.
If customers repeatedly require a sales call merely to understand pricing, that may be a pricing UX problem.
If sellers repeatedly rescue users who cannot complete onboarding, that may be an activation problem masquerading as a sales opportunity.
If enterprise prospects consistently need an expensive solution engineer to configure something that could be automated, congratulations: you may have discovered a product feature worth millions.
Sales conversations are not noise surrounding the product.
They are product research occurring unusually close to money.
A practical 90-day PLS roadmap for PMs
A PM starting from scratch does not need a machine-learning propensity model, a 14-tool RevOps stack and a newly hired Vice President of Acronyms.
A sensible first 90 days can be surprisingly pragmatic:
Define value first. Identify the behaviours most associated with activation, conversion and retention. Interview Sales and Customer Success, but verify their beliefs against actual product data.
Create an account identity layer. Group users by workspace, company, verified domain, CRM account or another reliable organizational identifier. Preserve the ability to drill from account behaviour down to individual champions.
Instrument enterprise signals. Add events for invitations, workspace growth, usage limits, pricing exploration, administrative settings, security documentation, SSO, integrations, billing and other high-intent behaviours.
Build a first PQA model. Combine product value, organizational breadth, momentum, enterprise intent and ICP fit. Start rules-based; sophistication can come later.
Create a contextual handoff. Push not only the account and score into your CRM but also the reason the account qualified and the specific customer problem worth discussing.
Add contextual hand-raisers. Give users obvious ways to request human help at high-friction moments without forcing everyone through sales.
Run controlled experiments. Compare different trigger thresholds, messages and timing. Where possible, maintain a holdout group so you can measure incremental lift rather than flattering correlation.
Feed revenue outcomes back into Product. Won, lost, churned and expanded accounts should continuously reshape your qualification model and enterprise roadmap.
By the end of that period, you will not have “finished PLS.”
You will have something more valuable: a learning system.
The PM’s real job in Product-Led Sales
The temptation is to see Product-Led Sales as a clever mechanism for converting free users into enterprise leads.
That undersells it.
The deeper opportunity is to connect three things that traditional software companies often keep embarrassingly separate:
what customers do, what customers need and what customers will pay for.
Product sees behaviour.
Sales sees organizational intent and procurement complexity.
Customer Success sees whether the promised value actually survived implementation.
PLS works when those signals become one system.
The best product-led companies are already moving in this direction. Figma lets the product spread organically and then uses direct sales to scale larger deployments. Atlassian automates as much of the customer journey as economics permit and introduces direct sales as accounts become sufficiently valuable and complex. Slack built enterprise sales on top of bottoms-up adoption. Zoom has even demonstrated the reverse move—removing lower-value customers from direct coverage when human attention no longer made economic sense.
None of those companies abandoned product-led growth.
They completed it.
Because enterprise customers do not wake up one morning, throw away their credit cards and suddenly become “sales-led.” Their needs evolve. One user becomes a team. A team becomes five teams. Five teams become a security concern, an identity-management problem, a procurement event and—eventually—a very large contract.
The PM’s job is to design the product so the company can recognize that transition.
Not too early, when a salesperson merely becomes friction.
Not too late, when an internal champion is drowning in security questionnaires.
At exactly the moment when the product has proven its value—and the next obstacle requires something more than another tooltip.
That is Product-Led Sales at its best.
The product earns the customer.
The data identifies the opportunity.
And the human helps close the gap.