Where are you now? Situational analysis for devrel

The first step in building a developer relations strategy is understanding where you are now.

If you were a traditional marketer, this is where you’d do a situation analysis. Most likely that would take the form of a five Cs analysis:

• Company
• Competitors
• Customers
• Collaborators
• Climate.

As Developer Advocates we are interested in many of the same things but perhaps with different emphases. So rather than five Cs, we’re going to analyse our situation with COOL:

• Community
• Organisation
• Openness
• Legacy.

Yes, I feel some shame at coining a corny new acronym but, I swear, it just came out that way.

Community

If we consider community in a fairly broad sense, then it lets us look at where your project sits in the wider world, including:

• the competition
• any wider ecosystem into which your project fits
• community in the sense we probably understand it best: the developers and others invested in our project, either as users or contributors.

The competition

It’s unlikely that your project stands alone. Even a teleportation system written in Go with a ReactJS front-end would have competitors: walking, cars, planes and staying at home being amongst them.

First up you need to identify your project’s competitors. Make a list of any tool, service or software that either:

• is already available and solves a similar set of problems to your project
• could develop in a way that makes it a threat.

Your marketing colleagues will perform a similar analysis so that they can position against those competitors. For us, the criteria we analyse are a little different to what might interest the marketing team but it’s still all about giving us the understanding we need to position ourselves credibly.

For each competing project, and your own, make a list of:

• how the developer community views it
• how it compares with your project on technical merit and practical applicability
• its Developer Relations plan and activity
• its business model.

Pretty quickly, you’ll recognise two or three of the following:

• Market leader/incumbent: this could be a long established player being disrupted by a group of start-ups or it could be the start-up with the greatest developer mindshare.
• Upcoming challenger: the project that everyone agrees is the next big thing.
• Specialised niche challenger: perhaps it doesn’t do everything that your project does but it has sufficient cross-over to be a threat.
• Shooting star: the project that’s shining brightly and appears to be everywhere but is burning either money or developer goodwill far too quickly.

Take the time to learn what your competitors are doing in developer relations: attend their meet-ups, join their forums, read their blog posts, follow their advocates and engineers on Twitter, and most importantly of all: try their stuff.

Install their code or sign-up for their API and make something. Make something that gives you a visceral understanding of what a developer experiences when working with that project and take plenty of notes.

The ecosystem

Understanding your competition is mostly about preparing yourself to position against them. It’s not too hard to infer a company’s intentions and strategy from its actions. Once you know what everyone’s up to, and how they’re perceived, you can incorporate that in your plan.

Understanding your non-competitor ecosystem is a little less clear-cut. Your relationship with an open source project that repackages your own, for example, isn’t as straightforward as your relationship with a competitor. Often you’ll find yourself dealing with individuals whose intentions aren’t easy to divine. Similarly, instead of positioning against members of your ecosystem, you’re looking for ways to co-operate even though some of your aims might not quite line up.

Your project falls in the middle of an ecosystem that features:

• the upstream projects you rely on
• the sibling projects that work alongside your own
• the downstream projects that rely on you.

All parts of the ecosystem have a role in the success of your project but the particular balance of upstream, sibling and downstream will be specific to your project.

Just as you did with your project’s competitors, you should draw up a list of projects and organisations in your ecosystem and categorise them according to:

• relationship type: upstream, downstream, sibling
• organisation type: community or commercial
• current status: actively engaged with your organisation, stalled or uncontacted
• sentiment: good or troubled.

Next, for each ecosystem project you should identify:

• key people
• any notable past, ongoing and potential activity/friction with your organisation
• risks
• where your goals align
• where your goals diverge and what difficulties that could present.

Your developer and user community

Community, in the context of a software project, can mean a lot of different things.

If you’re from an open source background, that might sound like nonsense. Of course, you’re thinking, community can only exist around an open source project.

Then you meet a marketer who has been working with BI tools for the past decade. He tells you that he knows all about community. Community, to him, is a purely passive thing. His community is made up of business analysts. Their meet-ups are mid-afternoon in swanky hotel conference rooms where everyone is in smart business dress. They expect a sales pitch or, perhaps, high level tips on how to get more out of the expensive BI tool that brings them together.

Although we’re focusing on developer community, you should be prepared that not everyone understands what that means.

At this stage you need to learn two things:

• what community means to people in your company
• what community looks like for your project.

Once you understand what your colleagues, executives and investors mean by community then you can begin either to shape your thinking to include their needs or begin planning to adjust their view of what developer community should mean for your project.

Life stage

Next, you need to evaluate what developer community, if any, already exists for your project. Broadly, you’ll find it to be in one of five life-stages:

• Non-existent/nascent: this is a brand new project and you’re starting from scratch.
• Unloved and unorganised: developers are out there and they’re using your tool but there’s nothing that resembles a community and your company is making no or minimal effort to engage.
• Unengaged yet organised: developers have formed their own community around your tool and yet your company is making no or minimal effort to engage.
• Faded glory: there was once a thriving community around your project but engagement has dropped off.
• Mature: you have a strong community of developers, your company is engaged with them and there is a community process to help everything work.

Culture

As someone new to the community, whatever stage of life it’s in, you should take note of the internet’s most important maxim: lurk first. You need to gauge the culture and sentiment of the community before you try to do anything other than introduce yourself.

If your tool is hugely popular with government sector 9-to-5 Java developers, you might wanna hold off on that order for 1,000 t-shirts featuring an obscure Hitchhiker’s Guide to the Galaxy reference.

That’s not just a throw-away joke: you’ll get a strong indication of culture by understanding the language, framework and operating systems preferences of the developers using your tool. Speak to your colleagues in pre-sales to find out what customers are doing, look at language-specific driver download stats, trawl GitHub, search blogs and watch Twitter.

Once you have that basis, hang out in the places your developers hang out. Maybe that’s IRC, maybe it’s a .NET meet-up.

Of course, the culture of your company will also have some effect on the culture of your community.

What’s next

In the next post we’ll look at organisation and how you as a Developer Advocate put your reputation on the line each time you take a new job.