Developer Products

Great developer products respect developers’ time, curiosity, and autonomy. They’re easy to try, easy to understand, and worth betting a project on.

1. Open source

Experienced developers love open source because they’ve seen the opposite. They’ve struggled to debug “black box” tools or watched a product flip licenses and close its source.

Newer developers love open source because the skills transfer between jobs. They learn tools and patterns they can take with them, and open tools often have better docs and examples.

You don’t have to open everything. But where possible, open source:

• Builds trust and reduces vendor risk.
• Makes debugging and contribution possible.
• Turns your users into collaborators.

2. Free to start

Developers don’t want to talk to sales to see if something works. They want to try it with as little friction as possible.

A good default:

• Self-serve signup.
• A meaningful free tier.
• Clear, predictable upgrade paths.

There are exceptions: some software still requires contracts, license keys, and hands-on provisioning. But if you ask the developers, they would almost always prefer a self-serve path to get started.

3. Excellent docs

The better your documentation, the more likely a developer is to try—and stick with—your product.

This isn’t about dark mode or a fancy ⌘+K dialog. It’s about how quickly they can find an answer to their problem.

Great docs are:

• A clear reference when you know what you’re looking for.
• An educational guide when you don’t.

Write for beginners without talking down to experts:

• Explain concepts progressively instead of dropping ten new ideas and five acronyms at once.
• Use simple language; experts appreciate clarity too.

4. Developer support

When docs aren’t enough, developers reach out to support. They want to talk to someone who actually understands their problem.

They can tell quickly whether the person on the other side “gets it.” Minimize the hops between problem and solution; avoid layers of people relaying messages back to engineering.

This is why roles like Developer Advocates and Customer Success Engineers exist. Developers expect to talk to developers.

5. Real community

Developers spend time in communities—online and in person.

You don’t always need your own branded community. Often, you shouldn’t start one. Instead, go where your developers already are. Listen, help, and contribute to the conversation.

Communities are not transactional. You’re there to provide value first. It’s a long game; the compounding value often takes years to become obvious, and then it feels inevitable in hindsight.