A while back, a concierge of my apartment building was caught breaking into a neighbour’s apartment and rummaging through their possessions.

It’s easy to take necessary disciplinary measures against the individual and consider the matter settled.

It’s far more effective to look at the system which enabled this to happen. Once you look at the system, you can begin to notice how the standards have steadily fallen when enabling this to happen. This includes:

• Salaries of staff members not keeping pace with inflation. This both encourages theft and high-rates of churn.
• Failing to replace staff members quick enough leading to stressed out staff.
• Deteriorating relationships between staff and residents (due to the above two factors).
• Shortcuts were increasingly taken to save time (notably with spare keys being kept in the mailroom accessible by all staff instead of locked in a safe accessible only by the building manager).
• Not undertaking a proper background check on staff.
• Failing to properly follow-up on past concerns by residents of missing valuables.

Sure, it was the rogue concierge who committed the crime, but it was a slow erosion of high standards which created the environment for this to happen. Simply recruiting a new staff member doesn’t solve the underlying problem.

This happens in communities too. A major ‘blow-up’ is rarely the result of a single unexpected incident. It’s almost always the result of standards that have declined rapidly over time. These standards often begin with recruiting but continue with how members are engaged, treated, and concerns acted upon.

It’s easy to dismiss the minor things, like grumbles from members about how they’re treated. But these are usually the first warning signs that your standards are slipping. Better to deal with it now than later.

I really admire AWS re:Skill.

The site looks great, it functions well and it’s great if you want to get support to learn AWS.

It’s also entirely built and managed by the AWS user-group community.

The site is a testament to the power of supporting a community to do what they want to do. We all preach the importance of letting the community lead the way (and handing over control to the community). But it’s far, far, harder to actually do it. At some point, members will want to do something you disagree with.

So perhaps it’s best to decide what’s more important. Would you prefer to have members stepping up to lead and creating amazing resources for one another – even though it will cause issues from time to time?

Or…would you rather none of the above?

There are multiple occasions where you have the opportunity to build multiple types of communities.

You might be launching a pilot program and trying to decide what topic to launch first.

You might be considering expansion to new languages and feel unsure which language to pick first.

You might be considering launching a new group and deciding which group to target first.

There are two major considerations here. The first is whether you have strong support for this already (i.e. are you fully resourced for a new community/group?) or do you have to prove results to get the resources (90% of the time it’s the latter).

If you have the support you want, target the biggest win. If you don’t, target the quickest win.

For the quickest win, refer back to this model here.

Find the group which has the combest combination of:

a) The biggest-sized audience.
b) The audience with plenty of existing questions/problems to solve.
c) Has limited competition for members to solve those problems today.

It’s fairly common to automatically close discussions after they have gone a few weeks (or months) without a response.

The benefit of this is it keeps the community fresh.

It’s tiring to see newcomers responding to discussions that haven’t received an update in several years. The common case is the member arrives via search to an outdated post, tries the advice provided, and points out it no longer works.

If the discussion was closed for new posts, that’s a good indicator that it’s out of date (or the matter is ‘settled’). It would also encourage the newcomer to create a new post that might solicit more recent, up-to-date, information.

The downside of this approach is you’re likely to get a lot more repeat discussions on the same topic. It can be exhausting for members to repeatedly answer the same questions.

So, what’s the best option? In most cases, it’s usually best to close discussions that haven’t received a new update in several weeks. For extremely large communities where repeat questions would be a problem, it’s probably best to try and have ongoing, definitive, threads (and up-to-date knowledge-base articles), which members can reply to.

I have no idea…

But if you’re feeling pressured to pursue ‘the next big thing’, it’s worth pausing to reflect upon the context.

Over the past fifteen years, how many of the following have really been game-changers for building a community? I can remember waves of enthusiasm for…

• Social media platforms.
• Blogging.
• Gamification.
• Blockchain.
• Smartphones.
• Virtual events.
• Social analytics.
• Habit theory.
• QR Codes.
• Virtual worlds.
• Machine Learning.
• Search Engine Optimisation.
• Location-aware technologies.

You can also look back at the hype cycle from 2008, 2015, 2019 (or any other year) and consider how many of these technologies have truly been game-changing for your work?

Some of these have had some impact for those of us building communities, but would you have suffered greatly if you had waited to see if the hype was correct before acting?

The cost of being late to the party seems minor compared to preparing for a party that might not ever happen.

One of my favourite things to do in member interviews is to open the community site (via sharing my screen) and let members talk me through how they experience it.

The results are usually quite startling (and great for discussing with the client).

We usually discover:

• Members don’t navigate through the site as planned.
• Most navigation options can be removed.
• The language and terminology used is often confusing (i.e. discussions vs. groups).
• The majority of features/content is ignored.
• During registration, members don’t read 90% of the information.
• We assume members have much more knowledge about the company (and communities) than we think.
• Most gamification features are irrelevant.

And this is only the tip of the iceberg.

If you want to gather great feedback, spend time with members guiding you through the site. You will be surprised.

I’m writing this in a London cafe on a cold day.

Each new customer opens the door and expects it to swing back closed behind them. But the door doesn’t do that. Instead, it stays open and the cafe starts to get cold.

At first, the staff shouted at customers to close the door behind them. But then their manager suggested shouting at customers before they’ve paid wasn’t the best strategy.

