Access and engagement strategies

Community Building Enterprise
1

How close should customers be to your teams?

I put some time into thinking about this one last week, informed in part by the discussions we’ve been having about getting our own team more involved here on Meta.

Designing healthy boundaries between customers and Product teams

How product teams interact with customers in their community is going to vary widely across orgs, so I’ll speak to our experience with Meta.

Our situation is pretty unique in that we are dogfooding our product in real time with our customers. For the first few years of the project, everyone in our org worked directly on the product so being part of the community was a necessary part of the job. Over time that has become less the case and we now we have to actively encourage staff engagement outside of support categories.

Some of our team admit they don’t spend time on Meta because they don’t know how to engage. There are no questions they feel qualified to answer and they don’t feel like they have the depth of knowledge required to lead interesting or relevant discussions. Here are some of the challenges we have identified that get in the way of our team participating more on Meta— I’m sure other orgs experience similar ones.

Barriers to engaging in the community

  • Inaccurate, outdated or inconsistent responses to questions. (Not knowing the right answer or fear of giving the wrong one stops many from engaging.)
  • Vocal members can have a disproportionate influence on our team, potentially to the detriment of other members. (Some members take a lot of energy to interact with diplomatically and not everyone has the patience for it.)
  • Trust erodes if we change the roadmap without sufficient communication or if we ask for feedback and appear to disregard it. (Some people feel safer working in private so they don’t set expectations they can’t live up to.)
  • Notification fatigue from being personally tagged into topics that have no relevance because people are impatient. (Some members treat visible presence as an invitation to request personal support when they are stressed.)
  • Managing frustration when members don’t feel they are being heard. (Sometimes participation can be taxing due to its confrontational nature, even when no one is at fault.)

Where has direct customer–product interaction worked well in your organisation, and where has it become difficult?

9 Likes
2

This is interesting. I think the natural assumption would be that the people who design and build the software would be some of the best people to field these types of questions and discussions. Did you dig deeper to find out what drives this lack of confidence?

3 Likes
3

Not every team member is an engineer or designer :slight_smile:

4 Likes
4

I think I would have a similar presumption for Product Managers, Customer Support, Enterprise Support, Marketing, Sales, and such like. It’d be quite tricky to do those jobs well without the requisite knowledge. :person_shrugging:

2 Likes
5

I think all of us feel a little like this at times. I think that is something forum based communities have an advantage over social media however. The slower pace of the conversations and the longevity of the topics give users a chance to get a ‘feel’ for the other users and eventually feel more comfortable participating.

Being ‘qualified’ to answer depends on questions being asked. Sometimes anyone with any even remote knowledge of Discourse can help because the user is clueless. On the other end of the scale is when someone asks something very specific about something very technical. In those cases I usually just make sure the question includes enough information so when a qualified member lands in the thread, they have what they need to help. (version number, that type of thing)

Again, I think this is partly human nature. And the irony is interesting conversations often come from a lot of unexpected places.

4 Likes
6

I’m not sure I can answer directly to the topic, but I have a few Discourse-related observations :

I sometimes came across team member saying “Oh, I didn’t know about [feature or anything about Discourse]” despite being a dev or any other position working on the software itself.

It surprised me at first, not for long, though.

Enthusiasts like me who love Discourse, advocate for it, and sometimes are Discourse admins themselves tend to have (or in my case used to have) very good general Discourse knowledge and can answer many questions about the software. In some case, more or more accurately than a team member. Which I’d say can be considered as some sort of success or achievement by CDCK :hugs:

I don’t expect even a Discourse developer to know anything about the features of Discourse. There are simply too much to know, most of it perhaps unrelated to what they’re paid for, and many questions about Discourse can be outside their expertise. That doesn’t make them less valuable obviously. They’re experts in their field.

Of course, they can sometimes think they know, answer a question, and end up being wrong. That happens to everyone, team or not. It happened to me many times, and I admit I sometimes felt a bit embarrassed whether I was a regular user or not at the time.
And even experts can be wrong from time to time and it’s OK.

I remember once when I was at CDCK and confidently jumped on a customer’s CSS issue thinking I’d solve it easy and fast (it wasn’t even my job). I was plain wrong. The issue was way more complex than I expected and I let the experts fix it instead. :laughing: Yeah, that was embarrassing, but honestly wasn’t a big deal and I quickly went over it.

Oh well. I don’t even really address what I quoted, I’m more like sharing anecdotes at this point.

Goes both ways. I think frictional interactions with some team members were one of the few things that always bothered me (just a little, no big deal) on Meta; from day one to these days, occasionally.

