Take These Four Key Steps When Launching a Developer Relations Program

You’ve created a product you know developers will love. Heck – you’ve even done your segmentation, so you know which developer personas will find success with your product. Now it’s launch time. Time to watch the developers start rolling in to use your product. Right?

Well, not quite. If creating a thriving developer community was as simple as putting out a press release and making some marketing noise, then more companies would be successful at it.

Let’s look at the 4 most important steps to get your launch off on the right track.

Step 1: Functioning Product

Let’s review these two words separately.

First, product. Whether you have created a developer tool or have an API developers will use in creating their own product, you must consider that tool or API to be a full-fledged product.

And like any product, it requires resources of staff, budget, an outreach plan, go-to-market resources, support flow, and so on to be successful. Because it is a developer product, it will also need some form of technical educational content to explain how and why developers might use it, and an intentional community space.

In essence, it needs a Developer Program.

Even if you are just starting out and may not yet have all the resources necessary to provide a fully baked developer program, it is helpful to have a vision of what you need to build out over the long term, as opposed to tackling the individual component parts in a piece meal fashion. Have a plan that you can clearly articulate to your manager, stakeholders, and team members to put the pieces of the DevRel Framework in place over time as your product and user base grows,

The second word is functioning. As you reach out to prospective users, you’ll need to start with some functioning version of your product. The level of product completeness can vary dramatically, and often companies want to get new functionality into the hands of developers early to gather feedback and feature requests. Alpha, Beta, MVPs, and developer previews are common approaches. If you haven’t already, test out the product yourself as “Developer 0” or have someone that hasn’t been deeply involved in the product development do it for you and document any friction encountered. Using independent people helps remove bias and highlights reliance on inside knowledge that a prospective user will not have.

The issues that are uncovered should be shared with your product and support teams to either address immediately or document and add to the backlog.

Be transparent with the product's status and any known issues. You don’t want to lose potential users by them stumbling over issues you were already aware of. A culture of openness and ownership breeds good habits and builds trust in the community.

Step 2: Docs & The Developer Journey

Once your developer product is in reasonable shape, there’s still one more step before you pull back the curtains. Having basic documentation (or Docs) in place is crucial. Resources like a Getting Started page, Quick Start Guide, How to get to a ‘hello world’ code samples, and other learning resources will help your developer understand how and why they might use your product, and get started quickly with a limited amount of friction.

You can’t expect developers to immediately join the dots and understand why they should use your product, and what gap it fills. You also don’t want developers to get excited about your product but then have no idea how to build with your product or be unaware of any important dependencies. This will lead to frustration and friction.

You also don’t want potential users to get lost. Create clear onboarding flows for your developers’ journey to guide new users through an optimal experience with your product and Docs from the moment they land on your website.

Use your analytics and community feedback to monitor developers' success in navigating your onboarding experience. Conduct journey mapping and friction logging on a regular basis as your program grows, using a framework like our Developer Journey Map.

Step 3: Support & Team

One last prerequisite for launch. You’ll need a viable amount of support in place. Have someone whose job is to answer questions and a place online where a developer can ask questions (like a forum, Slack, or Discord). At a minimum, have an easy-to-locate email or a Twitter handle that someone actually answers.

You may have a dedicated support organization that can answer questions, or commonly the DevRel team/person help with support whilst they execute the developer outreach, but note this does not scale over time as your community grows.

If you haven’t already, you’ll want to have an experienced DevRel practitioner on the team. A senior DevRel person can take leadership for the Developer Program and strategy and start to hire a team. Or, if your budget doesn’t allow for that yet, the first hire is often a Developer Advocate. We recommend hiring an Advocate with experience that can grow into a senior role. Provide them with training and coaching support to get them there.

As Developer Relations is still an emerging field, finding someone with the exact level of experience and expertise you are looking for at the remuneration level you are prepared to pay can be difficult. Play to the strengths of your team. Also, look to identify community members that really care, and highlight their contributions as you build. The passionate users of today could become important design partners or employees in the future.

Step 4: Product Launch & Outreach

OK – time to launch!

Just because your product is built and you have your Docs and support in place, developers won’t try your new product unless you cut through the noise and reach them with your marketing, or they get a recommendation from a friend.

If you are working with a marketing team, be sure they are familiar with a developer audience. Tailor your messaging to appeal to your identified developer segments and personas.

There are many ways to create awareness about your product, including search advertising, SEO, speaking at events and content marketing. Remember your target developer could be based anywhere in the world, so it’s important to offer equitable access to developer advocacy and support. Consider the opening hours of support you offer, and be transparent on response times. If you are running developer events, always offer a recording for post-event access for those in other time zones or unable to attend live.

Research the various developer events, platforms, and communities where your personas spend time. These are often great places to find your first users. Become an authentic and valued member of those communities by making meaningful contributions and support to those communities, which is very different from a sales and marketing “lead generation” mindset. In other words, give rather than take.

Measure and Analyze

We would be remiss if we didn’t mention metrics.

Measure and analyze your progress through the launch of your Developer Program and product. Too many programs miss the opportunity for insights from their data. You might be using something like Orbit or CommonRoom for external engagement, Google Analytics, Segment or MixPanel to measure product usage or drop-off stages, or Peritus to act on and gain intelligence from developer questions. Most of these products have a free tier and are easy to implement.

Optimize what you can control. Build relationships across your company. Take guidance from your developers. Then celebrate your success and those of your community.

Need some help with your developer product launch? We’d love to help.

Special thanks to Chris Traganos for contributing to this article.

This article was first published on Heavybit and modified.