Should an Open Source Community Manager Report to Engineering or Marketing?

Back at OSBC in 2009, Stephen Walli and Dave Neary discussed the role of community managers and I was sitting at the same table. Back then, I was not really sure which stance to take, whether it was better for a community manager to report to marketing or engineering. After all, there are pros and cons, and it’s important for any company that’s serious about its Open Source business to consider the question carefully.

Now, two years later and with quite some more experience based on the consulting for my customers, I have an answer.

Marketing

When a community manager reports to marketing, there is a danger that the manager will fall into the traditional marketing mindset and will see his or her primary goal as the acquisition of leads for direct sales staff (Stephen discusses this in more detail). As a result, the community manager may attempt to “hard sell” the Open Source product to community participants, rather than working to indirectly drive product adoption through community engagement. Needless to say, any Open Source company that is perceived as using its community purely as a marketing vehicle will face a negative backlash, and an overall failure in its community development efforts.

It’s not all bad news, though. There are some positive aspects to having a community manager report to marketing. For example, it gives the community manager an opportunity to serve as an intermediary between the company and its community, ensuring that the community’s views are reflected in the company’s marketing strategy, and the company’s goals don’t conflict with or belittle those of the community. Having a community manager with his feet in the marketing stream helps the manager understand the company’s positioning vis-à-vis the marketplace and communicate this positioning to the community; it also helps the company fully understand the needs and goals of its community and take steps to realize these goals.

Engineering

Now, let’s look at the other side of the coin: a community manager who’s attached to a company’s engineering department. The downside of this arrangement is the ever-present danger that the job of community management will become seen within the company as a purely technical task, involving the installation of version control systems, wikis and mailing lists, and will not be perceived as a marketing and communications task.

In the first instance, this perception limits the pool of available candidates for the job; for example, a company might reject an applicant who has good communication skills but lacks a technical or engineering background on the grounds that he/she is “not technical enough”. But more importantly, when the job of community management is reduced to a set of technical tools, it squanders the rich opportunity the company has to enter into a conversation with its community on equal and respectful terms.

That’s the downside…but there’s also an upside to having a community manager report to engineering. Consider that at the end of the day, the community’s raison d’être is the software being developed by the company, and the features and value addition this software brings to the members of the community. This software is being produced by the engineering team and so, in one sense, the community and the company are most closely tied to each other through this team. It makes sense, then, that a community manager should report to engineering, as he or she can directly transfer feedback and feature requests between the software development team (the creators) and the community (the end-users).

In Search for the Best Department

So which should it be: engineering or marketing? And is there even a one-size-fits-all solution?

One approach would be to make community development an independent department, because it needs to counterweight as well as connect with various other business areas. For example, a strong community development department will ensure that marketing doesn’t abuse the community purely for monetization, and it will ensure that the community’s voice is heard without dilution by the engineering team. At the same time, treating community development as equal to marketing and engineering, rather than subordinate to them, goes a long way towards establishing the company’s credibility among developers, end-users and partners.

There are two problems with the above:

  • Separating community development from marketing might have the effect of further cementing the distinction between the two, whereas in reality, community development and marketing have a lot in common.
  • Community development is still a relatively young discipline, and many firms (even Open Source firms) are likely to find it too radical to create a new department solely to manage their community, also because it might still be hard to find senior community managers.

In these situations, it makes sense to have a community manager report to marketing rather than engineering. This is because community development is an open and organic process involving multiple conversations between the firm and its community. The community manager’s job is to serve as an intermediary between the company and its community, and to foster product adoption through community development. In essence, community development is more of a communication effort than a technical effort, and so it falls closer to marketing than engineering.

This is not to say that a community manager needs to be completely indifferent to the product; he or she needs to be knowledgeable enough about the product to answer questions and moderate community discussions. However, it isn’t necessary that he or she belong to the engineering or product development team to perform this function well.

To illustrate this point, think of any non-IT company: for example, a fashion label that has an active community of enthusiasts and loyalists. A community manager for this label would certainly need to know about the latest designs and in-season fashions, in order to communicate with the community; however, he or she wouldn’t need to be involved in selecting the fabric and the cut, or in actually stitching the garment together. The most logical association for a community manager in such a firm would be with the marketing department, rather than the product development team.

Another good (though temporary) solution is to create a joint community development/marketing task force that consists of both community manager(s) and marketing team members. This joint task force works like training wheels for executives used to traditional marketing techniques and helps them “get it” faster. This allows community managers to sensitize the rest of the marketing team about how to handle the community; in particular, to understand that the key metric of community development is not monetization, but product adoption.

Community Marketing

It should be clear that choosing where your community manager hangs his or her hat is a question that requires thought, not least because it can influence the entire role of marketing within your firm.

