It’s scary to launch a new community.
This is especially true when you’ve been working on it for half a year and made a $500k investment into the technology.
You launch and wait for the first trickle of activity. Two posts become four. Four posts become Eight. Eight posts become 16 and so on.
You see this with Datarobot’s community right now. The first trickle of activity is just starting.
Don’t rush this stage. An explosion of activity doesn’t help you if you’re left with a trickle of activity afterward. You don’t want most of your audience to see an empty community. That’s a terrible first impression.
Instead, go above and beyond for each new member who does arrive. Ensure the questions receive a quick and empathetic response. Direct message members and check their problem was resolved. Get to know each of them. Make the first members feel part of something new, special, and exclusive. Give them unique access just for being one of the first pioneering members of your community.
Don’t rush this process, but lean into it (and set expectations for it). The trickle stage is the time to identify and resolve issues, nurture future top members, and provide a world-class experience to every newcomer.
Soon the trickle becomes a stream, a stream becomes a river, and the river becomes a torrent of activity.
There are three good principles to consider when designing your community site.
1) Minimize effort and maximize reward. If members have to scroll past large banners or find useful information among static content, that’s bad. Minimise the static material to show the latest activity. Deliver the maximum value for the minimum amount of effort.
2) Prioritise by popularity. Don’t prioritise alphabetically, prioritise the display of topics/categories, content, features, and navigation options by what’s most popular in the community. If you don’t have a community yet, prioritise by use cases.
3) Keep social density high, but not too high. If you’re launching with multiple features (Q&A, ideas, groups, etc…) and a dozen topics/discussion categories, you’re doing it wrong. You need to keep activity high, but not so high it’s impossible to follow what’s happening.
One of my simpler, but favourite, community designs is the Basecamp community by Kony.
It’s clean, simple, shows activity above the fold, displays navigation options clearly, and is probably the best implementation of Salesforce Community Cloud I’ve seen in years.
Developing the community experience isn’t easy, but if you follow the core three principles you will probably be ok.
p.s. Learn the principles of a great community design for free.
Some interesting data from this study at LungCancer.net:
“In the fall of 2017, a series of 5 weeklong Facebook advertisement campaigns were launched targeting adults over the age of 18 years with an interest in lung cancer to increase opt-ins to the LungCancer.net community
The advertisements released during this campaign had a sum reach of 91,835 people, and 863 new members opted into the LungCancer.net community by providing their email address. […] A total of US $1742 was invested in the Facebook campaigns, and 863 people opted into LungCancer.net, resulting in a cost of US $2.02 per new member.”
The numbers vary by community sector.
$2.02 per new member and a 1% conversion rate is only slightly higher and lower (respectively) of the numbers we’ve seen in past client projects.
While you don’t want to rely on paid social ads for your community’s growth, it can be a useful tool to speed up the community’s early development.
If you’ve invested hundreds of thousands of dollars to launch the community, it’s typically worth investing an extra $2k to $5k to ensure it quickly attracts a critical mass of members.
With a few exceptions, most sub-groups within a community fail.
There are two primary reasons for this.
- They don’t have a good, committed, leader to succeed.
- There isn’t enough activity/members to sustain the number of groups created.
Sub-groups are one of the last things I’d add to a community. They take time and energy away from the community’s prime purpose. They are primarily a tool for large, mature, communities.
A far simpler option to creating and hosting groups yourself is to link to any existing groups which do exist. These might be on Facebook, Reddit, LinkedIn, Slack, Telegram or any other channel.
Now you’re supporting an ecosystem that extends beyond just your community website.
As a good rule of thumb, if there aren’t existing groups outside of your platform, you’re probably not ready for groups on your platform.
Consider two questions posted in your community.
“Hi, does anyone know how to get [Widget x] to work with [Widget y]?
Any help would be appreciated!”
“Hi, I’ve been struggling with a problem which is really driving me nuts.
I’m trying to get [Widget x] to work with [Widget y].
So far nothing has worked. I really need some help or I’m going to waste 3 months of work and have to begin the entire project again.
Can someone help?”
Which question would be more satisfying for you to answer?
For most of us, the answer is Question B. You feel a lot better about yourself if you know the impact your answer can provide.
The more you know the value of your help, the more you’re likely to provide it.
This should affect how we coach members to ask questions in a community. No, we don’t want emotionally manipulative language, but we do want to coach members to also explain the impact of resolving the issue to them where possible.
You can do this in your onboarding first question, the default text which appears in the text field before being replaced, or in ‘in line nudges’.
If members value the feeling they get from helping others, then make it easy to feel as great about helping others as possible.
Too many communities are launched with features they will never be able to support.
The number of features your community deploys should be driven by two things.
The first, obviously, is your community strategy.
If you want the community to be resolving questions, suggesting ideas, sharing expertise in long-form, and connecting with each other then you need the Q&A, ideation, blog, and group features to enable that.
But this should be countered by your membership projections.
The fewer members you project, the less features you should deploy. There simply isn’t enough energy and attention to support them (regardless of how ambitious you want to be). Some features, notably groups, need a huge base of members to thrive.
This means you need to prioritise features and deploy just the ones you can support.
Given the median number of monthly active members in a customer community is somewhere around 550, this should temper your ambitions.
- Below 200 active contributors: Q&A only.
- 200 to 400 active contributors: Q&A + events/webinars
- 400 to 700 active contributors: Q&A + events/webinars + ideas
- 700 to 1,000 active contributors: Q&A + events/webinars + ideas + knowledge base
- 1,000+ active contributors: Q&A + events/webinars + ideas + knowledge base + groups.
Treat these as general principles rather than rigid rules.
Bose, for example, has around 1,000 active participants but only uses Q&A.
Sophos has around 350 active participants and uses both groups and a knowledge base.
Two more important points here:
First, before you determine what features your community should have (or whether to deploy more) you need an accurate membership projection (use our template here).
Second, your community platform is never finished. It needs regular updates (some big, some minor) to ensure it has the right number of features for the number of active members.
Without a strategy, you end up tackling problems piecemeal.
What should you measure? Why not ask around and see what others are measuring?
What technology should you use? Why not look at different vendors and select the one you think is best.
What should your onboarding journey look like? Let’s see what everyone else does.
Needless to say, this is a terrible approach.
A good strategy answers all of these questions.
You should be measuring the success of your strategy, not anybody else’s.
You should be using technology which best supports your strategy (audience needs, budget, and internal resources).
Your onboarding journey should guide members to the behaviors you’ve identified in the strategy. Each step should connect with a specific emotion to guide the next action.
Great examples can show you what’s possible, not what you should do.
You need a community strategy.
Ever noticed members seem surprised by a change you’ve announced several times already?
That’s because they read far less of your content than you imagine.
They clicked through the emails and on-site announcements.
A handy rule of thumb is to assume about 20% of your members read 20% of the content you send to them.
So target the members who care and reduce your message down to the core points.
The longer and more frequent your messages are, the fewer people will read them.
The wrong way is as a crutch for bad design.
An on-site tutorial is not the solution to a complicated design.
If it’s too complicated to use, improve the design.
Most members simply click through a website tutorial anyway.
A better approach is to trigger a tutorial by an event.
i.e. After a member reaches a certain gamification level, has been a member for a year, or earned a special badge, they gain new powers. Here a pop-up/on-site tutorial can show them what they now have access to and how to use it.
Now you’re creating pop-ups people are excited to see and actually read.
Bonus tip – hold some permissions back from newcomers so you can surprise them with new permissions later.
If you’re managing a community, you should be wired into the topical issues of that sector.
This will mean following the relevant influencers, reading the major books and blogs, subscribing to (and reading) trade publications, attending industry events and participating in other communities related to the topic.
No-one expects you to be an expert, but there’s no excuse for being uninformed.
Last week, I flew from London to Las Vegas for precisely one day.
The purpose was to get various stakeholders in the same room to begin executing the roadmap.
Ideally, the people in the room include the senior leader (whoever controls the budget), the implementation partners, and the community team. It also helps to have scheduled meetings with other key stakeholders (technical, legal, PR, marketing).
The value of these meetings is three-fold.
First, they build the social capital you need for the team to cooperate effectively with one another. Emails and calls can be misinterpreted, but it’s easier to assume good intent when you can hear someone’s tone of voice, body language, and learn how best to communicate with each other.
Second, it allows you to go through everything in detail. Sometimes obscure aspects of a project can trip you up if every single detail isn’t wireframed and confirmed in writing.
Third, it allows for immediate creative problem-solving. When people have flown or travelled to a meeting for a day, you typically get their full attention. People are engaged in figuring out solutions.
It’s not always cheap to do meetings like this, but they always pay off many times over. Even if you can’t get everyone in the room, it helps to bring as many people involved in the community together when you begin the process.
You can have a distributed team if you like but bring them together when the project begins.
A few years ago, we asked members what they were working on that week.
We had a flood of responses.
So we did it again, and again, and again….
Eventually, the novelty wore off, the flood of responses became a trickle, and we stopped asking.
The problem was two-fold.
- Most people were working on similar things each week (each month might’ve been better).
- Members weren’t gaining enough value to keep participating in these discussions.
What do you do once you’ve shared what you’re working on?
We should have built upon the success instead of trying to replicate it.
We should have had means for people setting goals for themselves they would hold each other accountable to.
We should have been proactively making connections between members to collaborate on similar projects.
We should have asked them to share their resources, templates, or lessons they had gained after each week etc…
Two lessons here. First, don’t continue a tactic that is clearly in decline. That’s a waste of everyone’s time. Second, build upon your successes – don’t repeat them.