Forming Product Communities in Web 2.0

by Bruce Taylor

It seems that virtual communities are growing up all over the Internet these days. We see the obvious candidates of MySpace.com, Gather.com, and Facebook.com, but there are thousands of smaller communities that grow up around special issues. Even a well-attended Web log constitutes a virtual community, and the "blogosphere" seems to be growing every day. In this article, I'd like to discuss one class of virtual community, the "product community" -- what it is, how it forms, and how to take advantage of it.

I'll define the term "product community" as "the whole population of people and companies that depend on a given product and have a vested interest in its features, longevity, and success." In the software and IT industry, we've had product communities for a long time: we call them "user groups." Usually we ignore them, except for once or twice a year when we treat them to lavish extravaganzas to demonstrate the latest products and features available for purchase. This model served the industry well from the 1960s through the 1990s, but it is about to become obsolete. This obsolescence will be driven by two factors: the increasing sophistication of software users, who understand exactly what they need and how they want it delivered, and the advent of massive changes in Internet capability and behavior, collectively called "Web 2.0."

The phrase Web 2.0 is getting a lot of attention these days -- a recent Google search produced 132 million pages -- but the term seems to mean different things to different people. Some sites use it as a technology definition of faster routing and switching; some see it as an architectural definition; others define it as a new set of application paradigms; and some see it as something frankly mystical. To radically oversimplify Tim O'Reilly's online article on the subject [2], the characteristics of Web 2.0 are:

• Decentralization of almost everything. All the things that go into an "application" -- data sources, indexing, applications, computing platforms -- may come from any of several sources.
  
  
• The "Long Tail." We'll see wider participation by smaller entities that contribute, in the aggregate, as much as the major players.
  
  
• Federations of applications. The era of the monolithic application is over, to be replaced by smaller applications joined by Web services APIs.
  
  
• Continuous change. Data, applications, configurations, and users are in a continuous state of flux.
  
  

Whether or not all of this comes to fruition, something is clearly going to change in the world of Web applications. Technology will change, application models will change, and, most interestingly, the relationship of application producer and consumer will change. Predicting the nature of the changes requires some crystal ball gazing, but we can make some good predictions based on theories from community psychology. Those application producers that embrace the changes are likely to surge ahead as the changes take hold.

So how exactly will the new Web 2.0 model encourage the development of product communities, and why should producers care? Imagine having a community of users that is fiercely loyal to your product, is willing and eager to participate in its development, and is active in recruiting new community members. This sounds like acquiring a second sales and marketing department for free, but it comes with some commitments. You have to participate in the community as an equal and treat the community members as peers, not simply as consumers who can be cajoled into upgrading to the next version of the product. In the rest of this article, I'll show how these communities will inevitably arise, thanks to the characteristics of Web 2.0, and then I'll recommend best practices for forming and sustaining a vibrant product community.

A LITTLE HISTORY

Back in the prehistoric days when all software was custom written, the producer-to-consumer relationship was simple, because one organization played both roles. When software became a commodity, however, things became a little more complex.

In the days of shrink-wrapped software, the relationship between producer and consumer followed Henry Ford's famous dictum: "The customer can have any color car he wants, so long as it's black." Customers were expected to make their business model correspond to the product's features, and the producer decided unilaterally on all new features.

In rebellion, users of various products started forming "user groups," the first proto-communities organized around important products. The original purpose of the user groups was to band the relatively weak individual users together into a force that could challenge the dominance of the producer. To some degree, this cohesion worked, and producers responded to directions from the user groups. Producers still held a monopoly on features and product direction, however, and user groups were relegated to semiannual training and sales events intended primarily to cement user loyalty to the product.

CHANGE IS IN THE AIR

The relationship between software producer and consumer has been changing in recent years, putting the two on a more equal footing. This change is driven by several trends:

• Increasing sophistication of the customer. People now occupying the senior IT and executive positions in customer organizations are very aware of the capabilities of software, and they are no longer content to accept "because we said so" from the producer. They are demanding greater participation in decision making about features for their key applications.
  
  
• Increasing competition. The only applications that are free of competition are those so new that they have some market to themselves. But increasingly, producers have to include customers in decision making as part of their retention strategy.
  
  
• Architectural changes. The era of the monolithic application is over, and the trend is toward highly modularized applications that can be customized without extensive rewriting. This architecture makes it possible for producers to provide their customers with highly specific versions of their applications without incurring the nightmare of continual support and maintenance.
  
  
• Open APIs. Customers now expect providers to expose important parts of the product functions through APIs (often Web services) so that customers and third parties can write add-on modules to the product without consulting the original vendor.
  
  

