What docs can do
Get a first result out of the product today
Import, check and widen a real source
Roles, invitations and access reviews
Send the output where your team already works
Who can see what, and where data lives
The order that finds a cause fastest
Day-to-day use#
The best feature pages describe a cycle rather than a list: what triggers the work, what the product does with it, and what the person is left holding at the end. Readers recognise their own week in that shape, and they recognise nothing in a bulleted inventory of nouns.
Fill this in: name the two or three things people do in docs every week, in their words. If nobody on the team can name them without opening the app, that is the page to write first.
Working as a team#
Documentation for multi-person products lives or dies on one question: who can see and change what. Answer it explicitly — the roles on offer, what each one may do, and which actions cannot be undone.
Fill this in: the real role names and a one-line summary of each. If docs is single-player today, say so here; that is useful information, not a gap.
Where the edges are#
Writing your limits down is the cheapest way to stop a bad-fit customer signing up and churning a month later. State the sizes and rates the product is built for, what happens above them, which platforms and formats are unsupported, and the work docs deliberately leaves to other tools.
The limits you already quote on sales calls belong on a public page, not only in an inbox.