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 reaching out and supporting developers were that easy, more companies would be successful at it. Let’s find out where to start to get you 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 education for its users and an intentional community space. In essence, it needs a Developer Program. If you are just starting out, you may not have the resources to have a fully baked developer program on Day 1, but you must have a plan to put the pieces of the DevRel Framework (see image below) 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 start with some functioning version of your product. The exact level of functionality may vary, especially for newer companies that may blur the line between beta versions, MVPs, and developer previews. If you haven’t already, test out the product yourself as “Developer 0” or have someone do it for you and document any friction encountered.
You should flag specific issues that affect the developer experience to your product team as well as support teams so they are prepared.
Also, be prepared to let your users know the product's status and any known issues, you don’t want to lose potential users before they even start.
Step 2: Docs & The Developer Journey
Once your developer product is in reasonable shape, there’s still one more step before you open the curtains. Having basic documentation (or Docs) in place is crucial. Things 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 get started quickly, with a limited amount of friction. You don’t want developers to get excited about your product and have no idea how to build with your product, or be unaware of any dependencies and get stuck along the way.
You also don’t want potential users to get lost. Create great 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. Journey mapping and friction logging will be something you’ll want to do regularly as your program grows using a framework like our Developer Journey Map.
Step 3: Support & Team
We’re not quite ready for launch yet. 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 Discourse page). At a minimum, have an easy-to-locate email or a Twitter handle that someone actually answers.
By this point, 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 who can answer support questions and start the outreach. We recommend hiring an Advocate with experience that can grow into a senior role or provide them with some coaching support. As Developer Relations is still an emerging field, finding someone with the exact experience and expertise you are looking for 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 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 or enhancements unless you reach out. If you are working with a marketing team, be sure they are familiar with a developer audience. Based on your product and personas, there are many ways to create awareness about your product, including SEO, speaking at events, blogs, and many other forms of content. However, because your developer could be based anywhere in the world, it’s important to offer equitable access to developer advocacy and support. So consider a developer video or recorded livestream rather than an onsite workshop that only a few can attend.
Do also consider various developer communities where your personas might be hanging out – for instance, a Subreddit, Slack channel, or Discord server. Such destinations are often great places to find your first users and the start of your own community.
Measure and Analyze
I’d be remiss if I 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 and data to build into reporting. It might be 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 reasonable 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.
Special thanks to Chris Traganos for contributing to this article.
This article was first published on Heavybit.