The one test that tells you if you actually need DevRel

This post is part of a series on building developer relations, adapted from a book chapter I wrote. You can find all the posts once published in the series here.

People love to argue about the definition of developer relations, and the arguments are fun. Some say it's just what software companies call their marketing department. Others insist it's a critical part of engineering and tech support. A third camp says it's about turning a technology platform into a viable platform business. And someone in the back always says it's really just about selling technology to engineers.

They're all partly right, which is exactly why the debate never ends. So let me offer a shortcut - one question that cuts through most of it:

Can developers extend your product, or can they only use it?

That's the test. If developers can only consume what you built, you might need good docs, good support, maybe some developer marketing. But you don't need developer relations in the deep sense. The moment developers can build on top of your product - extend it, plug into it, create something you didn't imagine - everything changes.

Because at that moment, developers stop being customers. They become participants. Often they become partners critical to your success. They're co-creating with you, and you can't co-create with someone you're only marketing to.

The technical term for what you've built is a two-sided market: two distinct groups of users who provide each other with value, and who together reach a scale that a plain product never could.

Android is my favorite example. On its own it's a technology product. But it's used and enhanced by developers who extend it with engineering products of their own. To the everyday user, Android almost merges with those enhancements - it becomes infinitely more valuable because it's suddenly customizable to even the most exotic requirements. Google gets to co-innovate with a force far larger than its own engineering org. Developers get a scaling market opportunity and technologies that work better together. Everybody's slice of the cake gets bigger.

This is the thing marketing-first thinking tends to miss. In a two-sided market, developers are occasionally in the customer seat, being marketed to. But most of the scale doesn't come from marketing or selling technology to them. It comes from giving them the right incentives and the right enabling technologies, and then depending on them - for feedback, for building, for cooperation. Developers are a creative force that make or break technology products. Understanding what that force needs, and where it is heading, is strategic work.

The companies that win here are the ones that manage to strike a balance between listening and broadcasting. They co-create instead of just announce. And they benefit from the collective knowledge of an engineering community much greater than the one on their payroll.

So before you hire a single advocate or plan a single event, run the test. If developers can actually extend what you've built, you have a two-sided market - and you need to think about it as a relationship, not a funnel. If they can't, be honest with yourself about what you need, and save the DevRel budget for when the answer changes.