With a reasonable set of prioritized scenarios in place, the prospective leaders of the community can define the technical functionality that matches the scenarios. Again at this level, those building and stewarding a community are often tempted by the notion that more functionality must be better. In fact, superfluous functionality actually detracts from the core value creating activities. This is especially true for communities targeting professional audiences, who tend to be busy, impatient with technology, and already suffering from information overload related to their professional responsibilities. They want easy access to the one or two things that will help them get information or knowledge they need to do their job (e.g., “what are the materials I need to participate in the next meeting?” or “who are the three people I need to contact to get answers related to the issue I currently face?”).
The choice of functionality has a great deal to do with the community’s purpose. In a community, for example, whose key value proposition is allowing a small group of “knowledge owners” to share their experience and wisdom with a large group of “knowledge consumers,” the appropriate tool might be a blog. This format allows the knowledge owners to post useful knowledge that is easily consumed and commented upon by the community. A peer-to-peer discussion forum for the knowledge consumer participants might fail if all they want to do is read the posts by the experts. A second community, whose primary value is connecting members working on the same topics and encountering the same problems and questions, might be best served by facilitating discussions, allowing users to post and answer questions, quickly share resources or observations, and respond accordingly. Social networking functionality, such as rich profiles, friending, and messaging, might also be useful in this scenario. On the other hand, also offering member blogs for such a community might actually detract from the critical mass of the discussion area as users’ questions, ideas, and conversations are now split between two separate places. Last, in neither community described above would a wiki work well because this tool tends to be better suited to organized groups creating a single and coherent body of knowledge, but wikis often fall flat in less structured communities that facilitate ad-hoc, ongoing knowledge sharing.
It makes sense to start not only with a small feature set but also with a rollout limited in the scale of its community and its technology. In short, community leaders can be well served beginning with a limited pilot phase. The history of online community initiatives clearly shows that, once activated, community participants will take a community to where it makes the most sense for it to go—regardless, sometimes, of initial intention. This is a natural process and should be honored; if the end goals remain in line, community initiators should allow themselves to be pleasantly surprised by different means to the same end that can emerge. These different means may imply adding (or subtracting) technology features and making other refinements that enhance the community’s chosen direction. In addition, tracking the emerging patterns of activity may suggest new functionality that could improve the usability of the community. If it turns out, for example, that community members are regularly accessing image files from discussions, adding a photo gallery (or incorporating a feed from a service like Flickr) may be a valuable addition. Launching a pilot-level community first can allow these “in practice” directions of the community to emerge without a large investment in a different technology direction (in addition to the standard working out of kinks).