The funnel is widely accepted in sales and marketing circles, but despite its popularity, we think it has a few shortcomings when applied to developer relations:
For certain teams, the funnel remains a useful model. In fact, many marketing teams are judged on how effectively they move leads through the funnel.
That said, DevRel teams need tools and models created specifically for our discipline, and not just those adopted from other fields.
That’s because other models assume a specific kind of buyer-seller relationship, but developers don’t shop in the same way as other B2B buyers.
For example, a dev might use a tool for years before purchasing. Or they might never purchase at all, but given their influence, they might refer dozens or hundreds of paying customers.
That person deserves attention from the company because they can influence growth, but the funnel doesn’t know what to do with them. Short-term conversion is the wrong thing to optimize for, so how else can we effectively model this kind of relationship?
Creating consistent, authentic connection opportunities between developers is the most reliable way to introduce new tools into the developer community and help them grow.
Connection is people-centric, not stage-centric, and therefore excels at producing that most important of moments—the moment in which one developer passionately refers your product to another.
This moment is the wellspring of word-of-mouth growth, an essential type of growth in a situation where traditional marketing is ineffective. Word-of-mouth referral can happen in many contexts, both online and offline.
The mission of a developer relations team following the orbit model is to facilitate high-quality word-of-mouth exchanges.
But given time and budget constraints, DevRel teams can’t dive deep with every developer in the community, so how can you create context for connections at scale? Whether we like it or not, good strategy is all about hard choices, and one of the most important choices DevRel teams make is how to give different groups appropriate levels of engagement.
The Orbit Model accounts for the complexities of community, and allows DevRel teams to segment developers more effectively, and then to take action by facilitating connections between developers with and across segments, pulling the community together as a whole.
The first step is segmentation, but given the complex nature of the developer relationship, the linear nature of the funnel’s stages don’t work well. Instead, try to think about grouping your audience into levels of orbit.
Orbit levels aren’t set in stone, and you should tailor your levels for your situation, but we find that four orbit levels works well for most developer-facing companies.
They are: an inner circle of developers that are highly satisfied, knowledgeable users of the product and have a large influence in the broader developer community
You might ask them to: speak at conferences, organize events in local communities, run workshops, build plugins and integrations, amplify announcements, be a customer reference, and advocate universally
They want: visibility, help building their brand, exclusive or early access to features, direct lines of product support, speaking engagements, training, free product usage, overall to feel like a VIP
How to connect: 1:1 email, Twitter DM, messaging apps, shared Slack channels, video calls, IRL, i.e. make it personal
They are: a wider circle of developers who are passionate about the product, have successfully used it, and are happy to share their expertise with their sphere of influence
You might ask them to: contribute to documentation and SDKs, build hackathon projects, write blog posts, moderate forums and chats, build showcase projects, give detailed feedback, attend and speak at meetups, attend conferences, beta test new features, host internal workshops, and advocate locally
They want: learning opportunities, reputation-building, speaking opportunities, special swag, discounts, higher quotas, financial support and resources for their community
How to connect: Owned community chat/forum spaces like Slack, Discord, Spectrum, Discourse, GitHub issues and PRs, social media, IRL at events
They are: developers who are actively using the product, and who at a minimum have some online or offline interaction with other developers
You might ask them to: introduce the product to colleagues, be the champion in a deal, upgrade to a paid version, try out new features or related products, and advocate internally
What they want: a fast and reliable product, solid documentation, well-maintained SDKs, high-quality support, extensive library of demos and examples, generous free tier, reasonable self-service pricing, swag
How to connect: customer support, office hours, product-centric email campaigns, feedback widgets, on unowned developer channels like StackOverflow, Reddit, HackerNews, DEV, et. al.
They are: the rest of the developers who’ve shown interest by signing up, trying out or subscribing, but aren’t active and may not have a need for the product yet
You might ask them to: read content, browse high-level documentation, execute lightweight code samples, play with an example app, participate in games, contests and challenges
What they want: Quality on-trend technical content, high-level product-centric content that explains use cases, guides and tutorials, starter kits, community projects, social proof, games, entertainment
How to connect: Content marketing, newsletters, advertising, brand awareness
So how do you know what developers go into which orbit? There’s a general equation that’s driving the segmentation above. It looks like this:
Love = love for your service, a function of sentiment and product familiarity. Reach = reach to their peers, a function of the size of the developer’s sphere of influence and their authority within it.
Both dimensions are important. If there’s no love, reach doesn’t matter because there won’t be anything valuable to say. If reach is zero, there’s no one there to spread the love to.
Gravity (Love x Reach) is the criteria for segmenting developers, but it also provides a clue for increasing the value of your community.
The higher the gravity, the lower the orbit.
The ultimate goal of the Orbit Model is to help you maximize the amount of gravity in your solar system. Gravity is a force of attraction. The higher the levels of developer love and connection, the better your community will be at attracting new developers and encouraging existing members to participate more.
To build a high-gravity developer community, DevRel teams following the Orbit Model should:
How can this be applied on an everyday basis? Here’s an example that should be familiar to any DevRel.
Let’s say we’re launching a new feature and want to email folks about it.
Orbit level is a way we’d segment the message. Orbit 1 (O1) and Orbit 2 (O2) might get a message earlier with an ask to help beta test coupled with more detail or transparency that wouldn’t be appropriate for a mass mail, but would be more likely to drive engagement with them. We would then tweak the mass distribution to O3 and O4 based on input and feedback from O1 and O2.
Want to apply the Orbit model in your DevRel team? It’s a big vision, but the orbit model can be adopted incrementally. Start with O1 by creating a spreadsheet and filling it with your most engaged and influential developers. Then moved up to O2. For both O1 and O2, list out what you can ask them to do and what you can do for them in return. Create some next steps to make that happen and you’re already off to a great start 🚀
In the future, you can incorporate the model into your CRM and top-level KPI reporting, but today you can already get value from segmenting your outreach.
You can also read more and contribute to the Orbit Model on GitHub.
Want to automatically track Love, Reach, and Oribt Levels? Signup for early access to Orbit.
Thanks for reading!
Don't miss Orbit Co-Founder & CTO Josh Dzielak's talk about the Orbit Model at DevRelCon London 2019.