STRONG Product Communities

Communities of Practice: The Essentials

A community of practice is a group of people who share a craft and deliberately meet to get better at it together, not an accidental byproduct of working at the same company. The term has real academic roots: Jean Lave and Etienne Wenger coined it in their 1991 book on situated learning, and Wenger formalized it further in 1998.

For this book, that means internal groups of product people inside one company, occasionally a single community spanning several companies, never a customer or user community.

Product management doesn't have a fixed, licensed body of knowledge the way accounting or law does. Peer learning fills a real structural gap that no onboarding program or formal training track fully covers, especially at a company hiring product managers faster than it can build a shared culture and vocabulary among them.

The value case rests on a handful of concrete outcomes: stronger engagement and retention among product people, a shared set of practices and language across product teams that would otherwise stay siloed from each other, and faster onboarding for anyone new to the role, since they inherit an existing peer network instead of building one from scratch.

For a working PM or product leader, the real shift this chapter asks for is treating a community of practice as a deliberate, ownable lever, something built and resourced the way a hiring process or onboarding program is, not as a nice-to-have social club that happens to exist if the culture is good enough. That distinction is what determines whether it gets real sponsorship later.

Without one, product managers tend to learn in isolation, reinventing the same lessons team by team instead of compounding what the group already knows, exactly the gap the rest of the book sets out to close, one practical mechanic at a time.

Getting Started: What Do You Need to Know?

A community of practice doesn't start with a mandate or a budget line, it starts with a minimum viable community: two or three people who are genuinely excited about the idea, meeting informally, with no official structure yet.

Once that small group is meeting consistently, the next phase is adding structure: real, if lightweight, rituals and shared learning goals, enough that the community starts to feel like something with its own rhythm rather than a one-off conversation between friends.

Only in the third phase does the community formalize, official time and budget, real leadership sponsorship, and an intentional search for allies inside the organization who can help it run. A concrete trigger point the book gives for reaching this phase: once a community grows to around 40 members and is running three or four distinct rituals, that's a reasonable moment to start asking for dedicated time and resources, since the group has already proven organic demand exists.

The sequencing matters more than any individual step. Asking for formal sponsorship before a community has proven it creates real value is a much harder pitch, and often an unnecessary one, than asking for it once a self-sustaining group of forty people already exists and simply needs more room to keep going.

For a working PM, this maps directly onto how a good internal initiative gets funded generally: prove the small version works with the resources already at hand, then ask for more, rather than pitching a fully resourced program before anyone has seen it deliver anything.

The name is a deliberate echo of a minimum viable product: start with the smallest version that can prove real value, resist the urge to make it official too soon, and let evidence, not enthusiasm alone, justify each step up in investment.

Finding allies matters as much as finding budget during the formalize phase. A single champion in leadership who understands why the community exists is often what protects it the first time a busy quarter tempts the organization to deprioritize it.

Community Guidelines

Once a community of practice is past its earliest, informal phase, this chapter's central tool, a one-page Community of Practice Canvas, exists to force the same clarity a good product one-pager does before a community drifts into an unplanned social channel with no real direction.

The canvas covers roughly a dozen prompts, but a few carry the most weight. Purpose asks what the community wants to achieve, deliberately capped at three items, so the group doesn't try to be everything to everyone. Values asks what matters to the community as a group, capped the same way.

Success definition is left as an open question rather than a prescribed metric, whether that means a high return on the time members invest, a community that doesn't depend on one or two people to keep running, or simply a safe space where people feel comfortable sharing what they don't yet know.

• Roles: who actually organizes and runs things, not left implicit.
• Rituals and rhythm: which recurring formats the community runs, and how often.
• Channel and platform: where the community actually lives day to day.
• Financing, sponsorship, and leadership support: how the community plans to become financially sustainable, once it has something worth funding.

