As we all know, developer marketing is a crucial part of any technology company's growth strategy. However, it can be incredibly challenging to directly connect developer programs to business outcomes.
I'm going to share how I've approached it and some of the best practices I've learned along the way.
Specifically, I’ll cover:
- Why are we talking about revenue metrics?
- How to identify the ‘right’ revenue metrics
- Mapping the developer and buyer journeys
- 3 key frameworks for revenue impact
- How to approach personas and optimize targeting
- Building the foundation
- Getting your projects prioritized
Why are we talking about revenue metrics?
It's a well-known fact that we shouldn't sell to developers, and to maintain the integrity of our programs and communities, we shouldn't even mention the word revenue.
That’s absolutely true. The moment you start selling to your community, you lose that trust. Depending on your business model, developers likely don't hold the purchasing power, and they don't want to be sold to either. But they can be fantastic influencers in the buying process for a technology that they love and want to use.
You can still maintain all of that authenticity and trust within your programs, while still telling a really powerful revenue story internally.
That’s okay because revenue is how a business becomes sustainable, and that allows us to do things like invest further in our developer community and provide even better programs and support to them.
Tying our work to revenue metrics helps ensure these programs get the funding that they need to thrive. It allows us to invest back into upstream open source development, maybe open source our own tooling for the community, or just continue to innovate on our product portfolio that we already have to provide better solutions.
It lets us create jobs because supporting people's livelihoods is incredibly important as well, and is especially important to think about in this current economy.
Each of these jobs then becomes another dedicated resource to our developer community.
At the end of the day, developer marketing is part of a greater team, and we’re all working together to make the organization successful, and hopefully reap the benefits of that for ourselves, our teams, and our communities. The health of the developer community and the health of the business go hand in hand.
How to identify the ‘right’ revenue metrics
Let's talk about how to choose the ‘right’ revenue metrics for your team. Most likely, there are already metrics in place to use that your demand gen or marketing ops teams are using.
If you're a SaaS or product-led growth company, you're probably looking at signups. If you're running more of a sales-led motion, that’s probably a sourced or influenced pipeline. And then you probably have some type of lead scoring model to drive marketing qualified leads or other types of lead classifications.
Signups are pretty straightforward, especially because developers are probably your target audience across the board in this case.
You most likely don't have to convince people of the importance of dedicating resources to developers, you just have to show how your programs are getting them to sign up. That can typically be done through unique UTMs on any of the links you're using to drive those signups.
Pipeline gets a little bit more complicated depending on if your company is looking at sourced or influenced pipeline.
Sourced is when the opportunity comes directly from one of your programs. In developer marketing, it most likely isn't because the buyer isn’t typically a developer. You may source some opportunities, but it's probably not going to do your programs justice to show their true value.
Influenced pipeline shows if a contact within that account engaged with your programs prior to becoming an opportunity. This still gives your program credit, but it maintains the integrity of the sales process, where developers are just influencers in the account, but they're not being engaged by sales. The buyer is the one engaging with sales.
We have both a product-led and a sales-led motion at Kong, so I like to look at both signup growth and influenced pipeline from developer marketing activities.
Then finally, you have “M”QLs. If you're an organization that wants to send developers to sales, and perhaps you have a technical SDR function to support them, then this metric can be valuable.
The great thing about “M”QLs is that they’re based on lead scoring, so you can fully customize them to your leads and your programs.
Scoring can be based on the activities they engage in, their title, and many other behavior and demographic-based characteristics. They get points for meeting those characteristics, and once they hit a certain point threshold, they then get sent over to sales.
For example, if you have a developer title and engage with the community program, we’d actually give you fewer points than if you had a buyer title and engaged with a webinar or an ebook because we don't want you to go to sales.
There are many different ways to customize this and a lot of different philosophies around it as well.
You can even create your own version of this, like a community-qualified lead, which is why I have the M in quotations to separate it out from MQLs and route them differently.
This one in particular is going to very much depend on your business model.
The benefit of choosing metrics that already exist is that you're using the same language across your organization, and it ensures alignment and continuity with the rest of the business.
At the same time, you have to maintain integrity within your developer community. Your developer programs shouldn’t feel transactional and be solely focused on sales. This is just for internal purposes, to tell the story of why this work is so valuable. Ideally, it shouldn't even impact your program decisions, other than to provide another indicator for what is or isn't resonating with the community.
This is why I also believe that revenue should always be a secondary metric because you have other primary goals for your developer community.
For example, we’re first and foremost focused on growing and engaging our developer community. The revenue metrics just help us translate that value to tell that story internally in a common language about how we're supporting the business.
The right revenue metrics allow you to connect developer marketing to broader business objectives, while still building goodwill and trust with your developer audience. They should create a path to monetization that feels natural and not forced.
Next, we're going to talk about how to map this to your developer journey in a way that feels organic.