Instead, staff began to close the door behind each customer. But this wasn’t sustainable either. It took time away from serving customers and was clearly frustrating staff to do this every time a new customer enters (about every two minutes by my count).

So they wrote a sign and posted it on the door reminding customers to close the door behind them. But the sign was written in ink and was too small. Most customers ignored it.

Next, the staff wrote a bigger and clearer sign in bold marker and posted this on the door. This didn’t help either. There’s already five other notices on the door and window. Too many for any customer to bother reading any of them. They could remove the other signs, but that would upset management.

I’m struck by how often we’re faced with equivalent problems in a community.

We have a technology problem and there isn’t a perfect solution. We’re forced to choose between:

a) Simply allowing it to happen (i.e. allowing existing members to be disrupted).
b) Shouting at new members to behave the right way.
c) Politely trying to nudge members to do something (with little effect).
d) Posting really big signs (at the expense of other notices).
e) Doing a lot of extra work ourselves.
f) Paying (and waiting) for the technology to be fixed.

There’s no useful advice here – just a lesson that you’re not alone in these dilemmas. There’s no easy solution even to the most simple of problems. Sometimes you just have to figure out which is least painful.

The staff have settled upon the cafe getting cold.

Too often we move or evaluate platforms based upon a specific feature (or set of features).

I’ve seen organisations demand specific features such as:

• Ability to live stream events directly through the platform.
• Collaborate on documents together within the platform.
• Ensure all members use two-factor authentication to log in.
• Develop complex automated rules-based upon past behaviors.
• Universal point systems combining internal and external behaviors.
• Integrate social media content seamlessly as discussions.
• Customise their member profiles with unique designs.

The reality is the features that often get the most excitement internally are often the least used internally. Worse yet, once you begin customising the platform, you’re responsible for the maintenance of that customisation which can cause endless trouble. None of these will have a major impact on participation.

If you look at a few hundred communities (as we have), you start to notice the majority of members use the same few areas in almost every platform (typically discussions, direct messages, search, and knowledge base).

What really impacts participation isn’t adding major new features, but usually tweaks in the most commonly used features which makes them easier and more satisfying to use. This often includes the layout of discussions, being able to reply by email, length of snippets which appear in digests, quantity (or lack thereof) of text which appears on pages, simplicity of logging in and remembering details, cognitive vs. federated search tools, taxonomy, etc…

The tragic thing about most RFPs (and the people evaluating them) is they rarely account for this. They lack the breadth of features and assume one platform’s discussion forum is as good as the next. It’s like evaluating a restaurant by whether they have a kitchen instead of understanding the little details that make one restaurant better than the next.

The solution is to join a bunch of communities on different platforms and participate meaningfully for a week. Notice the little details. Evaluate the experience you’re having and what you’re feeling as much (if not more) than the features you’re seeing.

After this post, a few folks shared examples of their own feedback forms.

I especially like this one from Geotab’s (a former client) feedback hub.

There are some clever things going on here.

First, the feedback hub isn’t just gathering ideas, but feedback on a range of tools, features, and even customer service. This is a genuine place to also highlight complaints outside of the typical community channels. Feedback can also be directed to the person responsible for each feature/aspect of the service.

Second, the form captures what people want to accomplish, why they want to accomplish it, and the situation in which the need occurs.

Finally, the form captures the frequency and urgency of the need. It also captures what tools and software the member uses today.

This is the kind of data that’s needed to make feedback informative and practical.

Here’s my favourite way to test the viability of a feature; pretend it’s already live.

If you’re planning on launching a new group, category, ideas area, event series, etc…pretend it’s already live.

Go through the motions of coming up with discussions for the group, write draft emails to people to respond to those discussions, write draft emails for prospective people you would interview, book time in your calendar for a 30 to 45 minute meeting to discuss the call, find someone who can edit the interview, write draft emails to product managers to respond to ideas, schedule fake times in your calendar to engage with each of them to get support.

Do everything you can do without directly engaging with people. You will soon find every new feature you plan to launch takes up far more time than you imagined. I’ll bet you begin putting these tasks off to focus on the urgent things happening right now.

Coincidentally, this is precisely why most new features fail. You launch new features without allocating more time and resources to ensure they succeed.

And if you succeed in this, you’ve got a huge amount of content and actions already lined up for when you do launch the feature.

I’m noticing in a few client communities recently that the community manager (and members) often don’t structure their questions to get the best (or most) responses.

Here is one simple tweak you can make. If you want more people to respond to questions, ask them to talk about themselves.

Compare two questions

Question 1: “What metrics are most useful for measuring [x]?”

Question 2: “What metrics do you use to measure [x]?”

Question 2 will usually get a bigger response. The reason is simple. People love to talk about themselves. Not only that, the response will usually be more valuable. People aren’t speculating about metrics anymore, they’re sharing what they actually do.

Consider another example:

Question 1: “What resources are most useful to newcomers to [x]”?

Question 2: “What resources most helped you when you were a newcomer to [x]”?

People are more likely to respond to the second one and the quality of responses will be better.

One more example:

Question 1: “What is the best way to solve [problem]?”

Question 2: “How did you solve [problem]?”

Now you’re getting responses from people who have actually solved the issue instead of people speculating about how to solve the issue.

Try it on Twitter/LinkedIn if you like, you might be surprised.