documentation as intention
You can tell a lot about what a team thinks it's building by reading their documentation. Not the marketing copy — the API reference, the error messages, the guides for edge cases nobody asks about in the first month but everybody hits in the third.
The teams that write documentation like it's a product are signaling something about how they think about their users. They've imagined someone arriving with a specific problem and traced the path from arrival to resolution. The documentation is evidence of that imagination having been exercised.
The teams that write documentation like it's an obligation are signaling the opposite. The API reference is complete but bloodless. The guides cover the happy path. The error messages say 'something went wrong.' What they're telling you is that they've thought carefully about the system and not at all about the person using it.
Column's documentation is in the first category. Stripe's documentation is the canonical example of this done right — it shaped expectations for what developer documentation could be. The interesting question is whether that quality of documentation is a cause or an effect of product quality. My read is that it's both: the act of writing good documentation forces the team to encounter their own product as an outsider, which surfaces design problems that internal familiarity hides.
A docs site that's been neglected is a signal worth heeding. Not because documentation is important for its own sake, but because the teams that neglect it have usually decided, implicitly, that their users can figure it out. That decision tells you something about how they think about friction.