A developer is evaluating two competing libraries. Both do roughly the same thing. One has a clear README, a working quickstart, an API reference that covers every parameter, and a troubleshooting page that addresses the three most common errors. The other has a README that describes what the library does in conceptual terms but provides no examples, a link to “see the source for reference,” and a GitHub issue tracker full of unanswered questions.
The developer picks the first one. Not because it’s better code. They don’t know yet if it’s better code. They pick it because they can start.
Documentation is the part of the product that the user experiences before they experience the product. For developer tools, it’s often the entire first impression. A developer who hits friction in the documentation concludes that the product itself is probably also friction. Sometimes they’re wrong. But they’ve already moved on.
This is why treating documentation as an afterthought is a product strategy mistake, not just a communication failure. When you ship a product without documentation, you ship an incomplete product. The users who succeed with it do so despite the documentation, not because of it, and they’re the exception. The users who don’t succeed leave. They don’t file bug reports. They just go.
Stripe understood this early, and it shows. Their documentation at stripe.com/docs is as much a product as the API itself. The three-column layout, the inline code examples in the language you’re actually using, the interactive API explorer: these are product decisions about how a developer should experience Stripe for the first time. The documentation isn’t a manual for the product. It is the product, for the first hour you use it.
That’s not an accident and it’s not cheap. It takes deliberate effort to maintain documentation at that level. But it’s also not optional for a company whose users are developers. Developers talk. A product that’s well-documented gets recommended. A product that’s poorly documented gets complained about in the same spaces where the recommendations happen.
The reframe that matters here is simple: documentation belongs in the same sprint, the same pull request, the same review conversation as the code it describes. A feature that works but can’t be explained is a feature that most users won’t benefit from. A product that exists but can’t be understood is a product that competes with one hand behind its back.
Every product has users. Every user needs to understand the product. That’s not a documentation problem. That’s a product problem that documentation solves.