Terms like “culture” and “empathy” have a lot of meat when brought up in conversation. They provide direction, strategy, and the benefits of successful implementation are clear. But the tactics of implementing things like developer empathy are not always clear. (And at the end of the day, talk is worthless.) But there is a way to implement developer empathy into your developer portal without planning for it every step of the way.
The outcome of a vendor practicing good developer empathy is that the users of their API or application have the confidence and enthusiasm to use it. But while many organizations talk about the need for developer empathy, few are making it a standard part of their developer marketing or developer relations activities. Often, developer empathy is implemented in a waterfall approach after the fact (such as a one-time overhaul of documentation and the developer portal). The problem with this approach is that the cost is extremely high, and the outcome is out-of-date once it’s been completed. The result of being this ineffective is:
- Lack of continuity: Some parts of your dev portal and content hit the mark, and other parts are off-putting. That lack of continuity does not ensure confidence. And it often leaves developers with the notion that the team who implements the portal is scattered.
- You build empathy for yourself: Project-based modifications of your developer portal mean that planning and strategy are implemented in a waterfall fashion. The only way to do that is to base your content and strategy on a lot of assumptions you have made. They are educated guesses, but they are just guesses. And the net result is something that will appeal to you, but maybe not to the rest of your user base.
Ideally, developer empathy is implemented during the standard creation and maintenance of your developer portal. This keeps the cost down, and ensures the coverage of your developer empathy strategy is high. Your marketing and dev relations team can’t do this alone. They need the help of the very persona they are going after.
Getting Help from Your Users
The only way to ensure that developer empathy is baked into every aspect of your marketing and developer relations programs is to incorporate the users you are trying to support. Practitioner content marketing is the easiest path to do this.
By directly or indirectly bringing your users into the fold, you are able to maintain a touchpoint with the consumers of your developer portal—and they are the only ones who can make it very clear if you are successful or not.
You can engage your users to bake in developer empathy in the following ways:
- The majority of content needs to be produced by practitioners: Instead of trying to create documentation, blog content, and how-tos by yourself and assuming the content follows the assumptions of your users, have the user based do it for you.
- Crowd-source validation: Engage practitioners in regular and ongoing reviews of the content you create. This includes having them do a sanity check prior to new feature announcements, etc.
- Focus on strategy, not execution: Your desire to build in developer empathy, and the knowledge of what sort of content and engagement is needed to support your users is probably spot on. Your team’s value is best used in optimizing this strategy, but not in producing the content itself. Being 100% strategy-focused allows you to get your unintended bias out of the picture, and have your target user base make sure the execution of your strategy is working.
From conversation to results
Going from what you know you need to do to actually doing it should be the most gratifying aspect of your job. Even if it’s not, for your users and your company’s ability to engage and maintain credibility with developers, it’s paramount—and it’s key to the success of any developer program.
It can seem overwhelming to embrace developer empathy. And it might seem like the only approach is periodic project-based updates to your portal’s structure and content. But a better way is to have your team focus on strategy, and bring in practitioners who will benefit the most from developer empathy to execute it.