Product-led growth is seductive. Let the product do the selling. Users activate themselves. Conversion happens at scale without a big sales team. It works — when the conditions are right.
Here’s the thing people don’t say enough: PLG is infrastructure. The product is the engine. But if the information architecture underneath it is broken, you’ve got a sports car with a busted GPS. Fast, expensive, and completely lost.
I’ve evaluated PLG motions at multiple companies. At Visual Layer, I cancelled a PLG motion partway through and pivoted to ABM instead. Not because PLG is wrong — because the conditions weren’t right. The self-serve path wasn’t ready, the knowledge layer wasn’t there, and we couldn’t instrument what we couldn’t see. Going PLG anyway would have been burning budget on activation we couldn’t support.
Before you commit to PLG, make sure you’ve got these three things.
1. Map your user journeys before you build your onboarding
Most PLG fails at activation. Users sign up, poke around, don’t find value fast enough, and leave. The product team calls it a retention problem. It’s actually a clarity problem.
The path to value has to be obvious. Not “it’s in the docs” obvious. Immediately obvious — in the product, at the moment the user needs it.
Map the journeys before you design onboarding. What is the user actually trying to do? What’s the first moment of meaningful value? What has to be true for them to reach it? Where do they get confused or blocked?
These are user research questions, not UX questions. You need to talk to people who match your ICP and watch them move through the product. The gaps they hit are where your PLG motion bleeds users.
Build onboarding to eliminate those gaps, not to showcase features. An onboarding that teaches users your mental model instead of solving their immediate problem is onboarding that gets skipped.
2. Build a self-serve knowledge layer that answers the questions your product raises
When a user hits a wall in a self-serve product, they can’t raise their hand and ask a rep. They Google it. They check your docs. They ask in your Slack community. If they find nothing, they leave.
The knowledge layer is the invisible sales team in a PLG motion. It includes developer docs, in-app tooltips, contextual help, a searchable knowledge base, and ideally a community where users help each other.
Most companies build this reactively — docs get written after support tickets pile up, tooltips get added after users complain, FAQs get created after the same questions appear in chat. That’s backwards.
Before you launch a PLG motion, audit what questions your product raises. Not what questions you expect users to have — what questions they actually have. Talk to beta users. Read support tickets. Watch session recordings. Then build the knowledge layer to address those questions before they become blockers.
If users have to email support to get past your activation flow, you don’t have a PLG motion. You have a leaky funnel with a support team plugging the holes.
3. Instrument your information architecture
You can’t improve what you can’t see.
In a PLG motion, the signals that matter most are often outside the product: which docs pages do users visit before converting? What do they search for in the knowledge base? What terms show up in support tickets right before churn? Where does the self-serve path break down?
Most analytics setups track product events. Fewer track content and information events. That’s where the blind spots live.
Instrument your docs, your knowledge base, your in-app help. Know which articles are read before activation and which are read by users who churn. Know what searches return no results (those are content gaps). Know which questions keep recurring in support — those are IA failures that a well-placed doc or tooltip could solve at scale.
When you can see the information architecture behaving, you can improve it. Until then, you’re optimizing the product while the floor has holes in it.
PLG is a bet you have to earn
I’m not anti-PLG. When the product is self-evidently valuable, the onboarding is tight, the knowledge layer is built, and you can see what’s happening — PLG scales in ways that sales-led growth can’t.
But it’s a bet. And like any strategic bet, it should be made with open eyes, not as a default because it worked for Slack or Figma.
Evaluate whether your users can actually find the value on their own. Evaluate whether your information architecture supports the journey. Evaluate whether you can instrument enough to learn and improve.
If the answer to any of those is “not yet,” build first. Launch the PLG motion when it’s ready to work, not when you’re hoping it will.
