Social Media
When planning DevRel initiatives, it becomes easier to understand by considering the developer journey. The AIRDO method serves as a fundamental framework for this approach.
The AIRDO method breaks down the developer experience into distinct stages, from being unaware of your service to releasing and operating their own products.
Here’s a visual representation:
This phase represents the journey from complete unawareness to discovering your service. Potential discovery channels include:
This stage begins when developers become interested in your service and start researching. They also compare it with similar services. The following information is valuable at this stage:
During this phase, official documentation and case studies are essential. Case studies are particularly important for large Japanese enterprises, as they always check whether companies in their category are using the service.
Equally important are third-party evaluations. The presence of usage articles on platforms like Qiita or active information exchange in communities (both online and offline) can significantly influence adoption decisions.
This is the registration phase. Since developers have already completed their research, there shouldn’t be major barriers. However, the presence or absence of a trial period can affect the registration barrier.
Other factors like social login availability and SSO support can also impact the registration process. The key at this stage is to ensure a stress-free registration completion.
This phase involves integrating your service into the development workflow. Required information includes:
At this stage, it’s crucial to understand that using your service is not the end goal. Your service is merely a component, and it shouldn’t hinder developers’ objectives. Your service must not become a bottleneck in their development process.
Therefore, it should work with minimal errors. While runtime errors are unacceptable, the service should enable predictable development through intuitive error handling and expected behavior. Developers write code based on their experience, so avoid incorporating unique approaches or constraints.
Even if errors occur, a multi-layered self-support system is essential. This includes clear error messages in the SDK, understandable API errors, and comprehensive documentation. Without these, developers will turn to the community, and if they can’t find answers there, they’ll need to contact support. This could halt development for hours or even a day, resulting in a poor developer experience.
The final phase is operation. For APIs, once integrated during the development phase, they typically remain unchanged. As mentioned earlier, developers don’t use your service as an end goal, so they prefer to leave it untouched as long as it’s stable. Your service must maintain consistent, problem-free operation to support this.
SDKs must maintain backward compatibility while keeping up with related library version updates. Code must always be tested, and version updates should never introduce errors.
Therefore, SDK design is crucial. It requires flexible design that considers future expansion. APIs must maintain stable delivery even when versions change.
We’ve introduced the AIRDO method in this article. By considering the developer experience, you can better understand which initiatives will resonate with developers at each stage.
Additionally, by measuring where developers drop off, you can identify which initiatives need strengthening. This framework is also useful for differentiation from competitors. We encourage you to utilize this method.
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.