I think it just lies in people’s personality, mood, temperament and culture. Most of the time I can’t and don’t blame people I find sometimes harsh in their interactions.
I see it as the peaks of waves on an otherwise calm sea. The expression of human nature.
The aim for team/community interactions shouldn’t and can’t be “perfectly frictionless” but rather “mostly frictionless”. I think it’s the case on meta, even if there’s always room for improvement.

But well, yeah, can’t answer the one and only question from the topic, so, sorry for being a bit off-topic :face_with_tongue:

5 Likes
7

Yeah I think this is important to keep in mind! as frustrating or embarrassing as it can be to try and get something wrong, it’s better than if no one tries at all. We’re not working on anything that’s going to explode, there aren’t too many cases where getting something wrong is going to cause irreparable damage.

With a little patience we’ll figure it out and learn something along the way… in my experience 99% of the people that use Discourse and have come here to discuss it understand this.

2 Likes
8

I’m slowly drifting more into off-topic, but what you say reminds me of a quote by a prominent Trackmania streamer about kids, failures and learning (in chess and in general):

[Kids] have no fear as well. Kids don’t typically overthink, […] they’re not scared of being wrong. That’s the best way to learn, see what doesn’t work. But if you start learning a new skill as an adult you’re kinda scared of being wrong. Kids are a lot more willing to try and fail than adults are. Like yell out the wrong answer confidently if the teacher asks anyone has an idea. And this kind of mentality shapes how you learn things.[1]

Something to keep in mind I guess :slight_smile:

(end of off-topic)

  1. https://youtu.be/Hr2nBfa-yaM?t=1970 ↩︎

2 Likes
9

Hey James. :slight_smile:

I did! I think it is a combination of understanding the hidden costs of engaging and having a framework for participation.

The internal cost of staff engagement

Meaningful participation requires more than the time and effort spent actually answering questions. People need access to information, moderation support, follow-up frameworks, escalation paths, and clarity about what they can discuss/what examples they can share/what customers they can name.

Community teams generally absorb this invisible work because they know which subject matter experts to loop in, they have relationships with members, they have the skills to keep conversations productive, and they have the time to make sure nothing falls through the cracks. This ensures that trust levels are maintained and the community offers value to all participants.

Our team understand the value of that trust and how long it takes to build so the fear of doing something to erode it is enough to put some off engaging at all.

Building trust without overwhelming internal teams

Trust comes more from predictable behaviour than constant availability. Customers/members don’t need continuous access to your team if they have confidence in your processes. They need to know:

  • where to give feedback
  • what happens to it
  • who reads it
  • which discussions receive responses
  • how decisions are made
  • when we’ll report back

There needs to be some form of continuous feedback loop that is reliable—trustworthy with boundaries is preferable to being highly available but unreliable. No one is going to invest time giving feedback if they’re shouting into the void. You need enough direct contact to understand member needs, with enough structure that everyone knows what value they get from the interaction.

This interests me—let’s call in @mae and ask her how she feels about answering technical product questions. I think that might be quite eye opening.

I agree with you Andrew, there are probably always a handful of questions that anyone can answer but discoverability can be an issue in those cases. I’m interested to hear how other teams handle this.

I don’t think it’s off topic, I think there is something quite valuable that we can take from that. We need a better understanding of why we’re afraid to fail.

2 Likes
10

This is what I do if I am unsure of an answer…

first step: I look at how long the question has been hanging there unanswered.

if it has only been an hour or two or it is the weekend I’ll let it go for a little while and wait to see if anyone brighter then myself answers.

If it is a very specific question and it has been 24 hours and crickets :cricket: then I actually start to feel sorry for this person. I will try to help, even if I know very little on the subject of the question. In this situation sometimes I’ll do a quick search and see if there is some documentation I can point them towards. They could do that themselves but a lot of people don’t RTFM no matter how desperate they are. Or if it is a bug, I try to reproduce it.

If I think I know the answer but I’m unsure, I say ‘I think…’

If I think I know the answer but I’m not 100% positive, I say ‘I’m almost certain…’

If I have no clue, I say ‘I’m just guessing here…’

In a lot of cases with a topic that has been sitting there for awhile, somebody replying in any manner what so ever is better then crickets. At least the user knows they are not being ignored. And often the reply bumps the topic and others join in.

This I think is important. (and very well put) A super responsive team that comes off as auto reply and then doesn’t follow up is worthless.

