How do you build a community around a product?

Genuine product communities are a byproduct of making a small number of people feel unusually understood — not a marketing initiative layered on top of a finished product. The founders who build the strongest communities start by going absurdly deep with a deliberately narrow group, then let those early believers do the evangelizing. Done right, the culture of caring for users becomes self-reinforcing long before you have the numbers to call it a community.

Start with a narrow group who feel the product is theirs

The instinct to launch broadly is almost always wrong for community-building. A product that feels made for everyone feels made for no one. Paul Graham's observation about Facebook's early strategy is instructive here: by limiting access to Harvard students first, Zuckerberg created a sense of ownership and belonging that a national launch would have diluted entirely. The specificity wasn't a constraint — it was the mechanism.

This applies to nearly any product category. Pick a slice of your potential market that is specific enough to have shared vocabulary, shared problems, and the ability to recognize each other as peers. A devtool community built around senior backend engineers at fintech companies will cohere in a way that 'developers broadly' never will. When members of your early community look around and see people who are clearly like them, they start self-identifying as part of something — and self-identification is the seed of community.

The practical implication: before you think about Discord servers or newsletters or ambassador programs, ask who your product is most specifically for. Name them. Find ten of them. Go extremely deep with those ten. Everything else follows from that.

Do unscalable things to make early users feel seen

The gap between a product people use and a product people evangelize is almost always filled by moments of being genuinely surprised that someone cared. This is where founders can do things that larger companies structurally cannot — and it's where early community loyalty is actually manufactured.

Paul Graham argues that founders who obsess over making their earliest users happy are never led astray by it. The reason is mechanical: when you treat individual users with an attention level they've never received from any company before, they don't just stay — they tell people. Not because you asked them to, but because the experience was genuinely remarkable. A handwritten note, a founder hopping on a call to walk through a problem, a feature built specifically for one user's workflow — these create stories that get told.

The objection founders raise is scale. If you do this for ten users, how do you do it for ten thousand? The answer is that you don't need to — the culture you build in those early interactions shapes how your team thinks about users permanently, and the stories your early advocates tell do recruiting work you could never do through advertising. The unscalable phase is an investment in the community's founding mythology.

Treat direct user engagement as your most valuable data source

Community is often thought of as a distribution or retention tool. It's actually your highest-signal feedback channel, and treating it that way changes how you build it. When you engage with users individually — watching them use the product, asking open-ended questions, following up on complaints — you learn things no survey or analytics dashboard will surface. Graham points out that when companies grow large enough to rely on focus groups, founders often wish they could go back to the days of sitting in users' offices watching them struggle with the product in real time.

The founders who build strong communities never fully outsource that contact. They stay in the forums, the Slack groups, the support threads — not to manage PR, but because the signal quality there is irreplaceable. A user who posts a complaint in your community forum is telling you something that dozens of silent users feel. A user who posts an unexpected use case is handing you a roadmap idea. The community becomes a living feedback mechanism only if the founding team treats it as one.

This also shapes how users perceive the community itself. When founders are visibly present and visibly responsive, users understand that participation has consequences — that what they say matters. That understanding changes the quality of what they contribute. Lurkers become posters. Critics become collaborators.

Let identity, not incentives, drive participation

Most community-building tactics — referral programs, points systems, leaderboards — try to solve a motivation problem with extrinsic rewards. They can generate activity metrics while hollowing out the actual community. The strongest product communities are ones where participation is an expression of identity, not a transaction.

This happens when the product is specific enough and good enough that using it becomes part of how a user thinks of themselves. A founder who builds a tool for a specific kind of maker, and who has gone deep enough to understand that maker's self-image, can create a community that members want to be in because it reflects who they are — not because they'll earn points for showing up.

The implication for how you structure early community spaces: prioritize depth over scale. A forum with 200 people who are all genuinely excellent practitioners of the thing your product serves is far more valuable than 2,000 casually interested users. Give members reasons to demonstrate expertise to each other. Create norms that reward quality contribution over volume. The community's reputation becomes a draw in itself — people want in because of who else is there, and that dynamic compounds in a way that incentive programs never do.

Build the community into the product, not beside it

Many founders treat community as a marketing layer that sits adjacent to the product — a Discord server here, a mailing list there. The strongest community-product relationships happen when the product itself creates reasons for users to interact with each other and with the team.

This can be structural: features that let users share their work, see what others are building, comment on each other's outputs. It can be cultural: a product that celebrates a certain kind of mastery will attract users who want to demonstrate that mastery to each other. It can be operational: a public roadmap, a changelog with genuine context, an open process for feature requests that lets users see their feedback move from suggestion to shipped.

Garry Tan's framework for good product thinking — lead with the point, tie technical choices to what the real user sees and does — applies here too. Every community touchpoint should have a clear purpose for the user, not just for the company. If the community exists to make users better at their craft, they'll come. If it exists to reduce churn or generate referrals, they'll sense it and leave.

“I have never once seen a startup lured down a blind alley by trying too hard to make their initial users happy.”

— Paul Graham, source

The one thing to do

Find the ten users who most deeply need what you built, make them feel more understood than they've ever been by a company, and let that relationship become the founding culture your community grows out of.

Frequently asked questions

When should you start building a community — before or after product-market fit?

Start before you have scale, but after you have at least one narrow user group who clearly benefits. The earliest community is really just direct relationships with your first users. Formalizing too early — launching a forum before you have ten deeply engaged people — creates ghost-town spaces that actively hurt perception.

How do you keep a product community from going quiet after the initial launch buzz?

Communities go quiet when participation stops producing value for participants. The fix is structural: create recurring reasons for members to contribute — release cycles, collaborative challenges, expert Q&As — and make sure the founding team stays visibly present so users know their participation has consequences.

Should you pay community members or moderators early on?

Paying early community contributors can shift their motivation from intrinsic to extrinsic and make their participation feel transactional to other members. Recognize and elevate your best contributors through access, influence, and status first — compensation structures work better once the community identity is already established.

How do you measure whether a product community is actually working?

Ignore raw member counts. Track how often community members refer new users without being asked, whether engagement comes from the same people repeatedly or from a broad spread of members, and whether the community generates product insights your team didn't already have. Qualitative signal — are people proud to be here? — matters as much as any metric.

Sources

More playbook answers · Growth Prophet home