Good developer experience is a GTM hack

Running this line of code sends a text message to any number you want. Two things made this form factor compelling to so many software developers in the early 2010s:

1. End-to-end utility: you completely solve a specific user need in a few lines of code, i.e., send an SMS to any number
2. Rewarding developer experience: you get a sense of satisfaction from easily solving what should have been a complex technical problem

One side effect of Twilio’s focus on developer experience (DX) was that the product’s value prop was immediately apparent to developers. Anyone could look at a code snippet, try it out, and instantly convert to a paid user. As a user, you went through this loop at the earliest stages of the conversion funnel with no go-to-market (GTM) personnel. For Twilio, this translated into low customer acquisition costs (CAC). Good developer experience turned out to be an excellent go-to-market hack.

As the developer tools (devtools) market has matured, reaching and converting developers has become more challenging. Multiple tools compete fiercely for developers’ attention. Consequently, developer experience is as essential as ever. It’s not enough to solve a technical problem for developers. You must also do so in a way that captures their attention over the competition.

I’ve begun to think of good devtools like good consumer apps. They don’t just provide utility but grab your attention early in the user journey. Tactically, this often looks like hiding complexity and making it dead simple to try a new product.

Hidden complexity

A simple, unassuming code snippet is often the building block of good DX.

Back to the Twilio example above. 

This code snippet is modeled after the basics of sending a message on your phone: to, from, body. It’s simple and familiar. The client SDK lets you choose when to opt into deeper layers of complexity, but all that complexity is hidden behind sensible defaults.

It’s refreshing when a devtool’s landing page puts a simple code snippet front and center. It's even better if there’s a simple cURL request to copy and run. Just like you don’t need to know the internal workings of a car when you go for a test drive, you don’t need to know the internal configurations of an API when you try it out. Hiding complexity is a tried and true way to highlight a hero use case and boost conversion.

Time to hello world

Another detail that resonates with me when I try new devtools is how little setup there is before I can get to the aha moment.

Consumer tools are good at this. Think about how quickly you go from making an Instagram account to getting lost in a feed of videos designed to harvest your attention for ad revenue. The fewer setup options there are, the more quickly users get to experience your product's value. In consumer psychology, this is known as Hick's Law. The developer experience equivalent is "time to hello world." 

I particularly like this onboarding example from Hookdeck, an events gateway infrastructure tool I use to manage webhooks. There is a single-page setup with only two required variables. If you've set up Kafka clusters to manage events before, you’ll appreciate how magical this feels.

A lot goes into building good devtools: functionality, reliability, speed, etc. However, a lot more is needed to capture a user’s attention. You can’t afford only to build a product that works well. You must make it work, make it right, make it fast — and, I'll add — make the experience enjoyable.

While good developer experience leaves an aesthetic impression on users, its impact extends to unit economics as it increases the likelihood that top-of-funnel interactions convert. For devtools startups with limited resources, this might be the difference between a project and a sustainable business.