We have been experimenting with a few different formats for engaging with our customers/members this year thanks to @danielle’s amazing work at How We’re Organizing Webinars & Office Hours. These kinds of formats are infinitely scalable because a few hours of Danielle’s time benefits multitudes of future consumers. Office hours are particularly valuable because they bridge the gap between direct and async communication—people with direct questions can ask them live, while others can benefit later from the curated discussion.
I’m curious to hear what other types of one to many engagement models work well for others.
Another little pattern that I see working well for us is to have people who are closest to a particular change making announcement topics about that change.
To some degree, this was probably a natural outgrowth of Discourse being an open source project. At the same time, I think we’ve continued to be intentional about this as we’ve scaled and added people in different roles.
For example, our feature announcements are usually made by someone who actually worked on that feature (whether an engineer, designer, or product manager).
This allows people to start conversations about something they know something about in a way that hooks pretty well into the process of building the product.
It gives the community a place to engage directly with the people building a particular feature.
And it also allows the people building it a way to continue to engage in feedback from the community about that thing without having to watch everything across the community or come up with sophisticated triage or tagging systems.
I’ve seen others do similar things elsewhere pretty effectively too, even if some of the details differ.
One thing we tried but weren’t successful with was having periodic discussions (just like this) to ask people’s thoughts about different elements in the product—almost like bite-sized feedback.
Currently, our categories all require something specific:
Ask/answer questions, but this requires either having something wrong or knowing the product knowledge to provide an answer
Share a guide, but this requires some product expertise that no one else has shared and/or the docs don’t cover
Submit a feature request, but this requires coming up with an idea that no one else has thought of
But having a “how do you handle ABC” or “what are your thoughts on XYZ” allows people who aren’t product experts to share their input. Unfortunately, our community is still pretty inactive, so it only converted a couple of lurkers to contributors, but I still think there’s merit to the tactic.
Also, kudos to the meetings that Danielle has put on! I sign up for all of them and try my hardest to attend