That last category connects directly back to Chapter 2's three-phase model: the canvas treats financing and sponsorship as a question to answer once a community has already proven organic demand, not a prerequisite to get in place before starting.

For a working PM, the canvas is worth using the same way a lightweight PRD is used elsewhere: not because every box needs a perfect answer on day one, but because writing down an honest, capped purpose and a real definition of success surfaces disagreement inside the founding group before it becomes a source of quiet frustration six months in.

Regular Rituals

A community of practice needs recurring formats to actually have a pulse, and this chapter organizes them by rhythm, since different cadences do genuinely different jobs.

• Daily: something lightweight and always-on, most commonly a dedicated Slack channel.
• Weekly: shorter, informal touchpoints, an open community meeting sometimes called "Product and Friends," a Friday coffee chat where people share the week's wins and challenges, or a 1:1 lunch pairing.
• Monthly: slightly more structured formats, a themed learning session, a product team game night, an onboarding session for new members, or a recurring learning challenge.
• Quarterly: deeper commitments, a book club that reads one month and discusses the next, a full training day built around a theme with a keynote and activities, or a multi-module onboarding track for junior product people sometimes run as a "Product Academy."
• Annual: a single anchor event, typically a multi-day product summit that brings the whole community together once a year.

A few named formats recur across the book's examples beyond the rhythm ladder itself: a product teardown session, where the community analyzes another company's product together with only one person needing to prepare in advance, and a conference club, where members prepare together for an external PM conference and build outward-facing networks as a group.

A blunt but important expectation-setting point: at meaningful scale, only around 10% of members will actively attend and participate in any given session. That's normal, not a sign the community is failing, and treating it as failure is a fast way to burn out whoever is running things.

The chapter's own guidance for what makes any of these formats actually work: a real rhythm, a genuine sense of belonging, clear agendas even for informal formats, real inclusivity, explicit ground rules, and checking in with the community itself before adding or cutting a ritual, rather than deciding unilaterally.

For a working PM, the transferable habit is treating a ritual calendar the way you'd treat a feature roadmap: not every ritual needs universal engagement to be worth running, the same way not every feature needs every user, and low attendance at one specific format is a signal to adjust that format, not to shut the whole community down.

Learning from Other Product People

This chapter is a set of interviews with people who've actually built or led a product community of practice, spanning genuinely different contexts on purpose: a leader who runs a large cross-company community built around her own continuous-discovery work, alongside product leaders running internal communities at specific companies, a leader running product community efforts inside a major tech company, and an organizer of a regional, meetup-style product community chapter.

The point of gathering such different contexts side by side isn't to hand the reader one universal playbook, it's the opposite: a bank's internal product community, a big-tech internal community, and a city meetup group face genuinely different constraints, so what actually works for each of them looks meaningfully different in practice, even while some of the underlying rituals and planning tools from earlier chapters show up across all of them.

A reader looking for one clean formula from this chapter will come away disappointed; the real value is closer to a set of case studies to borrow specific, adaptable tactics from, matched to a reader's own company size, geography, and culture, rather than a single template to copy wholesale.

For a working PM building or running a community, the practical habit this chapter reinforces is deliberately seeking out someone running a community in a meaningfully different context than your own, a different company size, a different industry, a different country, since the tactic that transfers best is often the one you wouldn't have thought to try inside your own bubble.

The range itself is a lesson: a telecom carrier, a European jobs platform, a regional bank, and a city-level meetup group don't share an org chart, a budget process, or even a first language, yet each interviewee describes building the same underlying thing, a small, trusted group product people actually want to show up for.

Several of these leaders describe beginning with the same small, informal group Chapter 2's three-phase model lays out, before any of it was formalized, evidence that the sequencing described earlier isn't just theory, it's what actually happened in practice.

Digging Into the Data: My Research on CoPs

This closing chapter grounds everything earlier in the book in Wille's own survey research: 103 responses collected over roughly six months in 2022, using around 20 open-ended questions.

