PLG didn't fail you. You adopted someone else's conditions.

For most of the history of SaaS, the path to revenue ran through a human being.

Someone had to run the demo. Someone had to handle the procurement conversation. Someone had to be on the other end of the phone when the enterprise buyer had a question at eleven in the morning on a Tuesday. Growth was a people problem. You hired your way to it.

Every day, sales teams across the industry did the same thing. They qualified leads, managed pipelines, and personally guided buyers from interest to contract. It was expensive, it was slow, and it was the only model most companies knew.

Until a handful of companies proved it didn't have to be.

Slack. Dropbox. Figma. Notion. The list became a canon. Products that grew without a sales team. Users who signed up, found value, invited colleagues, and converted to paid without ever speaking to a human. The product did the growing. The numbers were real. The case studies were detailed and convincing.

Because of that, product-led growth became the defining growth strategy of the early 2020s. Conference talks. Frameworks. Playbooks. Entire consultancies built around helping teams make the transition. The logic was simple: if it worked for them, it can work for us. The model was sound. The results were documented. Why would you keep paying sales reps when the product could do it better?

Because of that, teams across the industry rewrote their growth strategy. Free tiers appeared on pricing pages that had never had them. Onboarding flows were redesigned for self-serve. Sales teams were reduced or repositioned. Product teams were handed growth metrics they'd never owned before and told to build toward them.

Until finally, the results started coming in.

And they weren't what the case studies had suggested.

I've sat with four different product teams this year who adopted PLG between eighteen months and two years ago. All four are having the same conversation, just in different rooms. The numbers are moving, but not fast enough. The free tier is attracting users who aren't converting. The self-serve onboarding that looked clean in testing is producing a dropout rate nobody predicted. The viral loop that worked so visibly at Slack, where a user invites a colleague and the colleague invites a team, isn't firing.

The teams are all asking the same question: what are we doing wrong.

But that's not quite the right question.

There's a version of franchising that works and a version that doesn't, and the difference is almost never about execution.

The version that works starts with a restaurant that has something genuinely replicable at its core: a recipe, a process, a supply chain that can be reproduced across locations without losing what made the original worth copying. The franchise model scales the replicable parts. The original restaurant's specific chef, its neighbourhood regulars, the particular energy of a room that took five years to build: those don't franchise. They were never meant to.

The version that doesn't work starts with a restaurant that was successful for reasons that are specific, local, and deeply tied to conditions that can't be transferred. The food is good. The model looks scalable from the outside. But what made it work was never in the recipe.

PLG adoption followed the same logic at scale. Teams looked at Slack and saw a product that grew virally and concluded: viral growth is the output of PLG. Implement PLG, get viral growth. But viral growth wasn't the output of PLG at Slack. It was the output of a product where the core value was inherently collaborative, where using it alone was noticeably worse than using it with others, and where inviting a colleague was a natural step in getting value rather than a growth tactic bolted onto an existing workflow.

That's a structural condition. Not a playbook.

Dropbox grew because sharing a file was a built-in use case, and every shared file was an advertisement. Figma grew because design feedback required the reviewer to be inside the product. The viral loop wasn't engineered on top of these products. It was baked into the reason they existed.

Most products don't have that. And most PLG playbooks don't mention it.

The structural conditions that made PLG work at its canonical examples are specific enough that they're worth naming directly.

The product has to be genuinely better with more people in it. Not marginally better. Noticeably, immediately better in a way the user feels in the first session.

The free tier has to create real value, not a preview of value. A free tier that gives users enough to understand what they're missing is a trial. A free tier that gives users enough to solve a real problem is a growth engine. They behave completely differently.

And the upgrade moment has to be a natural consequence of the user succeeding, not a gate placed in front of their progress. When a Notion user hits the block limit, they've already built something they don't want to lose. The conversion is a protection decision, not a purchase decision. Those are different psychological states and they produce different conversion rates.

Most products asking users to upgrade are asking them to make a purchase decision before the user has a reason to care. And then wondering why the conversion rate looks the way it does.

This isn't an argument against PLG. It's an argument for reading the case studies more carefully than the industry has been.

The companies that proved PLG were not proving that any product can grow without a sales team. They were proving that products with specific structural characteristics, natural collaboration, inherent virality, and a free tier that solves rather than teases, can grow without a sales team. That's a narrower claim. And it's the claim that got lost somewhere between the conference talk and the roadmap rewrite.

The teams I've worked with who are struggling with their PLG numbers are not failing at execution. They are succeeding at implementing a motion their product was never built to support.

The honest question isn't what are we doing wrong. It's whether the conditions that made this work elsewhere were ever present here. And if they weren't, whether the product can be reshaped until they are, or whether a different growth model fits the actual structure of what was built.

That question is harder to ask after eighteen months of investment in the wrong direction.

But it's the right question. And the teams asking it now are already ahead of the ones who are still optimising the onboarding flow.