Product-led growth sounds simple. Let the product sell itself. Give users a free trial or a freemium tier. If the product is good enough, people will upgrade.
Slack, Figma, Dropbox, Calendly. The case studies write themselves.
Except the conversion numbers tell a different story. The average free-to-paid conversion rate for product-led growth companies sits around 9%, according to ProductLed’s benchmarking data. That means 91% of users who try the product do not pay for it. For most business models, 91% attrition would be alarming. In product-led growth, it is treated as normal.
That gap between the promise and the maths is worth examining. Product-led growth works. It also has structural limits that the standard playbook rarely acknowledges.
What product-led growth actually means
Blake Bartlett at OpenView Partners coined the term in 2016. The core idea is that the product itself drives customer acquisition, activation, and retention. Instead of running outbound sales or paid ads, the company makes the product so useful that users invite colleagues and expand usage on their own.
This is different from sales-led growth, where a sales team finds prospects and guides them through a buying process. It is also different from marketing-led growth, where campaigns fill a pipeline that sales then closes. In product-led growth, the product is the pipeline.
The appeal is clear. When the product acquires users on its own, acquisition costs drop. Users who expand usage before talking to sales shorten the sales cycle. A product that delivers value before the buyer commits budget reduces risk for both sides. In theory, everyone wins.
This post looks at why the reality is messier. It covers why conversion rates stay low, what PLG demands from an organisation, and how to assess whether the model fits. It does not cover PLG tooling, pricing strategy, or free tier design.
Why the conversion rate is structurally low
A 9% average conversion rate is not a failure of execution. It is a feature of the model. Product-led growth deliberately casts a wide net. Free tiers attract users who would not have entered a traditional sales funnel at all.
Many of them are curious, exploring, or solving a one-off problem. They were not going to pay regardless.
This is not necessarily bad. Those free users still generate network effects, word of mouth, and brand awareness. Slack’s free tier created millions of daily active users who told their colleagues.
Many of those colleagues worked at companies that later bought paid plans. The free users were not waste. They were distribution. The same pattern shows up at Calendly, Notion, and Loom. Free usage spreads the product into places a sales team could not reach.
The problem arises when teams treat the 9% as a metric to optimise on its own. Adding friction to the free tier, gating features, or nudging with aggressive in-app prompts can lift short-term conversion. But they degrade the product experience that made growth possible. The very thing that drew users in gets weakened to push them towards paying.
The Figma example
Figma is often cited as the best product-led growth example. Adobe agreed to buy it for $20 billion in 2022, but both sides abandoned the deal after regulatory opposition. Figma’s free tier was generous. Designers used it, invited developers to comment, and those developers showed it to project managers. Usage spread across teams before anyone started a buying process.
What is less often discussed is that Figma also had a sales team. By the time of the Adobe deal, Figma had account executives working enterprise buyers. The product opened the door. Sales closed it. This hybrid model, often called product-led sales, is now the norm rather than the outlier.
Product-led growth as an organisational design problem
Most writing about product-led growth treats it as a go-to-market strategy. Choose PLG or choose SLG. In practice, it is an organisational design choice that affects every function.
Product-led growth requires product, engineering, data, and growth teams to work in tight step. The product must track activation, engagement, and expansion signals in real time. Engineering must build self-service features (onboarding, billing, team tools) alongside the core product. Data teams must find which behaviours predict conversion and feed those signals back, creating the kind of disciplined feedback loop that separates guessing from learning.
Most organisations are not set up this way. Product and engineering report into separate chains. Data teams serve many masters. Growth is a buzzword rather than a function with clear ownership. The result is friction where there should be flow.
Adopting product-led growth without changing the org chart produces a familiar pattern. The company ships a free tier, waits for growth, and wonders why the numbers do not look like Slack’s.
What the organisational model requires
A product-led company needs three things most companies lack. The most foundational is a shared view of the activation event, the action that predicts long-term retention. The commonly cited examples are Slack (a team sending 2,000 messages) and Dropbox (uploading a first file). If the team cannot name it, the product-led model has no base to build on.
Closed-loop data is equally important. Every user action from sign-up to upgrade must be tracked, studied, and fed back into product choices. This is ongoing operational work, not something a team builds once and walks away from.
The third requirement is clear ownership of the conversion funnel. In a sales-led company, sales owns the funnel. In a product-led company, nobody owns it unless the org makes a deliberate choice. The gap between sign-up and paid conversion is a product problem, an engineering problem, and a data problem at once. Without end-to-end ownership, it falls between the cracks.
Where product-led growth breaks down
Product-led growth works best when a few conditions hold. A single user must be able to get value before involving their organisation’s buying process. Time to value must be short. The product must make sense without a demo or a sales call. If any of these fail, the model breaks.
When these conditions do not hold, product-led growth struggles. Enterprise infrastructure tools, compliance software, and products that need integration with existing systems all face the same problem. The user cannot get value without organisational buy-in first. A free trial of a database migration tool is useless if IT must approve the connection.
This does not mean PLG is irrelevant for complex products. It means the model needs adapting. Many enterprise companies use a product-led approach for developer tools or team-level features while keeping a sales-led motion for large contracts. GitLab offers a free tier that developers use on their own. A separate sales team handles large deployments.
The metrics that matter in a product-led model
Product-led growth introduces metrics that traditional SaaS models do not prioritise. The most important ones are not revenue metrics. They are behavioural.
Time to value measures how fast a new user reaches the moment the product is useful to them. If this takes days rather than minutes, product-led growth will fall short no matter how good the product is at scale.
Activation rate measures the share of new sign-ups who reach the activation event. A low activation rate points to onboarding problems, not product problems. If users sign up but do not reach the moment of value, the product may be fine but the path to it is broken.
Natural rate of growth, a metric developed by OpenView, scores how much of a company’s growth comes from organic, product-driven channels. It combines ARR growth rate, share of organic sign-ups, and share of revenue that starts in the product. A high natural rate of growth is the strongest signal that the product-led model is working.
A practical assessment framework
Before committing to product-led growth, a product team should answer five questions honestly.
Can a single user get value from the product without involving procurement, IT, or a manager? This one carries the most weight. If the answer is no, the self-service model has no foundation and the other four questions are moot.
Can the team name the activation event? If no single action predicts retention, the team does not yet understand the product’s value well enough to build a funnel around it.
Is time to value measured in minutes or days? Products where first value takes weeks are better suited to guided trials with sales support.
Viral loops matter too. Does the product have a natural sharing or collaboration mechanism, such as inviting teammates, sharing documents, or commenting on work? These are what turn free users into distribution. Without them, the free tier is a cost centre.
Finally, is the organisation willing to invest in instrumentation, not just features? Product-led growth needs closed-loop data from sign-up to expansion (for more on choosing metrics that inform decisions, see this guide to data-driven product management). If the engineering and data teams are not staffed for this, the model will not produce useful signals.
If the answer to three or more of these is no, a sales-led or hybrid model is likely a better starting point. Product-led growth can be added later as the product matures.
Quick reference checklist
- A single user can get value without procurement or IT involvement.
- The team can name the activation event that predicts retention.
- Time to value is measured in minutes, not days or weeks.
- The product has a built-in sharing or collaboration loop.
- Engineering and data teams are staffed for closed-loop instrumentation.
Product-led growth is not a shortcut. It trades the cost of a sales team for the cost of building a self-service product, real-time data systems, and cross-team coordination. For the right product and team, that trade pays off well. For the wrong one, it is an expensive way to learn that giving away your product does not mean anyone will pay for it.
The five questions above are a reasonable litmus test. If three or more come back negative, a hybrid model is probably the more honest starting point.