A presentation at DevRelCon NYC 2024 in in New York, NY, USA by Phil Leggetter
From Funnels to Flywheels Phil Leggetter and Matthew Revell
We’ve been talking about this since the first DevRelCon How we plan, measure, report, and think about developer relations is a recurring theme. And that’s okay. For our profession to progress and to have the impact that we want, it’s good that we keep coming back to those questions.
In those nine years… And since 2015, quite a lot has changed. Let’s take a moment to think about what DevRel was like in 2015. For one, not many people were calling it DevRel. And there were more technical evangelists and developer evangelists than developer advocates. And, sure, what we think of today as developer relations had been around in some form for quite some time. But let’s be honest, those programs going back to the 90s or the 80s were one-offs. They were run by companies who had a quite specific set of circumstances that meant they had an individual or handful of people they knew could go out and engage with developers. The people doing the DevRel were a known quantity. And demand came from the developer side. Developer relations back then was mostly about making sense of existing developer demand. But in 2015, developer relations was in roughly year three to five of its Cambrian explosion. Rather than being an old boys club, DevRel was professionalising.
In those nine years… we’ve begged So at first we did our best to beg credibility. We tracked things and hoped something would stick. Mostly, it was numbers of events attended, people in the audience for a talk, number of blog posts published, that type of thing We measured output rather than outcomes.
In those nine years… we’ve borrowed But we’ve also done a great job of adopting and adapting tools and frameworks used elsewhere. We’ve been especially good at using ideas and practices from marketing, with whom we have so much in common.
In those nine years… and invented Perhaps most importantly, we’ve also created our own ways to plan and understand what we do. However, there are still some gaps. And perhaps that’s because the scope of DevRel is just so ambitious. We all know that the meaning of developer relations can vary from one company to the next. So, it’s no wonder that there are different ways of thinking about DevRel.
But DevRel is still in its infancy But that means that, in terms of operational maturity, developer relations is still somewhat in its infancy. That’s not to say that there haven’t been individual DevRel teams who do a great job of being organised.
Who has better framework maturity than DevRel? ✅ Sales ✅ Marketing ✅ Product Management ✅ Engineering ✅ HR But let’s think about our friends and colleagues in other departments. Each of them has one or more professional associations, shelves of books, even entire academic departments publishing standards, frameworks, and more.
Who has better framework maturity than DevRel? ✅ Sales ✅ Marketing ✅ Product Management ✅ Engineering ✅ HR And it’s worth noting that product management started to gain traction as a distinct discipline around the same time as DevRel but it seems to have a much clearer idea of itself. Perhaps it’s because there are so many fewer of us in DevRel than in these other disciplines. But whatever the reason for us having less in the way of standards etc, what matters is that we continue to find new ways of thinking about what we do.
In this talk, we’ll put forward an argument that there are cases where one framework alone is unlikely to be the best approach. Instead, you should use a combination of frameworks based on the specific situation you find yourself in. We’ll cover a few individual building blocks of DevRel strategy that we currently use, where they work, and some of the gaps they may miss. And we encourage you to do the same sort of analysis. We’ll introduce the DevRel Flywheel and how it helps us think holistically about DevRel, identifies those gaps, and highlights opportunities that may otherwise be missed. Finally, walk through a hypothetical but realistic situation to demonstrate the DevRel Flywheel in practice. Although we’re drawing on our own experiences and the experiences of those we know and have spoken to, we need more input to validate the idea and iteratively improve it. So, we would love for this to be the beginning of a
conversation.
Review of what we have now So, let’s review of few frameworks that we have now.
Funnel
Funnel: Origin story AWARENESS INTEREST DESIRE ACTION The funnel helps us think about what a person might need or do as their relationship with our product evolves. It allows us to package up interventions and responses based on what we think is likely according to what that person and people like them have done before. It also encourages us to remove people from the process quickly. For example, if someone is interested in our product but they don’t meet our criteria then we won’t continue to put effort into them.
Funnel: Origin story AWARENESS Elmo St Elmo Lewis Late 1800s So old, this bloke’s photo is in sepia INTEREST DESIRE ACTION The funnel isn’t perfect but it certainly has staying power. Its origin lies in the late 1800s where a bloke with the excellent name of Elmo St Elmo Lewis proposed the AIDA steps.
Funnel: Origin story AWARENESS William Townsend 1924 INTEREST DESIRE ACTION Later, another bloke writing a book on how to sell bonds framed AIDA as a funnel, with the key idea being that as someone’s propensity to buy increases so should our focus on them at the expense of everyone else.
Funnel: Origin story AWARENESS AWARENESS INTEREST CONSIDERATION EVALUATION PURCHASE DRIVE TRAFFIC CONSIDERATION CAPTURE LEADS INTENT NURTURE ENGAGE EVALUATION COMMIT DEVELOP CLOSE What’s great about the funnel is that it’s adaptable. We can come up with almost any set of intermediate steps or reframe those steps depending on what we’re trying to model.
Funnel: the good bits Funnel stage is a useful way to predict what someone needs Gives you a common language when talking to your sales and marketing colleagues Should reflect where someone is in their product journey Focuses your attention on people most likely to deliver a return It’s flexible, so you can adapt it to your needs And although it’s easy to dismiss the funnel as inappropriate or old fashioned, it does have it plus points.
Funnel: the bad bits Too linear to capture the reality of how people engage Focuses on one goal at the expense of others That focus makes people disposable Does not encourage systemic thinking And yet there are downsides too.
AAARRRP
AAARRRP: Origin story AARRR by Dave McClure is very well known within the startup ecosystem. It attempts, and mostly succeeds, at providing a set of universally applicable broad startup metrics that map to a journey - a funnel - for your customers. The terminology it tends to use is around a “website” but it’s easily convertible to developer tools and product usage.
AAARRRP: Origin story Acquisition - just a site impression. Not necessarily a signup or installation. Activation - same as “Hello, World” Retention - continues to use your product Referral - likes so much they tell others Revenue - pays to use Now to clearly depict this as a funnel.
AAARRRP: Origin story Although this is often seen as a funnel. I saw these to represent clear goals for a business.
AAARRRP: Origin story ● Acquisition: Get developers through the door: signup, download etc. ● Activation: Have developers achieve the “Hello, World!” ● Retention: Continue to use your product ● Revenue: Pay to use the product ● Referral: Love your brand and product so much they tell others What did stand out was that each of the “stages” clearly represented business goals. However, for me, it missed two goals that I felt developer relations can bring to a business…
AAARRRP: Origin story ● Awareness: Grow brand and product awareness with developers ● Acquisition: Get developers through the door: signup, download etc. ● Activation: Have developers achieve the “Hello, World!” ● Retention: Continue to use your product ● Revenue: Pay to use the product ● Referral: Love your brand and product so much they tell others ● Product: Help you build a great product for developers Awareness… And Product…
AAARRRP: How to use it ● Awareness: Grow brand and product awareness with developers ● Acquisition: Get developers through the door: signup, download etc. ● Activation: Have developers achieve the “Hello, World!” ● Retention: Continue to use your product ● Revenue: Pay to use the product ● Referral: Love your brand and product so much they tell others ● Product: Help you build a great product for developers How do you use AAARRRP? You sit down with the company stakeholders and agree on the goals for DevRel
AAARRRP: How to use it - goals ● Awareness: Grow brand and product awareness with developers ● Acquisition: Get developers through the door: signup, download etc. ● Activation: Have developers achieve the “Hello, World!” ● Retention: Continue to use your product ● Revenue: Pay to use the product ● Referral: Love your brand and product so much they tell others ● Product: Help you build a great product for developers
Choose a goal that your business wants DevRel to contribute to or own
AAARRRP: How to use it - activities ● Awareness: Grow brand and product awareness with developers ● Acquisition: Get developers through the door: signup, download etc. ● Written content ● ● Video content Activation: Have developers achieve the “Hello, World!” ● Retention: Continue to use your product ● Revenue: Pay to use the product ● Events -> Talks ● Referral: Love your brand and product so much they tell others ● Working with influencers ● ● … Product: Help you build a great product for developers ● Demos ● Events -> Sponsorships Then, once you have AAARRRP you can 1. 2. Map that goal to activities that will help achieve that goal
AAARRRP: How to use it - activity analysis To support this, there’s also a spreadsheet that helps you understand: 1. 2. Which activities may contribute towards multiple goals. For example, tutorial content can help awareness, activation, retention and potentially referral Which activities will be most effective via a weighting and scoring mechanism
AAARRRP: the good bits Proven to help teams with their DevRel strategy including Kong, Couchbase, Equinix, Huawei, … and Nexmo/Vonage. Customizable, systematic, and analytical approach Ensures alignment with company goals and with stakeholders
AAARRRP: the bad bits It’s not really a funnel so doesn’t consider the full developer journey Doesn’t consider the cyclical nature of communities a.k.a. no flywheel consideration
The Orbit Model
Orbit Model: Origin story So, funnels help us to model someone’s journey through a process. But, as we saw, they’re too linear when compared to reality. And the way that people engage with products and companies has changed enormously in the past 100 years. There are people who might never buy or product, or won’t buy it yet, but that have a significant impact on our product’s ability to survive and generate revenue. We kinda misuse the word community but that’s probably the best way of describing the people in orbit around a product.
Orbit Model: Origin story Communities are interconnected and most certainly not linear. So Josh Dzielak and Patrick Woods, now at Postman, developed some ideas that Josh had used at Keen into the Orbit Model.
Orbit Model: Origin story Gravity: the rate at which member involvement changes Love: an individual’s level of involvement Reach: an individual’s sphere of influence Impact: the output of the community
Orbit Model: the good bits Recognizes that value != $$$ Give us finer grained ways to think about someone’s involvement Thinks longer-term than a single, linear interaction
Orbit Model: the bad bits Harder to align with what other departments expect to see Focuses on community (not a bad thing) but it’s not a holistic model
Other approaches
DevRel Strategy: there’s more than one We don’t have time to cover all the options. But, needless to say, marketing funnels, AAARRRP, the orbit model aren’t the only options.
Existing frameworks are not holistic The common theme across all frameworks is they tend not to be holistic about both organizations strategy and about developers relationships with a brand or product.
Let’s talk about flywheels
Flywheels are a useful metaphor. In factories, in your car, in a railway locomotive, they act as an energy store. They’re usually heavy and big. So it takes a while to get them going. But once you’ve put a certain level of energy into them, they become ALMOST self-propelling. Their weight helps them achieve forward momentum. What works against the flywheel is friction. What works in its favour is that each subsequent turn should require less energy input, or give you more output for the same energy. And our colleagues in other disciplines have made good use of flywheels to describe holistic systems that, with the right inputs, can become almost self-sustaining.
Product-led growth, community management, HR, and other disciplines all have their own versions of a flywheel. And perhaps that’s not surprising because businesses and business functions work well when they act as engines that cycle through a process.
Flywheel: Components Stages
Flywheel: Components Inputs
Flywheel: Components Friction
Flywheel: Components Outputs
Flywheel: The good bits Holistic: Helps you think about how every part of your strategy feeds into the others, rather than focusing too closely on individual parts Sustainable: Encourages the creation of self-sustaining strategies rather than one-off initiatives Amplifies your effort: Each push of the flywheel is easier than the last Focuses your attention: By putting friction up front, makes it clear that there’s more to consider that only your inputs
The DevRel Flywheel
DevRel Flywheel: example outputs Discover: Content, events, partnerships, influencers, one-on-one outreach Activate: Tutorials, sample apps, developer stories, community support Implement: Docs, SDKs, tutorials Advocate: Champions programs, community nurture
DevRel Flywheel: example outputs Discover: Traffic, awareness amongst micro-influencers, sign-ups Activate: Better use case understanding, social media activity Implement: Case studies, forum activity, revenue Advocate: Community growth, blog posts, one-one-one advocacy
The DevRel Flywheel in (theoretical) action Let’s look at an example that combines using AAARRRP with the DevRel Flywheel and a Funnel.
AAARRRP + DevRel Flywheel: Begin with AAARRRP ● Awareness: Grow brand and product awareness with developers ● Acquisition: Get developers through the door: signup, download etc. ● Activation: Have developers achieve the “Hello, World!” ● Retention: Continue to use your product ● Revenue: Pay to use the product ● Referral: Love your brand and product so much they tell others ● Product: Help you build a great product for developers Begin by understanding your company goals using AAARRRP which is good for alignment here You identify Awareness and Retention as priorities. DevRel can clearly help there.
Map: AAARRRP to Flywheel stages Acquisition Awareness Activation Referral Product Retention Take a step back and look at the flywheel. And map AAARRRP to the flywheel. Revenue
Map: AAARRRP to Flywheel stages Acquisition Awareness Activation Referral Product Retention Revenue Awareness is at the beginning of the cycle and Retention towards the end. This opens up an interesting conversation and raises useful questions.
Identify Friction: between stages Acquisition Friction? Activation Awareness Friction? Friction? Referral Retention Friction? Product Revenue Are you using energy effectively? Where are the points of friction? Retention with Referral would feed energy nicely into Awareness. Can you try to also focus there? Do you have enough momentum between Awareness and Retention covered by other teams? Will you lose entergy in those phases or will other parts of the organization maintain the energy?
Identify Friction: between stages Acquisition Awareness Activation Referral Product Retention Revenue In our hypothetical situation, let’s assume that the company now identifies a gap with Acquisition The business adjusts it’s goals for DevRel to Awareness and Acquisition which map to Discover through to Activate in the Flywheel and thus increases efficiency And it’s really important that you’ve done this upfront, because the skills you need on a team to acquire developer can be different to those required to retain developer through, for example, community building.
Funnel: energy between stages Acquisition Awareness ? nel n Fu Once you understand the funnel stages and your AAARRRP goals, you can start to think about how you funnel energy between stages.
Funnel: between stages Success metrics? Acquisition Awareness Social engagement with blog post shares el? Awareness nn Fu Blog post traffic Sign ups Activation ? el? Funn Acquisition And, importantly, how you measure the success of moving between stages via a funnel. ● Combination: ○ In the hypothetical situation we started with AAARRRP to identify company goals. ○ We took at step back and look at the broader context using the DevRel Flywheel, to see if we’re using our energy efficiently. and ask important questions. ○ And back into AAARRRP to adjust out goals. ○ We then narrowed in on the Discover through to Activate stage and used a Funnel to help us move between those stages and identify what outcomes represent success.
Conclusion In developing the DevRel flywheel, we wanted to find a way to help us think of DevRel as a system. We have a lot of work to do, but MENTION COMMON ROOM
Conclusion MR: summary of earlier MR: This is the start of a conversation MR: thanks
Thanks to ● ● ● ● ● ● Rebecca Marshburn and all at Common Room Jen Sable Lopez Carmen Huidobro Kevin Lewis Sarah Dorward and everyone who came before us
How we think about DevRel can impact what we’re able to achieve.
Take the funnel, for example. If we use that to shape our DevRel thinking, we’ll naturally end up with goals and initiatives that can’t help us once a developer has reached the end of the process or, worse, will filter them out.
So, does that mean we need to use the orbit model, instead? The orbit model gives us a useful way to think about the relationships people have with our community but its focus makes it less useful for thinking about every aspect of our DevRel programs.
If we think of DevRel as a process focused on one very specific goal, then quite naturally, we’ll set goals and create programs that feed that goal, potentially at the expense of other beneficial goals.
The truth is, there’s no one-size-fits-all model for thinking about and planning developer relations. Instead, we need to use the right tools for the right job.
In this talk, we’ll look at:
We’re not going to pretend that the flywheel is a panacea, a panacotta, or pancetta. But we do think it’s a useful additional way to model how we plan and execute DevRel, alongside the other tools we already have.
The following resources were mentioned during the presentation or are useful additional information.
for free. You
can too.