DevRel Scribbles
  • What are Scribbles?
  • Index
  • Developer Advocacy
  • Developer Advocates
  • Life as a developer advocate
  • Modernising Red Hat’s enterprise developer program
  • Engaging 9-year-old software developers
  • Making 22-year-olds love 26-year-old software
  • Dogfooding developer products: gathering insights from internal hackathons
  • How far does your ethical responsibility stretch for the tech your devs create?
  • Outside the lecture theatre
  • How do you design programs for diversity?
  • Build the Platform Your Developers Actually Want
  • Measuring dev rel programs far beyond marketing activities
  • Developer Evangelism
    • Developer Evangelists
    • How to rock a technical keynote
    • The Art of Slide Design
    • The Art of Talk Design
    • The Art of Story Design
    • Dev events beyond 2021
  • Developer Experience
    • The Power of Content
    • Building a Developer Community in an Enterprise World
    • How to lose a dev in three ways
    • Developer relations, why is it needed?
    • The hierarchy of developer needs
    • GitHub is your documentation landing page
    • Docs as engineering
    • Commit messages vs. release notes
    • A11y pal(ly)- crafting universally good docs
    • Inspiring and empowering users to become great writers, and why that’s important
    • Solving internal technical documentation at Spotify
  • Community Management
    • Building community flywheels
    • DevRel = Community Management?
    • Creating high-quality communities
    • How to grow a healthy Open-Source community?
    • Managing communities at scale
    • Using community to drive growth
    • Useful community success metrics
    • Communities aren't funnels
    • How to mobilise your community during a pandemic
  • Managing a DevRel Team
    • Developer Relations + Product
    • Distributed developer relations
    • Understanding company goals
    • DevRel Qualified Leads (DQL)
    • Path to success for DevRel
    • How to move up in your organization
    • Four pillars of DevRel
    • Building your DevRel dream team
    • Managing the burnout burn-down
    • I messed up and I’m going to get fired
    • How to report on community relationships without being creepy about it
    • How to scale a developer relations team
  • Misc
    • Is developer relations right for you?
    • Tooling your way to a great DevRel Team
    • Planning your DevRel career
    • Success metrics as narratives
    • Get executive buy-in or else
    • Introduction to the AAARRRP devrel strategy framework
    • Strategy for developer outreach
    • Connecting dev rel and product
    • Performance DevRel
    • Ultimate cheat codes for healthier travel
Powered by GitBook
On this page
  • Summary:
  • Scribbles:
  • Dev Rel: 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.
  • The Dev Rel funnel
  • Four pillars of DevRel
  • Outreach
  • Community
  • Understanding where you are
  • Product
  • Competition
  • Company
  • Climate

Was this helpful?

Export as PDF
  1. Misc

Strategy for developer outreach

Matthew Revell talks about almost everything around developer relations and fundamental stages in creating a developer outreach strategy.

PreviousIntroduction to the AAARRRP devrel strategy frameworkNextConnecting dev rel and product

Last updated 3 years ago

Was this helpful?

Summary:

  • 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

Scribbles:

Dev Rel: specialised marketing

  • 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 aren’t just another audience.

  • 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.

Developer-targeted tools aren’t just another product.

  • 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.

Maybe the audience knows more about the product than you do.

  • 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.

The Dev Rel funnel

  • AAARP DevRel Strategy

Four pillars of DevRel

Outreach

  • Meet-ups.

  • About creating something online.

  • Blogs or other resources that bring people into your sphere.

Community

  • 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.

Developer experience

  • API and SDK design, the documentation, the onboarding process.

Development and support

  • Development where you provide excellent support to people.

Understanding where you are

  • 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.

Product

  • 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?

Competition

  • “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.

Company

  • 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.

Who are your target developers?

  • 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.

Climate

  • 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.

So how do you choose which groups 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?

Introduction to the AAARRRP devrel strategy framework
Video