Developer Relations is still a relatively young profession, trying to find its rightful place between marketing, support and engineering. I enjoy reflecting on this journey with others at events like DevRelCon and hope to organise a new DevRelAms soon. Earlier I wrote about comparing Developer Evangelism with its Religious counterpart and the Value of FOSS.

In this new post I’d like to explore how Developer Relations makes sense in what Pine and Gilmore called The Experience Economy, already back in 1998.

Products

A long, long time ago it was all about the product. “A great product sells itself”, they would say. Well, I hope we’re way past that myth. Sure, your product should do what you say it does and do it well. But with a new JavaScript framework pretty much every day surely some will be of excellent quality, without resulting in much adoption.

“I hope we’re way past the myth that a great product sells itself”

The status quo for developer marketing

And yet, while B2C and B2B marketing moved on, the so-called B2D (Business 2 Developer – another discussion) marketing did not. Check any random developer portal and it will still list features, benchmarks and boost with the use of trending languages and libraries.

Solutions

B2B marketing moved on to solutions; the idea that you should develop products around customers’ needs instead of trying to find or even create a need for your products. While this often seems to be primarily a matter of how they phrase their proposition and organise their licensing, this still seems to work well B2B.

In B2C marketing you actually saw the same shift. Simply replace solutions with benefits.

Experience

Primarily in B2C marketing it became clear that consumers wanted more than products with the right benefits, in particular for more trivial needs. This is where the Experience Economy comes in. A product might fit a need perfectly, if it doesn’t leave a meaningful impression users will easily switch to another.

Developer Relations is all about Developer Experience

And this… is where I think Developer Relations belongs.

We’re not in the business of selling products or solutions. Sure, we should known our products inside-out and focus our blog posts and samples on actual uses cases (How to..) rather than features. But in the end it’s our responsibility that developers love the experience of working with our products and interacting with other users. This is what we advocate for internally and work with Marketing and Engineering to achieve. This is what motivates us to fly out and dial in to our communities.

“It’s our responsibility that developers love the experience of working with our products and interacting with other users”

What makes a great Developer Experience?

Developers are King and it’s up to them what they work on and what tools they use. And again, there are plenty of tools to choose from. They select their own stack rather then buy into your all-in-one solution. They seek for:

• Excellent onboarding, allowing them to get from zero to hello world ASAP.
• Sure, a great product. Although unlikely to have no bugs at all, the workflow should be effective, efficient and fun.
• Excellent documentation, samples and guides, helping them to get form hello world to actual use cases with ease.
• Friendly support; great listeners, knowledgable, helpful and feeding back to Engineering.
• An active community of developers who clearly have a great time using the products.
• In the case of OSS; A sizeable, motivated group of contributors working closely with the product engineers/maintainers.

Combining Experience & Lock In

Apple is a great example of a company that combines the experience with a more evil marketing (retention) strategy: lock-in. They convince you that in order to have the best experience, you should go all-in on their ecosystem. And where lock in on itself will easily damage your reputation, actually delivering on the promise results in customers who wouldn’t even think about switching.

Harvesting

With or without lock in, this is where Developer Relations and Sales meet but should never mingle. DevRel should never ever have any sales targets or responsibility. If you design your product in the right way and allow Developer Relations do its job to deliver a great experience to users, sales should have no problem collecting money from them. This might come in the form of paying for capacity or even additional features, but it’s vital that the developer experience is great at every level.

“It’s vital that the developer experience is great at every level”

Eat your own dog food

When Microsoft was developer Windows NT, Paul Maritz introduced the idea of “Eating our own Dogfood”. I think this is crucial for a great developer experience. Engineers, support staff, sales engineers and of course developer advocates and evangelists should be allowed, motivated or even required to use your products for their own side-projects. Preferably using their own, personal accounts. Sure, reimburse them, but let them go through the billing process and the same experience as your users. Organise internal hackathons to test out new features, whatever it takes.

Let’s develop for better developer experiences!

Photo by Ryan