Most documentation is written for the writer, not the reader. The writer dumps everything they know, in the order they know it, without asking what the reader needs to know and when. The result is a document that accurately represents the writer's mental model and is nearly useless to anyone else.
The test for good documentation
Apply this test to every document you write: could a new team member use this document to do the thing without asking anyone? If yes, it is good documentation. If no, it needs more work. The test is binary and brutal, which is exactly why it works. Most documentation fails it immediately because it assumes context the reader does not have.
What goes at the top of every document
Context first. Every document should open with four things: what this document is, why it exists, who it is for, and when it was last updated. Undated documents are untrustworthy because you cannot tell if they are current. A document without a clear audience gets written for no one and read by no one. Getting these four things right in the first paragraph doubles the chance that anyone reads past it.
The one-page format that works
For product requirements, the format that consistently gets read and used has these sections in this order: the problem with supporting data, the success metric with a number and a timeline, non-goals explicitly listed, the solution in two to three sentences, user stories in as-a-who-I-want-what-so-that format, out of scope explicitly listed, and open questions that need to be resolved before work starts. The explicit non-goals and out-of-scope sections are the parts most writers skip and most readers need most.
The documentation habit that actually sustains
Document as you go, not after. Documentation written after the fact is always worse — the decisions are harder to reconstruct, the reasoning is harder to remember, and the motivation to write it drops sharply once the work feels done. The practice of writing forces clarity about what you actually built and why. Teams that document as they go ship faster because the writing surfaces ambiguity before it becomes a bug.