Make Something Developers Want
Five steps for building products developers love.
Y Combinator is famous for their advice: make something people want.
It's simple and direct—relentlessly focus on your customer.
However, when those customers are developers, I'd argue the execution of this advice looks different and might be counter-intuitive from what people generally want.
Here's what you should do to make something developers want:
You should embrace open-source
You should have a free tier
You should have excellent documentation
You should be able to get support from developers
You should be part of a community
1. You should embrace open-source
Experienced developers love open-source products because they've seen the opposite. They've struggled to debug a “black box” closed-source tool, or worse, had a previously open tool change licenses or close its source code.
New developers love open-source products because they're learning skills that help them advance in their career—their knowledge transfers from company to company.
Open-source developer tools often have better documentation and educational material, too.
2. You should have a free tier
Developers don't want to talk to your sales team. They want to try out the product with as little friction as possible. Start free, then grow, once they've validated the product works and will solve their needs.
There are exceptions to this rule. You might have procured software that required months of negotiations, license keys to get access, and hand guided provisioning of resources from a human. But ask your developer—they would have preferred if they could have started self-serve.
“Try it before you buy it” isn't novel sales advice, but developers are outliers in this demographic.
3. You should have excellent documentation
The better the documentation, the more likely the developer is to try your product.
This isn't about specific UI features like dark mode or ⌘+K search dialogs. How quickly can they find an answer to their problem? Great documentation is either a reference guide or an educational tool.
Educational material should be equally compelling for both beginners and experts. Experts love to hear concepts explained in a simple way. Beginners want new concepts progressively explained. Don't drop ten new concepts and five acronyms right away. Write like you're teaching beginners.
Here's more thoughts on what makes a great developer experience.
4. You should be able to get support from developers
When developers can't find the answer in your documentation, they'll reach out to support.
They want to talk to someone who empathizes and understands their problems. It's easy to tell whether the support person actually “gets it”. Minimize the number of hops between problem and solution, ideally cutting out layers of humans in the middle.
This is why roles like Developer Advocates or Customer Success Engineers exist. Developers expect to talk to developers.
5. You should be part of a community
Where do developers go to hang out? Online and in-person communities.
This doesn't mean you need to start a community for your product. In fact, you probably shouldn't. Instead, look at where the developers are already spending time. Go there. Talk to them and contribute to the discourse.
Communities are not a transactional relationship. You are there to provide value. This is a long game, sometimes taking years to materialize value back, but then obvious in hindsight.
Do they really say community is non-transactional, and then go on to say “ sometimes taking years to materialize value back”. That is so hypocritical. It’s like saying transactional implies short term. Long term transactional is fine.