Gaps in your Developer journey; Can you fix it?

🌱 - A collection of sprouting thoughts.

I find myself amongst the DevRel practitioners looking for a new opportunity; in that, I ask myself what is DevRel to me (again). Naturally, I look at the last article I wrote trying to rationalise just that.

The more I grow in my career the more I realise that outside of the AAARRRP-esque goals of DevRel, the more I want to fill gaps.

For clarity, AAARRRP is a framework for defining a Developer Relations strategy where each acronym identifies a potential business goal for a Developer Relations team. Most DevRel activity I believe can fall into these acronyms.

There’s no understating how Developer Relations professionals are over-represented in layoffs during our industry's “market correction”—a necessary struggle in the professions' character development. An unfair but necessary crunch. DevRel has always been teased, like a misunderstood adolescent growing into its own. Its existence is a testimony of its value, like every growing human, it must adapt and grow into something everyone wants to understand and value. That will take time.

Awareness, Adoption, and Revenue Generation are still as important as previously alluded to. The latter is more so now given the current context. Since that article, going from solo DevRel to growing and leading a team has seen me push for education as my method of choice with developer experience being the overarching theme. I shared some ideas in my article titled a take on Developer Experience.

Nothing is as offputting as great messaging and placement with at minimum, miniscule friction that deviates a user from their desired developer journey.

Gaps exist in each DevRel pillar, for simplicity, I’ll go with Hassan and collaborators’ definition on whatisdevrel.com; Community, Content and Product.

My take on developer experience is it's mostly gap-filling. We need to ask ourselves what gaps we are filling and which ones matter. I’ll take a philosophical approach and ask what a gap is and where it comes from.

Gaps are a space or interval; a break in continuity.

Friction comes from users falling into gaps.

We talk a lot about developer paths and developer journeys - the goal for most profit-seeking companies is to get someone to find out about them, use them and then convert to a paying customer.

DevRel exists in many universes, in our basic example DevRel chaperones people from where they are and puts them on a path to discovering your product, helps them as they use your product and sets them up for success as they use your product, eventually handing off for some sort of conversion that plays with whatever a company go-to-market strategy is.

We can go deeper, for many other companies, DevRel goes beyond awareness and adoption as we described to retention. Can we get people to stay users and help them use other parts of the product? Important questions to answer if they matter to you.

Here are some gap-filling questions to get you started. Ask…

1. Is our onboarding up to scratch? Is it frictionless and is the barrier low enough for our core target demographic?
2. Are we where the people we need to know about us are? How do you get there?
3. Is our content strategy serving our community's needs?
4. Are our docs a great reference resources?
5. Are we communicating releases well and are these releases well supported?

Gaps have a nice way of showing themselves in your data. Take a look at product usage funnels, and website user maps for example.

Hopefully, the idea of gap-filling is resonating with you. To quote Jordan from Sailspoint in this article - “If you're discerning your developer relations team's direction, benchmark your product against this hierarchy to pinpoint areas of enhancement. Start where the gap is the widest.”

I recall a couple of gaps uncovered across a couple of pillars at my previous job. We needed to increase plugins built for a marketplace. Naturally, we thought, a hackathon could solve the problem. However, the hackathon resulted in lacklustre software primarily based on the only tutorial we had. Internally, we were aware of the power the marketplace could bring thus the investment.

I know, I did my best not to have a hackathon run without enough content and support to help hackers out. This was the first gap.

A few user interviews later, we learned not only did we not have sufficient resources out there, but there wasn’t enough documentation on the API that enabled the plugin to be built as to the standard we set.

We went ahead and put together a suite of resources, videos and blog posts (content), made some changes to the API (product) from feedback and created a space for plugin developers to interact (community).

The same was true for Custom Fields, these gap-filling exercises were really useful in taking the product forward and smothering the developers desired path as evident in this PR for docs after a mini audit.

TL;DR, at a minimum, your DevRel team should function along one or more of the pillars mentioned above. Good DevRel teams will take that a step forward and audit developer journeys for gaps that create friction in their ecosystem.

I was inspired by DevEx audits and some experiments from my time at Strapi and wanted to take the time to put down some of my thoughts in a more structured way.

If you have other examples for gap-filling along different pillars, share them. I’d love to hear from you all.

Might go on a limb and say the smoother your experience the better your growth motion holds, whether Sales-led, Community-led, or Product-led. Good products don’t sell themselves but bad products don't sell at all.

Can you fix it? After this post, hopefully, you can too.

I can't end this without extending an enormous thank you to Rizel and Johannes for the review. They're awesome, check them out!