Community management on a product team

The community team is a relatively new addition to the product team here at Vox Media—we’ve been around for a little over a year now—and as the team’s director, I get a lot of questions about who we are and what exactly we do. We’re going to write more about our work here in the year ahead, so I wanted to start off by sharing an overview on what our team is all about.

In short, the community team exists to advocate for the whole community of people who use the Chorus publishing platform: Vox Media editorial teams, our Chorus customers, community contributors, and audience members. It’s our job to make sure everyone has the resources and support they need to use our platform successfully. That work covers five main areas: user support, documentation, education, communication, and advocacy.

While each of these are discrete disciplines, they also build on and, well, support one another. When we approach them holistically, we can build products our users love, in ways that don’t slow them down. Here’s what that looks like.

User support

User support is the foundation of all that we do. We think of it as the front-line of both relationship-building and user research. Each support interaction is an opportunity for us to talk with our users, learn more about what they’re trying to accomplish with the platform, and identify where things are working well and where we might need to make improvements. Earlier this year, we even created new community guidelines for support requests that outline how we can best work with our users to resolve issues they encounter and incorporate the feedback they share.

Often, our conversations with users help us uncover bugs. Sometimes we’re unearthing some unexpected dependencies in our codebase, where changing one thing over here throws something off over there. Other times, we run into areas where something external has changed: a browser gets updated, an integration is deprecated, or a service the platform relies on goes down.

In all of those instances, we do our best to understand the problem quickly: to assess the scope of the issue and the impact it has on our users. We work closely with colleagues across the product team to prioritize issues as they come up and ensure that users are well-informed when critical issues arise.

We respond to about 60 messages a day, and those conversations help us uncover so much more than bugs—we also learn about:

  • Gaps in our product documentation

  • Opportunities for more education and topics to emphasize in our training programs

  • Features we should communicate about more frequently

  • Parts of the platform that aren’t working well, or could be improved to better serve users’ needs

We look at all of our support interactions with these areas in mind. There will always be bugs, but part of our work as a community team is to identify ways we can solve issues further upstream. For that, we have:


If you’ve ever had literally any kind of support or customer service interaction, it’s because you had a question or an issue that you couldn’t solve on your own. You probably tried to fix things yourself, and put off sending an email, starting a chat, or picking up the phone. Fixing things things takes time, and asking for help isn’t always easy.

As much as we try to make the process of getting issues resolved quick and painless, there’s nothing like being able to find the answer to a question yourself. Fortunately, product documentation is here to help!

We’re responsible for creating and maintaining all of the documentation on how to use our products, and frequently collaborate with other teams to document and share best practices on everything from SEO to editorial workflows.

Not only does documentation help users help themselves, it also helps our users help one another. One of my favorite things is seeing users share links to product documentation with their colleagues, to help them get started with a new feature, or answer a question about how something works.

We’re in the process of completely overhauling our documentation resources for Chorus, so watch this space for more details from Nicole Fenton on how she tackled this massive project.


Reading the docs is great, but sometimes documentation isn’t enough. We want all of our users to feel comfortable and confident using our products—even if that isn’t their default setting with most technology.

To achieve that, we offer training sessions on the Chorus platform. Training shows users how to get their work done and accomplish their goals with the tools at hand. It also helps people learn the ropes in a safe environment, and provides lots of opportunities to ask questions about how things work, or why something has been built in a particular way.

We’re in the process of revamping our training programs now, but they include everything from onboarding new Chorus customers and site managers, to one-on-one refreshers with power users on our editorial teams.


Like any good product team, we ship updates and new features all the time, so it’s not enough to offer training for new users once and send them on their merry way. If users are going to make the most of our platform, they need to be well-informed on all Chorus has to offer. That’s why we share regular updates on what’s new with Chorus in launch announcements and release notes.

To make it easier for everyone to stay up to date, we share product updates across a range of channels—including Slack, email, and blog posts. We also try to over-communicate the most important things so that folks can catch up when they have time, in the way that makes the most sense for them.


The Chorus team is extraordinary, but sometimes even we ship features that aren’t quiteright. Sometimes we build things that don’t fully meet users’ needs, or don’t account for all the ways they might interact with a feature.

In those cases, the community team is responsible for sharing the pain points and feature requests that come up while we’re interacting with users. We work closely with colleagues across the product team to advocate for solutions that meet our users’ needs and help them achieve their goals.

At the same time, we advocate for the platform and share details on product decisions with users. We can’t always promise a particular feature on a specific timeline, and there are times when we can’t accommodate certain requests at all, but we can ensure that users have the information they need to make decisions about how to approach a story, project, or workflow.

Stay tuned

That’s what community management looks like on the product team here at Vox Media. Watch this space for more updates from the team—we can’t wait to share our work with y’all! In the meantime, if this sounds interesting, if you have questions, or if your team does something similar, I’d love to hear from you! You can find me on Twitter at @eyemadequiet.