But I think this also plays off what people are saying in the other topic about community engagement dropping off. If a support forum doesn’t respond or takes hours to respond the temptation to ask AI and get an immediate answer is even greater.

BTW I think meta does a really good job of striking a good balance at this

THIS is where I believe a community forum reaches critical mass!

As a guy trying to get a community forum going this is what I someday hope to achieve.

When a forum, especially a support forum gains enough knowledgeable veteran users participating that when a user asks a question, there is a whole group of people who hang out and answer questions just for the fun of it, then we are cooking with gas. If the audience is spread over enough time zones that somebody is always awake and responding, now we are really exploiting the power of the ‘world wide web’.
And there is what AI can’t give us that a community can… a community

6 Likes
11

That was an interesting read, but I don’t think it covered the main thing I was curious about. I was more interested in this specifically:

This just seems counterintuitive. Who else is best placed to know more, and across such a broad spectrum of sites and use cases? Sure, no one can know everything, but surely a decent chunk more than the average lurker.

There are going to be departments that are quite far removed from the product (eg finance, legal), so if this feedback is solely from them then it’s more understandable—but if it were that easily explained I presume you’d have said so earlier.

This feels like a set-up… :slight_smile: I was imagining marketing and sales to have a slightly different specialism than technical questions, but maybe I’m overthinking it. I shall not prejudge. :slight_smile:

Though I do agree about where best to apply your time/resources, but that’s a separate issue to not feeling able to contribute if you wanted to.

12

Would you ask a basketball coach to teach you tennis? Both are sports, but you’d want someone who actually plays the game. Same idea here, I’d rather point you to the right expert than fumble an answer I’m not qualified to give.

I can talk all day about positioning, messaging, and how we tell the Discourse story, but the deep technical stuff belongs with the people who actually build it.

All that being said, I do think Marketing and Sales should play a bigger role on Meta and could be drivers behind less technical content. This is a Q3/Q4 priority for me.

If anyone has any ideas for less technical content that they would like to see on Meta, please don’t hesitate to reach out or tag me in topics. :slightly_smiling_face:

4 Likes
13

Yup, love this. I think it’s the perfect approach.

Very interesting thought—no doubt you’re right. Do you think people would default to the bot here (or on another forum) though, or go completely external? Might be interesting to measure.

My answer was a bit convoluted, but what I was getting at was this specifically:

And to clarify, yes it is the business side of the org that feels that particular barrier to engaging. I didn’t actually mention technical questions so that has been conflated. :slight_smile:

14

True. If someone came up to me with a basic query regarding Discourse, I would say I could answer them fairly confidently. But when it goes into very advanced setups, or installation failures that turn out to be bugs hidden deep down, then thats way out of my knowledge.

There was a period a few months back where I posted considerably less. Not because I simply wasn’t around (I was; I still read Meta daily), but because the questions got much more technical and because of timezones, I only saw them much later. Very specific bug reports, or questions that were too specific that I could apply on my instance(s).

That’s when I realised that ultimately, what I know barely scratches the surface in comparison to the devs working on the actual product, or people like Moin and Lilly.

My point? Even if one engages with Discourse regularly, the configurability of Discourse ensure that information is near infinite. It’s too customizable (not a bad thing, though) and can be tweaked so heavily it barely resembles a stock forum. So if staff may not know everything about the software, that’s fine: they specialize in different parts, and each can be consulted as ‘experts’ for that part.

2 Likes
15

Ahh, I knew it was against the odds, but from the ‘eye-opening’ description I had started to hope you were going to jump in with some arcane knowledge about Flarum migration scripts or setting up a cloudflare tunnel. :slight_smile:

Though as you say later in your post, there are certainly other less technical areas where you’re looking at applying your specialist Discourse knowledge, so at least you’re not part of the original ‘lack of confidence’ feedback. :partying_face:

I think companies need to be realistic about which departments and people they’re expecting to participate in the community. A blanket policy or one-size expectation is likely going to be a poor fit, even in smaller organisations. I think asking, ‘what are the benefits for this department/person to participate’ is certainly a key question when evaluating an inclusion strategy.

I did think it was an incongruous addition to the conversation. :slight_smile: Some kind of AI blip or something?

1 Like
16

I wondered what you were talking about and I had to read back through the entire convo to see where it was introduced because AFAIK there is no AI involved here. But then I saw…

I conflated it! I have no idea why I added the word technical! Reading back I can only assume I misinterpreted what you were saying. No one ever asks marketing questions here, I thought you were suggesting everyone has product knowledge. My bad.

1 Like