Community-led growth: Serve a group that already gathers

“Let’s build a community around our product” is the most common version of this idea and the one that reliably fails. Nobody wants to join a community organized around a vendor’s software. They already belong to communities organized around their work, their craft, or their problem, and those existed long before you did.

The companies that get this right did not create a group. They served one that was already there, better than the alternatives, until it gathered around them.

What is community-led growth?

Community-led growth is a PLG pattern where the people who use your product support, teach and recruit each other, so acquisition and support both get cheaper as the group grows. It works through peer credibility, which is why it converts better than anything you can say about yourself.

The distinction from adjacent patterns is who is talking and why:

The trade is unusual: community-led growth is the cheapest channel to run and the most expensive to start, because the thing you need most is time and the one thing you cannot buy is credibility.

Why “build a community” fails and “serve a community” works

The failure has a single cause. A community needs a reason to exist that is not your product, because nobody’s identity is “customer of a mid-market SaaS tool.” A group of people who happen to have bought the same software is a mailing list.

What works is inverting it. Find the group whose work your product is genuinely about, and become useful to them on their terms, in the places they already gather. That is also why this pattern rewards a narrow product: a tool for everyone serves no identity, and identity is what people actually gather around, the same way scarcity signals belonging rather than value.

Discord is the clearest version, because it made itself infrastructure, not a destination.¹ Communities build on Discord, so the server belongs to whoever runs it, not to Discord. Members promote their own space, and taking part requires an account of your own. Discord’s growth is a by-product of other people’s communities succeeding, which is a far more durable arrangement than asking people to care about you.

Figma shows the other half: give contribution a payoff for the contributor. By the time it filed to go public, most of its monthly active users were not designers.² The filing does not say why they came, but the shape of the product suggests an answer: much of what a non-designer opens in Figma was made by somebody else, in files, plugins and templates other users published. A designer’s Figma profile doubles as a portfolio, so publishing something is career work, not a favor to a vendor. When contributing advances the contributor, you stop having to motivate it.

Both are the same principle. Discord gave communities ownership. Figma gave contributors credit. Neither asked anyone to care about the company.

One place a community already exists is education. Students are a group with no budget, no procurement process and a shared identity that has nothing to do with any vendor, and they graduate: the ones who learned on your tool carry it into workplaces that never evaluated it. Two things decide whether you can serve them at all, and both are product decisions rather than marketing ones: running in a browser, so nothing needs installing on a locked-down school machine, and a free tier generous enough that a teacher can adopt it without asking anyone for money.

A community forms around a use case, not a product. A community of people getting better at project planning has a reason to exist; a community of people who use your project planner does not, and the second is what most companies build.

The categories where this reliably works share one thing, a user with a public identity: developer tools whose users are already in public, learning platforms whose users form cohorts (Duolingo, Replit), and flexible tools whose power users build setups worth showing off. That last group is a pattern in itself, since depth of customization is what generates something to show.

Which also tells you when to stop. If you cannot name a thing your users would want credit for, or a group they already belong to that has nothing to do with you, there is no community here to serve and no amount of budget will create one. The same is true of products people use briefly and rarely: there is no peer learning to be had about a tool that takes four minutes to master. Products in that position get their word of mouth somewhere else: from artifacts their users publish, or from the product reaching non-users during ordinary work.

The part nobody budgets for

Community-led growth is slow in a way that ends most attempts before they work.

Practitioners tend to describe the same shape: some activity within a few months, business impact much later if at all.³ Every part of that is soft, and that is the point. Nobody can tell you when it will pay off, so it gets funded like a campaign and canceled like one.

Two other ways it goes wrong, both quieter:

An empty room is worse than no room. A Discord with forty members and no conversation actively signals that nobody uses your product. If you cannot seed genuine activity, do not open the door.

You do not control what gets said. A real community discusses your bugs, your pricing changes, and your competitors, in public, in a space you created. That is the cost of credibility, and companies that try to moderate it away destroy the thing that made it valuable.

The metric that predicts community health

Community programs are usually measured by member count, which tells you nothing: a group can be large and dead.

The better signal, and the one worth instrumenting, is invitations. Track how many other people each user brings in. Someone who invites a colleague has already decided the product is worth their reputation, which is a stronger statement than any survey response. It is also, unlike most engagement metrics, free to collect: the product already knows who invited whom.

The observation is not ours: ClickUp, the project-management tool, is reported to have found invitation count a better predictor of retention than any registration metric.⁴ The reason to trust it is that the causation runs the right way. Nobody stakes their credibility on a tool they are not already getting value from, so the invitation is downstream of the value rather than a prediction of it. That makes it a product-qualified signal rather than an engagement number.

Three things in your own data will tell you sooner:

1. Do community members retain better than non-members? Segment your cohorts. If they don’t, you have a venue, not a community, and the churn problem sits somewhere else entirely.
2. What share of questions get answered by someone who does not work for you? That ratio is the whole economic argument for the channel, and it should climb every quarter.
3. Is the invitation rate rising or flat? Flat means you have an audience. Rising means you have a loop.

If you are going to build one anyway

1. Find where they already are before building anything. Search for your product’s category on Reddit, Discord, and Slack. If people are already discussing the problem without you, that is your community and you do not own it.
2. Pull your top 1% by usage and talk to ten of them this week. Community leaders are found, not appointed, and they already exist in your usage data.
3. Make contributing pay the contributor. Public profiles, credited work, genuine visibility. If contribution is a favor to you, it stops when enthusiasm does.
4. Instrument invitations now, even if you do nothing else on this list. It is the leading indicator, and it is cheap to capture and impossible to reconstruct later.
5. Agree the review horizon before you start. Get it in writing that this is judged over years, not quarters, or accept that it will be canceled the first time someone sensible audits the roadmap.

None of this is content marketing, and the difference is who is talking. Content marketing is you, at scale, and its output stops the week you stop paying for it. This is other people, and its output compounds, which is also why it is so much slower to start.

Ownership and credit are two things you can hand over. There is a third, and it is the most literal: the code itself, published so that anyone can read it, run it, and leave whenever they like. Open source makes that the whole strategy, and the economics are stranger than they look.

Updated August 2026