Developer evangelists and onions
I wrote about what a developer evangelist is and about the purpose of an API strategy within which the developer evangelist plays a crucial role. Over the last two years I developed a developer evangelist model which I would like to describe here. Feel free to comment, criticize, re-use, or extend it. The beauty of this model is that it summarizes some of the most important types of activities of an evangelist and it is scalable. The model can be applied to a one-man-band evangelist as well as to a team of evangelists.
Here is how it works. The following figure shows the three main pillars at its core.
The three main pillars explained:
Events: As an evangelist you need to be present, at events, physically. These can be large developer conferences, developer days, barcamps, hackathons, workshops, or trainings. The difference between a developer day (e.g., bada developer day) and conference (e.g., API Strategy) is that a developer day is usually organized by one company or ecosystem player, whereas a conference is usually broader and covers more diverse topics. The physical presence is very important to be tangible by your audience and to add the personal touch to your product, which increases trust. It also helps tremendously in getting a better understanding of the real needs and pain points of developers.
Communication: Apart from physical presence a developer evangelist needs to be present in the virtual space and communicate. These can be ‘classical’ means such as an email newsletter or RSS, or social media such as blogs, twitter, facebook, or a Youtube channel. Ideally you segment your developers and provide relevant communication to each segment. In marketing-speak that is the segmenting—targeting—positioning process. I wrote about developer segmentation earlier, which may help. Finally, you want to let the community solve problems between its members. An open forum is a good means to achieve that. You could also outsource this to thrid parties such as StackOverflow like Netflix did.
Content: This is really the meat of the work of an evangelist. The quantity and even more important the quality of the produced content needs to be excellent. Relevant content in this regard are API reference documentation, simple getting started and how-to guides, sample code and open-source apps, app galleries (for inspirational food for thought), sandboxes or API consoles. Here is Apigee’s example of Twitter’s API console.
A very important maxim is simplicity. Developers have no time, so it must be crystal-clear what’s the benefit of your API or product and it must be dead-simple and quick to adopt. There is Pamela Fox’ notion of developer experience, which is a great guideline to follow.
In addition to the three pillars, we have a foundation and a top.
The foundation in my model is the constant sensing of the market or your community. That is achieved implicitly by being present in your community physically and virtually – as mentioned above – with open ears and eyes. But it should be enriched by explicit means to get a better understanding of the pains and potential gains of developers. Means can be online questionnaires, expert interviews, or focus groups, or a combination of these. I recently conducted a perceived-use value (PUV) analysis of an API program, where I combined expert interviews to identify new opportunities (features or services) with an online questionnaire to quantify these opportunities. The outcome was very insightful.
Sensing the market is very important to see on the one hand the impact of your work but on the other hand also to understand where the market is moving to, to spot opportunities and exploit them – e.g., by reporting insights to product development.
I call the top acceleration. You are not alone. Usually you work in a network of vendors and partners. These partners often have their own content distribution and communication networks and means. By working together mutually beneficial acceleration can be achieved. With the emergence of open APIs chances are increasing that your partners have API or developer programs themselves which can be leveraged.
Finally, here is why it is called "Onion" model. What I described so far is only the inner core. There are two more layers.
The second layer around the core is about pilot partner engagement. These are usually early adopters who you work very closely with to adopt your technology. This is hard work and very manual because you want to provide a very careful and personal support. Getting pilots live has two main advantages: First, you get great feedback about your technology deployed in a real life setting and you can improve it accordingly. Second, you can use a successful pilot as a case study example and for general promotion and awareness activities.
This leads then to the final ring in the Onion, which is about general awareness activities. This is pretty much using classic advertising, promotion and PR means to spread the word about your product. This targets more at the general public and less at developers directly. It is advisable to work closely with PR and marketing people or departments of your company.
As indicated by the arrow in the figure above pointing from the center outwards, the activities encapsulated by the Onion are less regionally focussed the more you move outwards. Events and communication can be very targeted and regional whereas general public PR is very broad and less regional.
Deploying several Onions
I mentioned at the beginning that the Onion is scalable. It is also adaptable. Ideally you would adapt the Onion to the particular segments. As an example consider the following scenario: you have two main categories you want to serve: big-head and long-tail developers (using Chris Anderson’s notion (see “The Long Tail”)). I call it ‘categories’ because for segments this classification is too rough. Secondly, you provide your APIs using two different access technologies: SOAP and REST. You can construct a matrix like the one shown in the figure below.
This matrix gives us four areas we need to cover with evangelist activities.
Let’s assume we don’t offer SOAP for the long-tail category (too much overhead, not popular, no adoption). Hence, there is no Onion in the fourth quadrant. We do provide REST for the long-tail, and in order to reach out to developers we deploy the whole onion except we don’t offer a pilot program for long-tail developers (second quadrant). On the other hand we do provide a pilot partner program for big-head developers, which are usually bigger brands but don’t do general awareness activities for this category (most of the work is done via direct work with leads) (see first and third quadrant). Finally, you can spot that in the first quadrant the content pillar is empty. We don’t specifically provide REST technology content for big-heads but refer to the content developed for long-tails.
This example should show how you can scale and adapt the Onion and deploy various of them customized for your developer segments.
Key take-away:
As Chris Heilmann wrote in his Developer Evangelist Handbook -- which I also described in the post “What is a developer evangelist” -- the work of a developer evangelist is very diverse and so is the skillset. With the Onion model I try to bring this into a picture to structure this and to bring it in relation to each other. The Onion should also help to focus and prioritize and it will also show you which activities you need to do more of for which developer segment. Finally, it should also help in scaling your work, for instance, if you need to build an evangelist team and if you need to identify the skills you need to look out for.