Social Media
If DevRel is looked at as a “marketing method to spread products and services targeting developers,” one might think that it cannot be used if such services are not being made. However, DevRel is something that forms good and continuous relations with developers, so it is an initiative that has a large range and can be used more.
I will now look at DevRel from three different perspectives and consider those values.
Having in-house manufactured products and services be used leads to the profit of the company. For example, this applies to IaaS vendors such as AWS and GCP and SaaS vendors such as Stripe and Auth0. This is also true if API is provided for a fee. In this case, if developers are employed through DevRel, this will lead directly to an increase in revenue, it will be easier to compute the intiative as a cost. In this case, if there is a DevRel team under the marketing department, it will be easier for them to act after a budgetary allocation.
In the case of a direct revenue type, DevRel’s values can be looked at with a focus on number of users, number of inquiries, number of API calls, rate of activity, number of cases, and so on. Hands-on activities are effective in increasing the number of users, and to increase the number of cases, policies such as hackathons are easy to initiate.
In any case, it is easy for the direct revenue type to conduct DevRel and it is also a form that has many advantages.
This is a case in which the source of revenue of the main service is elsewhere and API is provided to assist and increase awareness of it. For example, this applies to restaurant service APIs, APIs provided with social significance, and so on. As for use in business, there are many cases in which agreement is obtained by consultation, and there are not many examples that are connected to actual cases. In this case, for DevRel, it is often the case that the purpose is to increase developers’ awareness of it, so it is more advantageous for the DevRel team to be in the development department. It is likely that feedback from developers can smoothly permeate the company and events and so on can also be conducted from the developers’ perspective.
In the case of the indirect revenue type, as revenue is not the aim, there is the problem of not being able to establish goals. Just increasing the number of users does not result in revenue, and on the contrary, this just leads to an increase in the burden on the server, leading to a cost increase. The same applies for the number of API calls. If the main service does not target developers, increasing developers’ awareness of it does not lead to an increase in revenue, making it difficult to implement the policy.
It is not good to neglect publicized APIs just because it is not related to revenue. It is likely that the credibility of the main service will be doubted due to unexpected security holes and old and neglected documents. If publicizing an API, it would likely be good to limit it to something that makes dogfooding possible (originally, it should be the other way around, and we should publicize what we use).
Possibilities for indirect revenue types arise when there is talk of tie-ups between corporations. WIth an API, the development when tying up services can be conducted smoothly. WIthout an API, an API will have to be developed according to the needs of the company with which the tie-up is being conducted for the first time. As a result, it might be an API that cannot be used for tie-ups with other corporations. ALso, if an API is not publicized, it might not be considered for tie-ups in the first place.
Last is for branding purposes. In this case, publicity of human resources will take the initiative. In the case of branding as well, it would likely be better for the DevRel team to be in the development team. By continuing on-site development, new topics can constantly be provided. Good examples include Cookpad and Class Method (although they probably are not in the forms of DevRel teams). Their aims are likely company branding and an increase in the employment of developers.
For example, having engineering blogs, setting up booths at conferences, and so on are carried out as policies. On the contrary, it is likely that user communities are difficult to establish. It is also common for communities to be established with the development language that the company considers itself most skilled in as the theme. It is difficult to quantify branding, but the number of employment entries can be counted quantitatively, so it is a policy that is easy to implement.
Other than branding, it is likely that even direct revenue types and indirect revenue types have these goals. Nonetheless, multiple messages will make it difficult to have an effect on the target group, so caution must be exercised.
The problems are likely DevRel’s initiative and continuity with regards to indirect revenue types. When there was a large buzz regarding Web2.0 around 2004, many corporations provided APIs, but many of them only distributed information and were unable to generate content. These APIs are still being provided, but they have been all but abandoned. That being said, an increase in users does not necessarily result in revenue, so there is likely no need to intentionally provide support. If architecture undergoes large changes in the future, the API might be closed suddenly. It is a common mistake to think that it is sufficient to just prepare a period of notice, but to developers, this is likely the ultimate inconvenience.
Google Maps API used to be free, but has been made to be paid. It can be said that developers saw this as collateral for continuity and Google was able to switch from a cost to profit department. There is also a free section so in many cases, there is not much influence, but I think that the move to charging a fee is a good one. In particular, Google has a bad habit of immediately closing down its services, so making it paid has made it unable to end at a moment’s notice in the sense of SLA as well.
Similarly, if providing functions to developers as an indirect revenue type, there should be consideration as to whether to make it profitable or support it, or to just stop it entirely. Costs on servers are also cheap, so as a result of leaving it there peacefully, discoveries of security holes and the continued publicization of documents that are not maintained might lead to doubt in the main service.
DevRel is a marketing policy, so it should be initiated after properly deciding on a goal. Without a goal, it is possible that the management ranks will suddenly ask, “Remind me what are you doing this for?” It must be shown that it is an activity that presents proper cost advantages and has value in continuing.
At MOONGIFT, we provide support for all aspects of DevRel. Please feel free to contact us regarding the improvement of direct and indirect revenue types, creating systems for branding types, and so on!
You will receive news and updates about DevRel via email.