My name is Dinesh Chandrasekhar and, at the time this article was written, I ran product marketing for the data and motion product line at Cloudera. I've worn many different hats over the years. As a developer, as an architect, I myself have been a developer evangelist at a couple of companies.
Today, as a product marketer, I have a very unique perspective of what it takes to build a developer program at various companies. In this article, I'll share my insights and my own experiences with you.
Here’s a breakdown of our main talking points:
- Developer marketing = paradox
- The developer program
- Where does one start to build a developer program?
- How to measure the success of your developer program
Let’s dive straight in. 👇
Developer marketing = paradox
Let's first define the phrase “developer marketing” and call it out as a paradox. There is no such thing as marketing to a developer. Developers are the best when it comes to sniffing out marketing messages and they'll clearly call them out.
You have to have a clear strategy, a different strategy than your traditional marketing means to connect with your developer community.
Enable, empower and embrace developers
How does it work, if you are to enable, empower and embrace developers? This is very important to devs. The fundamental philosophy is, never market to them!
How do you even connect with a breed of personas that detest marketing language? How do you embrace and empower them when they are trying to learn, try, and adopt your product, but, at the same time, you're not supposed to use any kind of flowery marketing language?
Developers are excited about new tech; they love new technology but, to them, time is currency, which means they need whatever they need right then and there. They can’t go through sign-up processes, long processes of engaging with sales teams, and so forth – if they want an API, they need it yesterday.
The important thing I also want to emphasize is they love being part of a larger community. This is where they get to share best practices, code samples, and so forth. For you to be successful in engaging with developers, you need to give them that platform and sense of community to build trust with them.
Developers! Developers!! Developers!!!
There are 27 million developers across the world today and we’re talking about over $40 billion worth of products being consumed, influenced, or purchased by developers. We're looking at a growth of over a trillion APIs by 2035, at least. This is truly a massive market opportunity for us to tap into as marketers but, at the same time, we have to acknowledge that product adoption starts with them.
The buyer's journey starts with them. They tend to use our products, they acknowledge they like it, and then they become the champions. They evangelize it, talk about it with their companies, and make it work for us.
The developer program
To be successful with a bottom-up approach, you need to make sure you are giving them enough to trust you and try out the products, so they can become champions. To do so, you need a developer program.
Let’s take a look at what a developer program is, and what it takes to build one.
What is the developer program?
What is a developer program and why do you need one? If we agree that nothing considered traditional marketing works for developers, how else are we supposed to connect with them? How are we supposed to embrace and empower them?
You need a specialist team, which I’ll refer to as the Dev Rel team (or the developer relations team). That team, and the resources you offer to this development community, are critical.
To engage with the developers, there needs to be constant care in building, nurturing, and enriching this developer community so you can gain their trust. It’s important to build and preserve this trust as well – you must have an ongoing focus on whatever you do and on how you communicate and engage with these developers.
This is what a developer program offers: the framework within these specialist teams and the resources that can work with them.
Developer experience (DX)
Developer experience is another term you may have heard when looking for alternatives for developer programs. A developer experience is a richer and broader way to define what a developer program is. It includes the people, the tools they use to communicate and engage or connect with the developers, and the processes you adopt.
Again, remember, developers don't like elaborate processes, even though they’re critical for measuring the success of a developer program. The content you offer to the developers, whether it’s rich technical content, documentation, or API docs, needs to also resonate as a part of this experience.
The events, the platform you offer, the community with which they can exchange various best practices, the thoughts and inputs (and having those discussions in an open forum); all that factors into this thing we call “developer experience”.
When would you need a developer program?
When would you need to develop a program? What are the types of offerings that you will typically have to warrant a developer program?
Not all products require one, so let's distinguish and identify which ones do:
PaaS type platforms like salesforce.com / marketplace
They've been phenomenal at offering a platform where other companies and other developers can build their own applications. Marketplace offerings like the Apple app store also allow developers to build applications that can help other customers. Providing that kind of platform is a great way to nurture a developer program.
Interoperable products
If you have a product offering with APIs that you want developers to consume, you need a developer program.
Developer / DevOps tools
Something like Microsoft Visual Studio, for example, allows developers to build all different types of applications using a variety of programming languages. This, in a sense, is what we term a classic example of where you would need a developer program.
Open source products
I deal with this day in and day out. Over the last four years, I’ve talked to open source communities and I engage with them. I offer content, mechanisms, events, you name it – the whole developer program that is needed to engage with this community. Open source equals developers.
If your product's primary end-users are developers
Your developers are instrumental in building programs that enable other users and users within the platform as well.
Where does one start to build a developer program?
Why is this a marketer’s guide?
A marketer is in the nexus of what’s happening within a company, particularly a product marketer like me. I engage with engineering, product management, sales leadership, and so many different teams cross-functionally.
I’m right at the crux of all this action happening. I'm also the liaison between all these different teams and I've been doing this in the last several companies I've been working with.
One of these was CA Technologies. Going back six, seven years ago, when I was tasked with launching a mobile back end as a service product, which was primarily a software development kit (SDK), I realized CA didn’t have a developer-facing front end.
No developer portal, per se, to connect or communicate with developers; they've never done that because they never had a developer product until that point.
I ended up launching developer.ca.com for the first time and what I learned from that experience is what I'm sharing with you in this article.
Process to kick off a developer program
These are the best practices I learned when I built that developer program at CA.
👍 Executive sponsorship: You need to do this because a developer program isn’t done overnight and you aren’t going to see the fruits of your labor right then and there. It takes time to build, meaning there’s a lot of engagement, as you need to build a community from the ground up, and so forth.
You're looking at 12 to 18 months in terms of seeing actual results from your developer program so you need to have executive buy-in to stay focused on your program and have the backing behind you.
🐯 Tiger team: Get all the stakeholders lined up for you; this would be across product management, engineering, sales, etc. Make sure everybody understands what you're doing and why you’re doing it.
📚 Educate everyone: If you're starting anew, you need to educate everyone. First, you need to make sure you tell them what a developer program is. I did this by hiring a third-party agency and coaching all of us in one single room. Go get all the stakeholders, the tiger team, in one room, and have the third-party agency train them on what a developer program is and set goals.
📊 Success metrics: It's not easy when it comes to developer programs. I guarantee you're going to have multiple opinions from multiple people on what we should be measuring, but the reality is you should stay focused on what is practical and what you should be measuring for a developer program.
🗓 Project plan/dates: Have a project plan clearly defined so you have short-term timelines of when certain deliverables will be achieved, as well as long-term of when certain things might happen. This is critical for all the stakeholders to be in sync with the developer program; keep them updated on status and progress as well.
💻 Developer portal: This is one of the first things that you will see internally, as well as externally, as the face of the developer program. It’s the façade through which the developers interface with your company and products – you can also offer various types of content to the developers through this.
Companies that have developer products will have a developer portal through which they offer API docs, technical documentation, and so on.
🤝 First DevRel hire: Your first hire might be a developer advocate or a developer evangelist and you want to make sure that person starts on the right foot using the portal as a mechanism. And not just the portal, but also social media and other channels.
You want a multi-channel approach for engaging with the developers and the dev community. While you may start with just one evangelist and one advocate, as you grow you will see the need for a community manager, a DevRel director, and a team of developer evangelists.
You will have more people on the team and start seeing the program expand and the need for more content arises.
Dos and Don'ts of a developer program
👍 Dos
- Internally, facilitate interactions between the various teams (DevRel, engineering, PM, marketing, and others) and primarily use this developer program as a way to interact and interface with all these cross-functional teams.
- Externally, you're allowing the developers to easily and quickly access the resources they're looking for. Quick is the keyword here, so make sure they can access these resources instantly and immediately without having to jump through hoops and various processes.
- Encourage the community to share best practices, code samples, and conversations. They can do it through Slack, on StackOverflow, and various channels, but the idea is to encourage them. You can also offer your own types of interfacing meetups, hackathons, Slack channels, developer events, and more.
👎 Don’ts
- Don't use marketing lingo because developers can sniff that out very easily.
- Don't expect leads from engagement and sales revenues from all this; eventually, it will happen, but don't expect them.
- Don't send too many emails for lead nurturing, which is also a big turnoff for developers. It's okay to send emails but the emails should be more of a newsletter type that includes technical content and product updates and asks them for input.
- Don't invite developers to marketing events, they don't like it.
Measuring the success of your developer program
This is what measuring the success of your developer program boils down to.
Product metrics
Product metrics are primarily about the number of calls made to your API; as I just explained, the number of downloads of your trial or your SDK.
More importantly, the number of product feedback inputs that you get from the community is truly telling of your engagement skills within the community. The more you engage with the community, the more trust you build.
They're gonna give you more input about your product, what works and what doesn't work, how it could be better, etc.
Community metrics
As marketers, we all tend to understand communities to a fair degree. We can measure the number of community members and the monthly growth – it’s pretty standard because you can look at social media metrics, likes, followers, etc.
If you are looking at having a separate social media account for your channel for your dev program, then that would be different, because now you are tracking specifically for that particular channel and the engagements that occur with that.
You might even need a specialized social media manager for your own digital team but, again, it depends on your company and your corporate strategy. You may choose to have the same channel for one or both but it's important to track the engagement from those levels.
Experience metrics
The experience metrics are very critical for us. They’re essential to understanding the number of users and signups to the site across several channels.
What is most important and interesting, and even harder to measure, is the developer satisfaction scores. The more you engage with them, their trust in you (if they feel happy with the overall developer experience that you offer as a company and as a product) starts to kick in.
That's where you begin realizing the developers and the community actually love your product, your company, the way you present it to them, and the way you engage with them.
Gamification metrics are also fantastic ways to engage your developer community. Microsoft mastered this years ago when they created the MVP program. They had different types of honors and badges and many companies have adopted similar types of models.
I’d encourage you to think about that because that's how you grow champions beyond your company. You can hire a few people who can speak for you about your product but it’s paid engagements or your own employees talking about it.
However, unsolicited championing on their own is something that you will not be able to get unless you are doing a great job at developer engagement with this developer program. When truly great, awesome products are delivered to developers the right way, developers become the champions for you as they start talking about it within their own companies.
That's where the whole ‘land and expand’ opportunities come into play. Once a developer loves and starts talking about it to the larger developer community within that company, your product automatically gets adopted within that company. That's how you grow.
To wrap up
I'll leave you with this last thought: the amount of time that it takes a developer program to be successful, from baseline to growth, is measured in years, not months or quarters. I cannot emphasize this more.
As you embark on this journey to build a development program within your company, you will realize many stakeholders are going to ask you, “hey, what are you guys doing? I know you have your DevRel team, is there talking to developers and all that? Where do I see any metrics or measurable, quantifiable metrics that say that you guys are doing a good job?”.
Time is a currency for developers but it's an investment for us as well. You need to invest the time in your developer community, nurture them and build that trust; that's most important. You have to come across as credible to win their trust and that's when they become the champions.
Then, you start seeing the fruits of your labor come into play. You start seeing your pipeline automatically grow and more inbound conversations coming in – for example, “we would like to have your company come in and do XYZ deal”, or they’ll have an opportunity, a conversation, engagement, or even a request for proposal.
Want more articles like this? Get fresh content in your inbox by signing up for our newsletter.
Developer Marketing Alliance