Finally, customers are demanding to participate in product definition, requirements specification, and even long-range strategic planning for their products. In the olden days, the producer used the customer's domain knowledge to define features and set direction through focus groups, contextual inquiries, and prototype evaluations. With the advent of agile development methodologies, user representatives form part of the customer team that sets large-scale and fine-grained requirements for developers to follow. The line between producer and consumer of enterprise-scale applications is beginning to blur, and we can expect that trend to continue and even accelerate as true product communities begin to form in the virtual space provided by Web 2.0.

HOW COMMUNITIES FORM

Here we'll take an excursion from the very immediate world of software development to a more theoretical field, community psychology, because we need to discover how communities form from inchoate sets of individuals. Loosely speaking, community psychology is the branch of social psychology that deals with the way individuals interact with their "social environment"; how societies form, adapt, and disintegrate over time; and how to construct social environments that are stable, dynamic, and reasonably beneficial to their members [1]. Usually, six conditions are necessary and sufficient for communities to form.

1. A CRITICAL MASS OF MEMBERS

Every community has a definition of inclusion -- a way of deciding who is "in" the community and who is "out." The definition may be more or less inclusive, and more or less explicit, but it defines the community membership. Communities with too few members disintegrate before they have a chance to form, for a variety of reasons. The critical number varies with the intensity of the members' commitments, but it can run from as few as three to several hundreds.

2. A SHARED PURPOSE

Groups of people form into communities only if they share a purpose or goal. In some cases, the shared goal may be simple survival, but it might be as sophisticated as "We want this application to better suit the way we do business." Without a goal like this, members drift off until, in the end, the community falls below the critical membership level.

3. A MEETING PLACE

Communities can't form if the members can't meet to decide issues and cement relationships. The definition of "meeting place" can be very broad: from a forest glade to a boardroom to a chat room. The meeting place must be easily accessible and enable all members to participate in the meeting at some level.

4. COMMUNITY MEMORY

George Santayana's famous aphorism "Those who cannot remember the past are condemned to repeat it" constrains community development. In so-called primitive cultures, community memory resides in the elders and storytellers. In more recent times, memories have been preserved in books, memos, and meeting minutes -- and there's nothing to prevent memories from being saved in databases and document repositories.

5. A COMMON CULTURE

There is some dispute about whether culture is really an attribute of a community or stands on its own, but for our purposes let's assume that every community has a dominant culture, and most contain subcultures. Community psychology defines "culture" in several ways, many of them quite technical, but we can use a very pragmatic definition:

The culture of a community is consensus on the way that community members have decided to treat each other.

It's a short definition, but the more you think about it, the more profound it seems.

6. AN ENFORCEMENT MECHANISM

Communities can't form and flourish as anarchies; they evolve their own cultures and must have some way of enforcing the norms and taboos of those cultures. Enforcement may be meted out by village councils, courts of law, or common consensus. Sanctions may range from social shunning to expulsion from the community, and these sanctions are administered by the community as a whole.

VIRTUAL COMMUNITIES

To see how these conditions operate, let's apply them to some well-known virtual communities and see how important they are.

USENET GROUPS

Usenet groups have been around since the early days of the Internet, and they once constituted a vibrant community of researchers and people sharing a common interest. In my opinion, these largely unmoderated groups now represent a failed community because they: (1) have lost the inclusion/exclusion test, (2) have diluted the common culture, and (3) lack the means of enforcing an appropriate culture. In unmoderated groups, there is no restriction on who can contribute to the group (i.e., no inclusion/exclusion test). This was a virtue in the early days, when people respected an unwritten culture, but this culture broke down when the Internet was opened up beyond the academic and industrial worlds. Most of the postings in Usenet groups are now spam and pornography, because the Usenet itself doesn't reward or punish any behavior. Only in the moderated newsgroups do you find working communities, because they preserve their charters and moderators exercise the enforcement role.

THE OPEN SOURCE SOFTWARE MOVEMENT

