Last year we reviewed some research on a developer community.
A somewhat crude paraphrasing would go something like this:
Q. “What would you like in the community?”
A. “Great documentation!”
Q. “What about better discussions, expert interviews, live chatting with product engineers?”
A. “No, we just want great documentation”
Q. “Do you think we should have a Slack channel?”
A. “We don’t care, we just want great documentation”
Q. “Would you be interested in publishing a blog post sharing your expertise?”
A. “No, I.want.to.see.great.documentation please”
Q. “If you had to choose between a blog post, expert interview, or a live chat…which would be your favourite?”
A. “Good documentation”
It’s obvious the community manager isn’t listening. S/he is looking for anything that validates the kind of community they already plan to build. No-one is going to win here.
A far better set of questions would go:
“Documentation? Great what kind of documentation do you most need?”
“What format do you like documentation in?”
“Would you like to edit it? Would you be interested in other developers adding their notes/comments on it?”
“How would you like to be notified of updates by documentation?”
“If we allow others to add their notes/make updates, should this be hand-selected or should we have a review process?”
Etc….
Now you can start shaping exactly the kind of community members want.
It might not even have a discussion area. It might be a wiki, a series of updated guides people can clip notes to or something else entirely.
It’s far harder to listen that we might imagine. Don’t go through a research interview with a set of questions hoping to get an answer that supports what you already want.
Genuinely do the research with an open mind and go where it takes you.
