Classifying Communities with the 3Ps: Product, Practice, and Play

How can the word “Community” mean so much and so little at the same time?

Kubernetes is a community. My small fencing club in San Francisco is a community. A large subset of Orbit’s customers are a community as well, sharing tools and tactics to help each other become better community builders.

Today, Orbit has more than 2,500 users managing more than a thousand communities across the world. And boy are they diverse.

After chatting with hundreds of customers and non-customers alike about “community,” I’ve realized that we need a more specific taxonomy to articulate what we’re actually talking about when we use our favorite word. A way to quickly get on the same page about our situation.

If it works, we can all identify the kinds of community we’re building, with the hopes of more efficiently communicating the context.

Taxonomy, by the way, is just a fancy word for classification, so in this post, I’d like to share my working 3-part classification of community types.

The 3 Community Ps

There are a million ways to segment communities, but my approach is to describe the community type based on the motivation for the community members. In other words, why are they here?

I think there are three kinds of communities based on three motivations:

Communities of Product, Practice, and Play.

Hat tip to Corinne Marie Riley’s blog post, which I think was the first thing I read that made the product/passion distinction. It’s worth a read.

As we’ll see below, some communities are entirely focused on Product, Practice, and Play, but most demonstrate elements of each. The key is assessing your community and moving towards an accurate description of the ways things are today, and potentially identifying gaps in the nature of your community today versus where you’d like to be.

Communities of Product

Members of these communities are focused primarily on discussing and learning about a specific product. The Airtable Community Forum is a great example, where folks dive deep into questions about automation scripts and templates, as well as show-off their custom-build Airtable creations.

Communities of Practice

Folks in these communities are all about leveling-up their craft and connecting with other practitioners, independent of any tools or platform. Think design communities like Dribbble or Behance, or Slack groups focused on professional development, or communities like On Deck, where folks come together to network and learn.

Communities of Play

Members of this category are interested in topics not directly related to specific products, professional development, or networking. Rather, they come together around a common interest, like sports, gaming, athletics, and more.

Large gaming discords are a great example, as are groups focused on music or cooking.

This category is admittedly a bit of a catch-all, but I think whatever we could put here would be fundamentally more similar to one another than to communities of either product or practice.

How would you describe your community?

With this taxonomy in mind, you can now assess and discuss your community with a bit more precision. But that doesn’t mean you have to pick only one category.

As mentioned above, most communities will incorporate elements of each, and I think a great way to describe your community is to think about the distribution of member expectations.

For example, there are around 500 people in the Orbit community today, and I’d say it’s about 70% Product and 30% Practice. In other words, 70% of the conversations are focused on our product — discussing ideas and best practices, sharing things folks have built with our API, and getting support. The remaining 30% is about community building and DevRel tools and workflows, sharing relevant news trends, and generally sharing ideas about more effective strategy tactics.

If we were to diagram this distribution, it would look like this:

If we plotted the distribution of other example communities, they may look like this:

Using the 3Ps

There are a couple of ways this framework can be applied.

Communicating the kind of community you’re building

When I have a conversation with a community builder, I start by asking what type of community they’re building. Talking to an indie builder about their community of practice really is different than speaking with a DevRel manager about their product-centric community.

Their motivations may be similar, but the tools and tactics for each are quite different, as are the overall strategies. The former may be thinking about monetizing the membership, and the latter may be thinking about the relationship to larger questions of business ROI.

So understanding their community’s classification helps us arrive at a shared understanding of what they’re trying to accomplish, and leads to more fruitful discussions overall.

Assessing the gaps in your community strategy

Finally, the framework can be used to assess your situation today, and to describe the ideal distribution you’re shooting for. For example you may find that your community is mainly focused on product support discussions, but you’d like to start incorporating more practice-style interactions as well.

You might then compare where you are today versus where you want to be by the end of the year:

Now, you and your team can build plans and programs to close the gap, and assess your progress over time.

Towards a more useful community taxonomy

One mark of a good taxonomy is that it should be MECE, which means that all categories should be mutually exclusive and comprehensively exhaustive. I think this 3-part system largely accomplishes that, but I would love idea and input to help us continue refining.

If you have questions for feedback, join the Orbit community on Discord, or send me a DM on Twitter @patrickjwoods.