Social Media
Today’s topic is how to start DevRel. Some might think it’s a bit late to discuss this, but I believe there are still valuable insights to share, so please listen.
However, I’ve been giving similar talks for the past 2-3 years. While DevRel has been around for over 10 years, I still frequently receive questions like “What should we start with?”
I think this question arises because we often see successful examples of services that are doing DevRel well. For instance, foreign companies like Apple, Google, and AWS, or community initiatives by SORACOM and kintone that seem very shiny. While these companies have built strong relationships over a long time, looking at these success stories alone can make it confusing to know where to start.
I’d like to share my usual answer to the question of “What should we start with?”
So, what’s the answer? Write a blog? Prepare documentation? Create an SDK? Build a community? No, these are all incorrect. These are just tactics and measures. The first step is planning.
Just like in service development projects, we start with planning. A project plan typically includes:
Why is this necessary? Because the DevRel needs vary for each service and product.
For example, the required functions differ between early-stage products and those with some recognition and existing users. Creating a community in the early stage is reckless because there are no users. Even if you create a spark, no one will help grow the fire. In the early stage, I think the focus should be on gaining awareness.
The project plan is also used to gain internal consensus. Please confirm within your company that “we need marketing for developers.” I’ve seen countless cases where DevRel was started without this confirmation, didn’t yield good results, and was discontinued. This happens due to misalignment in schedule, costs, and objectives.
Let me digress a bit, but the difference between Developer Relations and Developer Marketing often appears here. Marketing mainly aims for awareness and list building. In contrast, relations are about building mutual trust. There’s a significant time lag here. For example, who would trust me if I suddenly said “trust me”? Trust relationships can’t be built without understanding someone’s character and having repeated conversations. However, from a marketing perspective, there’s a tendency to seek quick results, so they might start harvesting as soon as they get some event participants on connpass. The result is often a wasteland with no trust and nothing gained.
Therefore, internal consensus is crucial. We need to help others understand why building relationships is important and why it takes time.
Now, let’s assume we have internal consensus. Then we can start thinking about “what measures should we take.” This is where we get to the main topic, but what I always recommend is “foundation building.”
Foundation building mainly consists of three things:
I’ll explain each of these in detail, but first, let me explain why “foundation building” is necessary. These are essentially first impressions.
In psychology, there’s a term called “Mehrabian’s Rule” related to first impressions. It states that 55% of first impressions are influenced by visual information. For developers visiting your website, this visual information is everything. While salespeople can follow up in face-to-face situations, it’s difficult to follow up with people browsing your website. In other words, developers must understand based on their impression of the website. If the first impression is bad, no matter how well-crafted your admin panel is, it’s useless.
Here’s an example: there’s a technology called Cordova. This technology allows you to create smartphone apps using web technologies, and it was called PhoneGap when it first appeared. It was a wonderful technology that allowed you to create iOS/Android apps using HTML and JavaScript, and many developers, especially frontend developers, had high hopes.
However, around 2009 when it appeared, smartphones and JavaScript engines were slow. This led to the impression that Cordova was slow and heavy, disappointing many developers. While it has improved significantly since then and many apps, both business and otherwise, are being developed with it, many developers still hold the impression that it’s “heavy.” When the first impression is bad, you lose the means to deliver correct information to them later. Because they’ve left disappointed. This shows how important first impressions are, and that’s why foundation building is necessary.
Consider these points:
Don’t you have cosmic visuals on your top page? Or maybe you’re using nice illustrations from unDraw? It’s a waste of the first view, so it’s better to stop.
On the other hand, are you writing everything in text? When writing text, writers often mistakenly assume that “readers will read everything carefully and understand perfectly.” No one wants to read text, so they skip through it. As a result, they hardly understand anything. If you want them to understand, you need an information structure that facilitates understanding.
Regarding prerequisite knowledge, there are often pages that overuse technical terms. People will drop off as soon as they encounter one term they don’t understand, so it’s better to avoid this. Of course, this is okay for highly specialized services targeting only people with sufficient knowledge. This depends on who your persona is, so be careful. However, service providers generally have sufficient knowledge in their field. They usually have more knowledge than website visitors, so it’s better not to assume that users have the same knowledge as you.
Next is documentation. Documentation is very important. Even if you write nice things on the top page, poor documentation quickly reveals it as a subpar service. If the documentation is bad, people will think the service quality isn’t great either.
There are several types of documentation:
While it’s difficult to create all of these from the start, you should at least have API documentation, SDK documentation, tutorials, and service usage guides.
Recently, cognitive characteristics have become a topic of discussion. This refers to how different people have different ways of understanding things best.
People have different preferences for which input resource they understand best. Therefore, instead of just providing text, it’s recommended to combine various methods like using images or videos.
And the third point. “Smooth” is qualitative, so we need to explain what it means specifically:
Services with many input fields are annoying, right? Didn’t we all learn as children not to do to others what we don’t like done to us? I really don’t understand why people do this to others.
Too many input fields, or strict formats for phone numbers and postal codes. Too many surveys. This is where Developer Marketing might raise its head. From a marketing perspective, they might want to collect as much information as possible at this stage. Also, from a manager’s perspective, they might say incomprehensible things like “we don’t want users who can’t handle this much input.”
Regarding user registration, the best approach is social login only. GitHub and Google are sufficient. While you could add X, Apple, Facebook, LinkedIn… and other buttons, that would just create confusion, so one or two options are enough.
And the pattern of making users wait several days after registration. This is the worst. It dampens the enthusiasm of developers who want to try your service now. When they receive an email days later saying they can now use the service, they’ve either already tried a competitor’s service or become too busy to try it later. As part of foundation building, the service should be ready to try immediately after registration.
Foundation building means preparing to receive visitors. Once you’ve created a state where you won’t disappoint developers who visit your website or show interest in your product, and can meet their expectations, then you can start expanding awareness and bringing them in. This is where marketing excels, and you can implement various measures like content marketing, conference sponsorship, and event speaking.
Not doing this foundation building is like a sieve with holes. No matter how much inflow you pour into the sieve, like water, nothing will stay. It just flows from top to bottom. That would be fine, but what’s flowing through the sieve isn’t water - it’s developers. Developers who might have used your service are visiting your site, becoming disappointed, and leaving. And as I said earlier, once users are disappointed, they won’t come back. This means you’re losing valuable opportunities every day.
I’ve written a blog article about product lifecycle and DevRel strategy, so please read that for more details.
Therefore, I want to change the perception that DevRel’s first step = awareness expansion. While marketing has the AARRR model and DevRel has the AAARRRP model, where the first A is Awareness, and while it’s important to gain awareness and expand reach, I want you to hold back and first review whether your service is ready to receive developers.
Of course, you can’t just keep doing foundation building forever. Once you reach a certain state, you need to continue providing the service while making improvements. You can’t make it perfect from the start, and it won’t be perfect even after years. This balance varies by company and service, so proceed while gaining consensus within your team.
Finally, let me introduce something. As a general incorporated association, DevRel has created a DevRel Roadmap for organizations and individuals who want to learn DevRel, like the content we discussed today. While it’s still far from complete, we’re building it to help with your DevRel activities, including the content we discussed today. Please take a look and use it as a reference. Of course, as this is a community activity, we welcome feedback about what content you’d like to see or what might be missing.
MOONGIFT supports your DevRel & developer marketing in the Japanese market. If you’re interested, please contact us.
You will receive news and updates about DevRel via email.