Bookmark
- Web 2.0, Corporate Websites, Social Networking, User Experience, User-Centered Design, Community, support, Business Model, Strategy
Ben Worthen had an article the other day in the Wall Street Journal about the kinds of online communities companies are starting to build - "Why Most Online Communities Fail." He provided some potentially disturbing statistics from a recent study:
Thirty-five percent of the online communities studied have less than 100 members; less than 25% have more than 1,000 members – despite the fact that close to 60% of these businesses have spent over $1 million on their community projects.
If, as we've certainly been not alone in suggesting, customers are looking for more authentic engagement from the companies with which they do business, why are these sites failing?
Worthen points, I think, to the key problem:
Businesses are focusing on the value an online community can provide to themselves, not the community.
Whenever you're thinking of building a community, you need to think about three core things:
- Who are the people we're hoping will participate in this community?
(It can't just be for "everyone" - who do we really think will come,
and based on what?)
- What benefit will they percieve from their participation? (Not just
how do we think they will benefit - what benefits will they realize?)
- What can our community offer that they are not already getting elsewhere?
The reality is that with online communities becoming increasingly common, if you're not going to reach users in the communities they already inhabit - you've already decided you need to build your own - you've got to have some differentiated feature. It is no longer enough (indeed the stats above suggest it never was) to be yet another "me too" community and aim for success.
Answering items 2 and 3 is often made more effective by involving some of the folks identified in item 1 in the process itself - leveraging an "alpha" group to help determine the features, functions, and design of the community, and then an active "beta" group to guide further iterations.
Finally, there's a hint here that the companies though of communities as something they would build once and then just let run: not a constantly evolving, living thing. Rather than spending a signficant budget on the design and launch of the initial community, then starving it on the vine, control the spend on the initial launch and provide consistent strong nutrition to the community as it grows.
Open source software makes a perfect match here, naturally, since you don't need to sign the enterprise license agreement (or budget for it) just to get started, and you won't feel penalized by the success tax as you do in solutions priced by number of participants.

