Tactics for Building Developer Awareness: Part Two

II. What tactics can we use to influence awareness with developers when launching a new product or service change to an existing product or service?

This is tactically quite a bit simpler because, in theory, you're not trying to convince developers to try something new. Instead, this can be an exercise in "winning the hearts and minds" of developers who already are committed to your product.

If they are current users of your product, they have already opted in to be contacted by you, which means that a targeted campaign of educational resources and consistent communication should suffice.

What about data privacy?

Firstly, I am not a lawyer.

Okay, now that we got that out of the way...

I worked with our development, legal, compliance, and marketing teams at SAP to implement GDPR compliance measures at SAP for our community of about 3 million members, so I have a good deal of experience with this.

But again, I am not a lawyer, so take this as practical commentary and not legal guidance.

Under GDPR, you do not need additional consent to send operational emails to individuals that you have a current business relationship with. This means that people who are using your service or product have, by virtue of signing up and agreeing to the Terms of Use, given consent for you to contact them about that product or service. This does not give you carte blanche to email them promotional garbage, but it is a general umbrella under which most product-focused communications to your existing user base are covered.

Consult your legal team if you have any questions on this one.

Back to Tactics...

Remember those questions we asked in Part One of Awareness? Here's a refresher:

1. Who does this change impact?
2. What is the change?
3. When is this change occurring?
4. Where is the change reflected?
5. Why is the change required?

These are the questions that we need to answer for our developers. So, let's tackle those in a sample Awareness campaign.

Based on a true story
In this simplified scenario, the product team is rolling out an update to the navigation menu, which will change where many of the commonly used features reside in interface. They have documented the changes, including a mapping from the old menu locations to the new ones, in their lengthy product documentation. However, we both know that your developers are not religiously reading the documentation or checking in for changes proactively, so it's on you as the developer advocate to influence adoption of these changes.

Note: In this example, the change only impacts the developers and not any end users who the developers will also need to support through the change. That scenario would be more complex and require you to build more enablement tools and resources, but let's stick to a simpler example for now.

Step One: Information Gathering

In this first stage, you need to get your bearings. You'll need to do some investigating and gather information from a few different stakeholders.

1. The Product Team
   This team is responsible for the change. But, you are now responsible for carrying the torch forward, so it's best to know as much as you can about the terrain you're walking into. This is the team to ask about any potential landmines (things they know are going to piss off the developers). They are also the ones who should provide all the answers to the above W questions. Make sure you fully understand the answers to those questions before you set out to educate others, including who your escalation contact will be if things go horribly awry. Hopefully, this team is also able to provide you with a list of impacted users to contact. If not, see stakeholder group 2.

2. Product Marketing, Developer Marketing, Developer Community, Developer Experience, Customer Communications, Customer Support, Customer Success, Account Management
   Your stakeholder list may contain one or more of these departments, depending on the size and complexity of your organization. Connect with anyone who is responsible for communicating with your developers on a regular basis on behalf of the company. Hopefully, you are regularly in touch with these folks any way to ensure that you are communicating in a unified voice and a well-orchestrated cadence. This group will help you determine what channels, formats, and timing work best in the context of other planned communications to ensure the proper amount of attention is paid to your announcements. They can also, likely, provide you with a contact list if your product team does not have that information.

3. Influential Voices
   Whether it's your CTO or a particularly vocal village elder in your community, there is someone (or several someones) that generally leads the sentiment of the developer community. This person is respected and trusted for their authenticity, their experience and expertise, and their impartiality when it comes to good or bad news. Hopefully, as a developer advocate or community manager, the group of people who fall into this category also includes you. But, it doesn't hurt to bring in the big hitters when the going looks rough. If the information you've gathered tells you that this change is going to meet some resistance, get some powerful allies in your corner before you head out into the field.

Step Two: Make a Plan by Working Backwards

Now that you know the answers to the 5 Ws, you can start to map out what the next couple of months looks like -- because, yes, this is going to be at least two months for a major change. Start with the launch date - in this case, we'll use a single launch date, but in some cases, there are progressive or phased rollouts. Work backwards depending on how much time it's going to take for you to create various assets (videos, tutorials, blogs, etc.) and schedule a regular cadence of communications.

Studies show that humans generally need to receive a message approximately seven times before they retain it.

Use What You Know About Your Developers

Each developer community is slightly different. As their advocate, it's a crucial part of your role to know what works for them, what their preferences are, and how they like to engage with you and with the rest of the community. Things you will need to know:

• How do they prefer to learn
• What channels do they prefer to use for communication
• When are they most active and ready to engage with your community
• What makes their jobs easier or harder
• How complex is the ecosystem that they are working in
• How hard will it be for them to implement this change

The answers to these questions will help you to determine:

• How far in advance do you need to first communicate this change to them
• Which channels (i.e. email, Slack, social media, forums, support portal, developer hub, etc.) will reach the majority of your audience
• What supporting resources you'll need to create

Here's an example schedule:

This is a high-touch change management plan for high impact, major changes. Not every feature or change requires this level of engagement.

Next time, on ADKAR for DevRel...

How do you get developers to want to make a change? What if it's not up to them, or worse, it's an unpopular change? How do we get them to do it any way?