The open source software movement represents a dynamic, widely distributed community that appears to be thriving. We can look at SourceForge (www.sourceforge.net) as an example of that community. It is succeeding because it fulfills all six of the necessary conditions: (1) only registered members participate, (2) the shared purpose is explicitly stated in the "About" page, (3) the Web site is well structured for group participation, (4) the community memory is provided by the project and personal diaries and histories, (5) the common culture seems to be enforced mainly by peer pressure and correction, but (6) the SourceForge staff can banish chronic offenders by disabling their accounts.

ENABLING TECHNOLOGY AND PRACTICES: WEB 2.0

Now let's bring these two threads -- Web 2.0 and community formation -- back together. How will Web 2.0 facilitate the development of product communities, and how can you best take advantage of them?

MORE FLEXIBLE COMMUNICATION TOOLS

The most popular virtual conversation tools -- discussion groups, chat rooms, and instant messaging (IM) -- all suffer from the same problems. Discussion groups use a very static model of conversation: a thread of notes and replies that leaves a confusing trail of information. Chat rooms and IM are both evanescent and disorganized; it is virtually impossible to capture their content in any meaningful way for the community memory. In Web 2.0, newer communication tools are starting to emerge.

Wikis

Wikis have a great advantage over traditional discussion groups in that both their structure and their contents are only loosely defined and participants have an opportunity to contribute to the body of knowledge without special authorization. If this flexibility is not suitably constrained, it leads to a chaotic situation, but most wikis seem to be well believed if they are monitored by their contributors or by an administrator. The Wikipedia project (www.wikipedia.org) is an example of a very successful wiki that publishes a huge volume of well-indexed information contributed by a wide variety of experts. Wikipedia is successful only because people (paid and volunteer) are willing to manage its structure and ensure that its contents abide by explicit and implicit cultural rules. Without this investment, it would look a lot like unmoderated Usenet groups.

Publish/Subscribe Model

The advent of syndication (and especially Really Simple Syndication, or RSS) as a communication mechanism has radically improved people's ability to choose and aggregate information useful to them into a single information portal. Blogs, podcasts, and news feeds are all examples of syndicated information from which a user can choose only the bits that are important to his or her task. This is one method of reducing the "fire hose" of information available on the Web to a more manageable volume that community members can cope with.

PERVASIVE DATA INDEXING

The ubiquity of search engines and automatic indexing of text content by Google, Yahoo!, and others makes the Web minimally manageable for the average user, but it is still very difficult to find important information without drowning in a sea of false hits. Indexing becomes much more useful within a smaller universe like the intranet of a company, and many companies are using indexing software and hardware, such as Google's search appliance, as the primary way of organizing their organization's data.

Tagging