The best approach is to establish a Community Marketing team, lead by a community manager, within your marketing department. Yet, this will only work if marketing regards itself as a moderator of market conversations. Rather than serving as a “gatekeeper” of information, marketing should become a “facilitator” of information, especially in Open Source and due to the still growing importance of social networks and media. In a similar vein, the marketing process itself changes: rather than being all about lead generation, it becomes a more comprehensive process unobtrusively combining product adoption driven by social conversations and collaboration with lead capturing, field marketing, etc.

Cross-pollination and knowledge transfer between community development and marketing will reshape how marketing perceives itself and vice versa, because the development team will learn how to communicate better.

This shift in marketing is not an easy one for any firm to make, but it’s a necessary evolution for any firm that’s serious about building a community and fostering a bottom-up adoption program for its product.

Improve Your Open Source Sales Funnel with Targeted Marketing Collateral

One of the great things about Open Source software, is its ability to significantly cut the length and expense of the sales process, by allowing prospects to “self-qualify” themselves for the product offering. Simply put, because an Open Source software product is freely available for download, potential users can get it, try it out, and decide for themselves whether it works for them. If it does, they can then decide to approach the vendor for additional services or technical support.

From the Open Source vendor’s perspective, this is a great place to be, because it’s getting a constant stream of leads which are (a) already educated about the product and (b) interested in pursuing a commercial relationship. This makes things much easier for the vendor’s sales people, because they typically need to do far less work in convincing the prospect of the suitability of the product and they can instead focus on meeting specific requirements and closing the deal. In summary, a shorter sales cycle for the vendor and clearer expectations/less disappointment for the customer.

Understand the Buying Process (and the Buyer)

The trick to this, of course, is to ensure that prospects have enough information to self-qualify. And this is not simply a matter of “provide a download link and they will do the rest”. For an Open Source vendor to fully exploit the informational advantages of Open Source, it needs to make sure that potential customers have all the information they need to satisfy their questions and concerns independently. And so, it is necessary to prepare and make available different types of marketing collateral for each stage of the buyer decision process.

There are two important aspects to consider here.

1. The stage of the buying process

The typical buying process consists of need identification, research, evaluation of alternatives, purchase and post-purchase evaluation. These stages are performed sequentially, and the prospect’s information requirements change from one stage to another.

For example, in the first and second phases, the prospect may have a wide range of options, but as the evaluation progresses, the field is whittled down to a few likely candidates. Correspondingly, the granularity of detail required also increases: for example, in the first two stages, the prospect may only be interested in (say) the platform and integration requirements, but once the main candidates are identified, the prospect will examine each in detail to understand the relative benefits of each. This is clearly seen in the following simple diagram.

2. The status of the buyer

The status of the buyer must also be considered. In small firms, the economic buyer (the one who actually pays for the product) and the decision maker (the one who takes a final purchase decision) might be one and the same. However, in larger organizations, the decision maker might be a developer, while the economic buyer might be a business manager or CFO. The information provided must be correctly targeted to the buyer’s status within the organization.

For example, consider the evaluation stage. At this point, a developer is keenly interested in the technical benefits of the product and so would gain maximum value from technical white papers, sample code, technical presentations, and other collateral that illustrate the technical capabilities of the product. However, a business manager at the same stage of the process would like to read case studies of similar deployments, white papers about collaboration features, data sheets listing service and support options, and so on.

Marketing Collateral Cheat Sheet

Here’s a quick cheat sheet, based on my experience, of what you could provide to different types of prospects to help them at each stage of the buying process:

Information search Evaluation Purchase
Business Manager or CxO Product brochuresBusiness white papers

Third-party reviews

Case studies for similar deployments

Service and support data sheets

Sales presentations 

Demos

Project Manager Product brochures 

Business white papers

Third-party reviews

Case studies for similar deployments 

Service and support data sheets

Competitor analysis

Sales presentations 

Demos

End-user or Developer Technical feature overview 

Technical white papers

Third-party reviews

Technical manuals or API documents 

Demos

Screencasts and videos

User manual

Demos

A final question to consider: how do you actually make all this material available to prospects? The best way is through your Web site, as this offers several advantages:

  • It’s the first place a prospect will visit for more information on your product/service offering.
  • It’s publicly accessible, which means that sales people (yours and your partners’) can use the same collateral for direct sales.
  • It’s central and 100% under your control, which ensures that updates occur in a single place and you don’t have to worry about salespeople or partners working off outdated material.

Conclusion

Open Source offers a number of advantages, and these are not restricted only to the software aspects of your product or service. By making available as much information as possible, you’re allowing potential customers to validate your offering against their needs, and giving them the tools to make an informed decision. This allows them to self-qualify or self-disqualify themselves, serving as an automatic filter and granting you the benefits of a shorter and more effective sales cycle.