Vonage is a cloud communication company providing messaging, voice, and video APIs for developers to integrate into their apps.
What do developers want?
In the API business, API is either a product or enables your product. Developers wanting to use your product will require quite a wide range of items. They would need documentation, code snippets, tutorials, libraries, open API specs, standards, open-source contributions, sample apps, debugging tools, integrations, dashboards, free trials, multi-language documentation, and SDKs in different programming languages. If a developer wants every single thing, they wanted every single thing yesterday. This is the crux of the issue when businesses try to adopt Developer Relations practices. Usually, they start with the Developer Relations Department. In most cases, they fail because they don’t follow the best practices that make sense for the context of our business.
Businesses tend to invest in the loudest of demands without putting in place systematic methods to take into account what is the most impactful thing. The web is full of horrors of developer relations departments being disbanded overnight because it didn’t make sense in a business context. When we ask ourselves what developers want, I believe we always ask the wrong question. We should start with the desired outcome about work and work our way back towards very quiet action. So as a team that is part of a business, we should ask, what do we want as a business? What do businesses want, and why do we want to engage developers and spend all this time or resources trying to get them to talk to us?
What do businesses want?
Businesses need to fit into five categories based on their criticality.
Survival: The minimum we need is to ensure that we can stay in business. In some cases, this does include profitability.
Development: Increase growth and profitability and attract talent. This is where the business starts building up.
Relationships: Get to know customers and staff. Build the right relationships.
Recognition: Build a brand
Higher purpose: A mission
It probably all sounds familiar. It turns out it’s a known pattern of needs. Everyone is familiar with Maslow a hierarchy of needs. This is a slightly simplified version. All categories build on top of the previous one. But, a business can jump between stages. In the case of larger businesses, different departments can be in different stages at different times.
Current models to develop relationships
AAARRRP Strategy Framework
AAARRRP is an acronym for awareness, acquisition, activation, retention, referral, revenue, and product.
Phil Leggetter developed it. It is very similar to the traditional purchase funnel. It is a customer-focused marketing-like model that relies heavily on conversion numbers to drive decisions. This is why many businesses like this model for their digital strategy because it makes sense; they already understand this model.
The Orbit Model
It’s an open-source model that replaces conversion with connection. It’s a very interesting interaction-centric model. To put it simplistically, it tracks popularity. It sounds familiar because it’s going to the social networks. In this model, the audience is split into four areas, called orbits. At the center, you have the product, then the ambassadors, fans, users, and observers.
Every tracked interaction gets a score based on the size of the audience of people involved event interaction and the love they spread. It’s a rough estimate of the sentiment of each message project. This model is a bit more Kumbaya, and he tries to associate a value to your social network. Not sure if it’s necessarily the right thing, but that’s how they think your popularity gives you that score and determines how good that interaction is.
It is safe to say that this tomorrow will provide completely different insights into wherever the Developer Relations program is.
But you only get good results if you put in good data. So this brings us to the hardest problem in developer relations. And that is metrics.
It will be no surprise that data and trends are essential in decision-making.
However, it is very easy to say we’re doing a great job, because last quarter, we gave away 10,000 T-shirts with our logo. Is that good? Is that bad? Well, you need to track the correct metrics. So then you say, this month, we reached 100,000 developers. But did you interact with and respond to every single one? These are the next adjustments you need to make to the metrics to make sense to the business. The metrics of a business depend on the stage where the business is at. For example, a startup probably should not spend a lot of time building the brand or having a very public mission statement until it nails for basics and has a program that makes sense.
Metrics to track for developer relations
In most cases, we consider easy-to-track, visceral metrics –
website visits, readership, followers, event attendees, T-shirts, and the number of white papers. I call all these vanity metrics because they are very good to have, but what do they tell you about the actual trends?
For example, you want your organic traffic always to be ascending. You will probably want to speak in front of more people at events rather than less. And as long as the trend is in the right direction, it does not matter how you do it. Notice that most of his actions are push actions. So you go and do your stuff. But you know, what do these numbers mean?
Businesses have different metrics. They have financial metrics like revenue, profit, and ROI. They have internal and external facing metrics, anything from culture to monthly active users, and you see a lot of those go straight into the bottom line, be the fact that you need to make a profit as a business. As you go up on the hierarchy of needs, things like branding, social good, participating in creating policies, etc.
Business-Driven Developer Metrics
How about if we use the same metrics or very similar metrics to measure DevOps initiatives. So in the process, we can have business-driven development initiatives that are easier to track and make things easier for us to do our job. So let’s start with the same hierarchy of needs. At a minimum, you need good APIs and documentation.
For “survival,” the metrics for APIs and Docs will be “Coverage.”
That’s your business model; how many of your APIs are covered docs, including open API specs, snippets, and tutorials, that is good for developers to have.
On top of that is “development.” You need good SDKs, libraries, sample apps, or tools that make developers’ lives easier.
The metric for usage can inform you on how many ongoing resources you should be allocating to keep things up to date for all of these. You will have lots of demands for different things at different stages. You should use data to drive which ones you update more than others. You should use “usage” as data to make informed decisions.
And from here onwards are public-facing initiatives, creating partnerships and meaningful interactions. As you build your brand, you contribute back to the community by open source. Ambassador programs are also a great initiative at this stage. Don’t worry too much about tracking brand recognition. Your marketing department already knows how to do that. The mission is a very personal thing. You cannot define it. If you look at this from the bottom up, you’ll see that there are different stages, and probably as a business, you shouldn’t jump to the top if you don’t cover the basics. So having an ambassador program when you don’t have all the basics is not a good thing.
Measure everything. Each decision must be backed by data.
Prioritize the right things. Make sure that you prioritize the right things. For example, install an API call metrics if you have SDKs installed. Actual API calls have a direct correlation to the bottom line. So people pay to access APIs.
Prefer Pull to Push. A subscriber to your newsletter, for example, is probably more valuable than a visitor to your website. The subscriber wants to consume your content; that’s why they’re subscribed.
“Speak” business. You need to familiarize yourself with the business terminology and get to know your marketing and sales colleagues. You need to find ways to help them; once you have a good relationship with them, you’re off to the races. Being in the Developer Relations department, you get to speak to your customers. You bring back that feedback to your engineers, salespeople, etc.
Experiment, learn, rinse, repeat.
You should always experiment; you should find what works best and, again, is driven by data. You should be able to infer meanings and find different ways to test things.
External and Internal. Developer relations are both an internal and external exercise. It is a department that needs to work well, with all the errors inside the business. A lot of people miss the internal part.
These are our learnings.
Developer relations is a fun and rewarding activity. The best thing about it is the customer is a hero. The worst thing about it is the customer is a zero. You get to try new things. You can discover bugs and different issues and work with your colleagues towards correcting them.