Search engines are undoubtedly helpful, yet they are limited in that they can only discover documents using key words and phrases, not semantics. Recently, however, sites like del.icio.us (http://del.icio.us) have started to provide a mechanism called "tagging," which lets users associate semantic tags with documents or pages. If tags were strictly personal, this would be no great advance over bookmarking, but individuals can share tag sets (called "clouds") with others and so expand their ability to search for documents based on their semantic content rather than their textual content. Amazon.com seems to be experimenting with tagging as a secondary way of searching its vast database of books, but the results of the experiment are inconclusive so far.

PERSONAL TELECONFERENCING

Most communication over the Internet is ultimately textual, because of tradition and because of bandwidth limitations. Creating a meeting with real telepresence requires significant investment in hardware and facilities. As bandwidth improves (especially under Web 2.0 protocols), it will be more common for users to initiate teleconferences from their desks, using low-cost hardware to share video and audio.

UNIVERSAL STORAGE

Even in our world of mega-storage systems, there still isn't enough storage to save all of a project's history. Therefore, most projects content themselves with saving documents that seem to be important. But experience shows that we humans aren't very good at forecasting what will be useful, so in the near future, projects will simply store everything and rely on very good indexing, searching, and tagging to make it available and useful. It's an open question whether high-bandwidth data such as videoconferences can be stored, and if so, how they will be indexed.

ESTABLISHING A PRODUCT COMMUNITY: TO THE PRODUCER

Speaking now to the producers of enterprise-level software: why would you want to spend the time and effort to establish, nurture, and preside over a virtual product community? I claim that if you have enough users of your system, a product community will inevitably form, simply from the laws of community psychology. Your only choice in the matter will be whether to play the leader or follower. There are certain advantages to establishing the community yourself. You can have a very large influence on the membership criteria and on the common culture, and if you provide the virtual meeting space, you'll be in a better position to enforce the community culture.

If a product community forms by itself, how can you take advantage of it? In the event, you'll find many opportunities on your own, but here are a few to think about:

• Use the community discussion for continuous feedback on product features and capabilities and as input to long-term product planning. Correspond with the users (those who care) about your plans and get feedback from a wide subset of your customers, not just a few focus groups.
  
  
• Use the shared experience of the users to help isolate difficult bugs. For example, syndicate the query "Has anyone seen this behavior?" and customers who are interested in that behavior will contribute a lot more diagnostic information than you could obtain from the typically vague trouble tickets that users submit to the system help desk.
  
  
• Use the domain expertise of your customers to educate your engineers and product managers in how the product is really used, how well it matches the business models, and how the customers' business models are likely to change. It is well documented that engineers who understand their customers' business produce much better software than those who don't.
  
  
• Increase customer loyalty. Part of your existing sales model is to establish the consumer's loyalty to your company and your product, but a certain percentage of customers will still flip to competitors. Suppose that you could establish their loyalty to the product community as well as to your product -- your customer retention rates would be much higher.
  
  

ESTABLISHING A PRODUCT COMMUNITY: TO THE CONSUMER

And now speaking to the consumer: why should you bother to join a virtual product community, when it means that you -- or your employees, or managers -- will have to spend time participating in the community on top of your normal job? Here are a few of the benefits (I'm sure that you will think of more):

• Share practical tips and advice. In a product community, you gain a new source of advice. You can syndicate questions like "We're having a problem making this kind of work rule match our pay model. Has anyone else encountered this, and how did you solve it?" Other users who have subscribed to the tips and advice feed may have an answer that will save you days of work.
  
  
• Put collective pressure on the producer. If you're not a very large, important customer (that is, if you're part of the Long Tail), you don't have a great deal of leverage to encourage the producer to add a feature that you desperately need or to improve the performance of an existing feature. Through the community, you may be able to form a coalition that is collectively large enough to get the producer's attention and make your problems stand out among the competing issues.
  
  
• Exchange add-on functionality. If the user can extend the product (say, through Web services), then you may have developed a set of add-on modules that solve some of your problems or implement some of your unique features. It's very likely that someone else in the community has a similar problem and could use your add-on. You don't need to contribute your work pro bono; you might set up a virtual marketplace for add-ons, which could operate on a barter or cash basis. Think of all the add-ons that the user community of the Eclipse Java IDE has developed and you'll see the possibilities.
  
  

Your competitors are part of the product community -- can you afford not to be?

CONCLUSION

This discussion has covered three seemingly disjointed topics: the history of software producer/consumer interaction; the theory of how communities form, sustain themselves, and adapt to changes; and the evolution of Web 2.0 technologies, applications, and paradigms. But the three threads come together into one string:

As enterprise customers become more technologically sophisticated, and as the projected features of Web 2.0 emerge, it is inevitable that users will form virtual product communities for major software products. These communities will be loosely coupled, but they will level the playing field between the producer and consumer, to the benefit of both. Using the product community effectively will vastly improve the producer's ability to deliver exactly the right software at exactly the right time, and participating actively in the community will allow consumers to use the products to their fullest benefit.

REFERENCES

1. Levine, Murray, and Douglas D. Perkins. Principles of Community Psychology: Perspectives and Applications. 2nd ed. Oxford University Press, 1997.

2. O'Reilly, Tim. "What Is Web 2.0: Design Patterns and Business Models for the Next Generation of Software." O'Reilly Media, 30 September 2005 ( www.oreillynet.com/pub/a/oreilly/tim/24news/2005/09/30/what-is-web-20.html).

ABOUT THE AUTHOR

Bruce Taylor is the owner and principal of WorkingInUnison, an organizational development consulting firm located near Boston, Massachusetts, USA. Mr. Taylor helps engineering organizations of all sizes to create low-stress, supportive, adaptable working environments so that the engineers, leaders, and managers can work as effectively as possible. He provides executive coaching for senior managers who are creating superior organizations, management coaching for technical leaders who are adapting to new agile practices, and individual coaching for engineers who are upgrading their skills.

Mr. Taylor has worked for over 30 years as a software engineer and system architect, and brings rich experience in software development processes that work in the real world. He has a master's in computer science from Duke University, a master's in community psychology, and a certificate in job stress and healthy workplace design, both from the University of Massachusetts. Mr. Taylor can be reached at bruce_taylor@workinginunison.com.