Product-first DevRel

I came into developer relations from a mix of product and engineering - rather than from the usual, engineering-only path. The role gets a lot of autonomy because you're often the only one that has all of: technical skills, social skills, writing ability, and user empathy. By nature, there are no shortage of takes on how to devrel. Some focus on marketing, community, hackathons - others on writing, forward-deployed engineering and interface design.

Regardless of what good devrel execution looks like for a particular product, I believe it should use product-first principles. Coming from a product team, my brain was trained on metrics, user interviews, understanding funnels, organizing ambiguity into something cohesive, being my user's best friend.

Engineers are incredible users

Great product teams master lean process with execution and become very good at measuring the outcomes of work. Most PMs would kill to have developers as users because engineers are great for feedback - they're obsessed with the products they use, will tinker with them for hours, and are often smart and opinionated.

Sponsoring hackathons is one way to take advantage of that. Although this can be very hit-or-miss and requires heavy investment. Engineers will end up using your product to quality for your sponsor stream, rather than because it organically makes sense.

Alternatively, you can host your own. But unless you have a team, that might teach you more about organization and operations than it will about how people are using your product and what you need to improve.

Although both can be great for brand awareness, I believe there are better ways to approach improving the experience. We can learn from the basics of product work: watching product usage in real-time to understand where the pain points are.

Run weekly dev sprints

Dev sprints are 2-3 hour hackathons, held weekly with the sole purpose of improving your developer experience. Run one, collect feedback, and improve over the next week. If done well, after 3-4 sprints, your users will have a much better time with the product.

Be picky about who participates. User interviews, unless scaled for stats are often unproductive for products that are meant to be used heavily and in a variety of ways. Its difficult to pick up on precise pain points from a conversation.

Your target is a good developer has expressed some interest in your product, but not enough to be well-versed.

How to find these people:

• Call for developers on socials and discord. Reach out to people interacting/following your twitter/github.
• Filter your user database for recent sign ups with, for example, 5 api calls in their first 2 days of signing up. You can use Exa to scrape info about these people and filter based on their info online (projects, work, github etc.)

How to incentivize:

• Offer to share their project on your social media, demos page and docs
• Cash, credits, gift cards etc.

1. Write automation for finding the above people, so that your system helps you find and reach out to 30 devs/week, ideally bringing in 2-3 people for your weekly sprint.
2. Host at the same time every week and in-person, so that you can watch every bit of what happens.
3. The execution of your dev sprint will depend on your product.
   • The better your dev experience, the less of an intro you need
   • Experiment with what info you give in your intro, and see how that reflects on clarity of the product.
   • Take as much advantage of this time as possible - for ex. share content of yours instead of a live intro, to get feedback on how clear your videos are.
4. Have people work alone and observe all of their steps. You will likely cringe and hope that they don't use a certain part of the product because you know its bad. This is normal.
5. Take notes the entire time and be as minimally invasive as possible.

Qualitative indicators of success:

• Speed to MVP is under 2 hours and should decrease over time
• Whether people can instantly think of use cases for your tool and ideas for what they can build
• How excited people are to build with your product
• For those that haven't used it before, is there a wow factor when they first use it
• Sentiment after spending 3 hours in your docs, api or product interface. Do they look happy and satisfied or exhausted?

Once the first set of sprints to improve the core developer experience is done, you can reduce the frequency and run sprints whenever new features are launched.

You can use this to test your content, docs, platform, api, dashboard, technical communication and it will give you incredible insight into where the issues are. As much as you understand your product and believe you know how to improve it, you graduate from being a "new user" a day or two into working on the product. You can no longer look at the product with naiveté and identify the painpoints of someone that isn't heavily involved.

As much as pm-ing is out-of-trend and startups are leaning towards being engineering-led, dozens of exceptional products show that product-first principles are a proven way to build an exceptional and magical experience for users. This is my way of finding balance between the two.