The headline split: 80% of respondents said they work in product and participate in some kind of community of practice, while 20% said they don't. Of the people who do participate, close to half belong only to a company-internal community, a little over a fifth belong only to an external, cross-company one, and the remaining third belong to both.

For internal, company-specific communities, respondents named a similar mix of rituals to the ones covered in Chapter 4, recurring update calls, monthly themed events, informal quarterly get-togethers, and onboarding sessions, along with a range of reward practices from formal recognition and bonus ties to nothing more than peer kudos, and in some cases outright mandatory participation with no reward attached at all.

The most consistent complaint across internal-community respondents was that too many sessions had quietly become project-update meetings, crowding out the actual learning and peer connection that motivated people to join in the first place, alongside a related complaint that over-reliance on one or two organizers, inconsistent rhythm, and too much online-only interaction all wore a community down over time.

For cross-organizational communities, the sample was explicitly smaller, 59 respondents, skewed international, and split fairly evenly between small, specialized communities and much larger ones of a hundred members or more. Most respondents who'd experienced both preferred the smaller, more specialized option, citing trust and focus over reach, though a minority genuinely preferred a bigger community precisely because its scale let quieter members participate at their own pace without much social pressure.

The most common reported benefits were skill-building, expanded perspective, networking, and a real sense of belonging; the most common reason for not participating at all was simply never having known such a community existed.

For a working PM, this chapter's real lesson is methodological as much as substantive: the same instinct that reads product usage data for a power-law pattern, a small fraction of users driving most engagement, applies directly to a community of practice, and the fix, broadening ownership and protecting real learning time from status-update creep, is a product management instinct pointed inward at your own community instead of outward at a product.

The Entire Book in One Framework

Every piece of this book connects to one underlying claim: a strong product organization isn't produced by hiring individually strong product managers, it's produced by deliberately building the structure that lets those product managers learn from each other continuously, the same way any other durable organizational capability gets built.

The three-phase build model, minimum viable community, then structure, then formalization, is the sequencing; the canvas is the planning tool that keeps that sequence honest; the rhythm-based ritual ladder is the operating cadence; and the survey data in the closing chapter is the evidence that the same failure modes, status-update creep, over-reliance on one or two organizers, and a lack of real sponsorship, show up again and again when that sequence gets skipped.

A community of practice built by fiat, top-down, fully resourced, with no organic demand behind it yet, rarely survives contact with a busy quarter. A community of practice built bottom-up, from two or three genuinely committed people to a formalized, sponsored group, is what actually lasts.

10 Most Important Takeaways

• A community of practice is a deliberate structure for peer learning among product people, not an accidental side effect of a good culture.
• Start with a minimum viable community: two or three genuinely committed people meeting informally, with no official mandate yet.
• Add structure, real rituals and shared learning goals, only once that small group is meeting consistently.
• Formalize with official time, budget, and leadership sponsorship only after the community has proven organic demand, a rough trigger point being around 40 members and three or four running rituals.
• Use a one-page canvas to force clarity before launching: a purpose capped at three items, explicit values, and an honest definition of success.
• Organize rituals by rhythm, daily for lightweight touchpoints, weekly for informal connection, monthly and quarterly for deeper learning, annually for one big anchor event.
• Expect only around 10% of members to actively attend any given session, and don't treat that as failure.
• Watch for status-update creep: the single most common complaint from real community members is that project updates crowded out actual learning and connection.
• Smaller, specialized communities are generally preferred over large, broad ones, though a bigger community has its own advantage for quieter members who'd rather participate at their own pace.
• Belonging to both an internal, company-specific community and an external, cross-company one gives the richest combination of shared culture and outside perspective.

The single deepest idea worth remembering: the health of a product community of practice is itself a product problem, with its own usage data, its own power-law participation curve, and its own failure modes, and the product management instincts that fix a struggling feature are the same ones that fix a struggling community.