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.
- Virtual events.
- Social analytics.
- Habit theory.
- QR Codes.
- Virtual worlds.
- Machine Learning.
- Search Engine Optimisation.
- Location-aware technologies.
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.
You probably know most of the community books already. So here’s some alternative reading you might find really useful this festive period.
- Workshop Survival Guide. If you’re hosting any sort of online or offline workshop, you should read this. It’s really helped us take our workshop game to the next level. The most practical guide out there today.
- Who. Read this before you recruit your next employee (or hire any sort of agency/consultant to help you work). This has changed how we recruit and hire for a variety of different roles.
- Playing To Win. Everyone developing strategies today should be familiar with the basic concepts of strategy. This will help you recognise the battle you’re in for your audience’s attention and how to win that battle.
- Your Strategy Needs A Strategy. A slightly different take on strategy. Before deciding what your strategy should be you need to decide what category of strategy you’re developing. This depends heavily upon the environment you’re in. Most strategies are dead on arrival because they’re unfeasible.
- Storyworthy. If you want to persuade anyone, you need to tell persuasive stories. This is the first book I’ve found which goes from the theoretical process to the practical steps to tell persuasive stories. Read it before your next talk (or article!).
- Peak: Secrets from the New Science of Expertise. Most of us reach a level we’re happy with and stay there. To really excel at anything you need to deliberately practice and refine new skills. This book was an eye-opener.
- Thinking in Systems. A bit of a dense and theoretical read with astounding implications for community professionals. Everything is part of a system. An increase in any metric comes at the expense of others. If you figure this out, you will be much better for it.
- Thanks for the Feedback. I never realised giving and receiving feedback was an art form until I read this. I’d make this a critical book to read whether you’re engaging in communities or not (but you might be surprised how useful it is if you’re in the trenches of this work).
- Endurance: Shackleton’s Incredible Voyage. Sometimes we just need a riveting read. I’d recommend this one. At its best, it’ll make you realise you’re capable of enduring more than you think possible. At the very least, it might put some of your daily troubles in perspective.
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.
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.
Several of the product managers I’ve met with over the past few years disdain ideas submitted by members.
The problem isn’t that an idea is especially good or bad (although there is a trend of wanting more while spending less). The problem is the ideas submitted don’t contain anywhere near enough information.
For example, it’s unclear whether:
a) What the idea actually is (instead of a complaint e.g. “improve [feature x]!”)
b) What the current use case is.
c) What the current approach to achieving that goal is.
d) How relevant it would be to different segments of customers.
e) Whether it’s an urgent priority or a minor annoyance.
f) Who the idea should be sent to.
The problem often lies in using the same (or similar) tools to create questions as we do for ideas. Ideas get a title and a body – then members are left to write whatever they please.
Okta, a client, has a more interesting and better approach.
Now it’s clear what the idea is, what the use case of the idea is, and how customers are approaching that solution today. Members can select the product area (which should ensure this gets sent to the right person).