Strategy for developer outreach
Three stages of building a developer relations strategy
Understand where you are.
Know what the situation is right now.
What it is in the world that you want to change
Know where you are, where you want to be.
Create a plan of action to make that happen.
DevRel specialised marketing.
Developers aren’t just another audience.
Developer-targeted tools aren’t just another product.
Maybe the audience knows more about the product than you do.
DevRel - AAARRRP Framework
Four pillars of DevReL
Outreach
Community
Developer experience
Development and support
DevRel Situational Analysis
Product
Competition
Company
Target
Developer relations is a specialised form of marketing that’s aimed at software developers.
When you think of it in other terms, then it’s very easy to get lost and detached from some of the things that are important to measure.
Developer relations are very long term.
Developers are experts in the thing that you’re selling.
They build a career on having an understanding of some very in-depth, technical subjects.
Developers will correct you in public.
They will not be embarrassed about telling you that you’re wrong, and so that means that you have to be right.
U can’t fudge this -- They’re betting their careers and their credibility on the choice of tool that they make.
They believe you, and they test it
At production, it goes ahead and it fails massively and they lose their job, then the stakes are higher.
People really need to be able to trust that what you’re saying is true.
You’re selling something very specialized, then they can probably, very easily tell when you’re fudging things.
Traditional marketing is a great deal about storytelling. It’s about selling a dream.
When you’re selling something very technical, you can’t fudge that detail.
Long-term relationships build trust.
They build credibility.
Build a one-on-one relationship with developers.
AAARP DevRel Strategy
Meet-ups.
About creating something online.
Blogs or other resources that bring people into your sphere.
Creating a process that enables people to feel recognised.
Feel like they’re contributing to something worthwhile.
Brings them from that aware developer to someone who is contributing back to your product.
MVP program or just something where you are actively encouraging and supporting people who are on your side.
API and SDK design, the documentation, the onboarding process.
Development where you provide excellent support to people.
If you plan well, then you’ve already won the battle.
A lot of developer relations is done off the cuff, is done without planning.
It’s done without thinking about strategy.
We need to understand where we are before we can plan on where to go.
What does your product change the world?
Quote If you’re not building something that makes the world different somehow, even if it’s a very small part of the world, then it’s probably not worth doing.
What is good about the tech?
What do we need to be honest about with our product?
What are the core use cases of your product?
What are people gonna be using it for?
“What are they good at?
What are they bad at, and how will people use it?
What are the core use cases for those products?”
And you’re your company. Your company, obviously, has a very big influence. Your product doesn’t exist in a vacuum. So what is your company’s role in the market? How your company interacts with the other competitors is going to influence how people see you.
Market leader.
Challenger.
Companies who are probably doing things that challenge the market leader, do more interesting things in some ways, but they’re not quite at the top yet.
Niche Player
Companies who are doing their own thing.
They’re quite happily bobbing along.
They’re carving out small businesses for themselves in a particular area.
Shooting star.
A company that’s got far too much venture money.
It’s spending it like crazy.
Survive probably till the end of the year unless they get another funding round, but the problem is they’re stealing all the oxygen because they’re spending loads of money.
Different drivers that send people towards and away from your product.
Understand these drivers by asking a bunch of questions.
Technical Drivers
You know, does it only run on Windows?
Does it require one or another particular language?
Does it require a particular platform?
Which technical use cases does it best suit?
Where does it sit in the development lifecycle?
Will greatly influence how we approach the market.
Developer Drivers
Questions about the developer themselves, the individual who you’re talking to.
How much commitment does our product require of developers?
What languages are they interested in?
What languages are they using?
Organisation Drivers
What sorts of organisations have a need for this?
What sorts of companies should we be approaching?
Where will they be earning their living or building their software?
Market Drivers
Competition
What’s happening in the industry currently?
Locations that might suit your needs.
Create segments in the market or amongst developers.
Once you have a bunch of segments that you’ve listed out, you can start to decide who to target.
Is it relevant to our business?
Are they actually gonna have a use for it?
Do they take those drivers that we had earlier?
Is it large enough?
Can enough money be made?
