The short version#
| What you want to do | Start here |
|---|---|
| Get a first result out of the product | Getting started |
| Give colleagues access to the same workspace | Invite your team |
| Check a limit, a policy or a price | FAQ |
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#
Every product has boundaries. Writing yours down is the cheapest way to stop a bad-fit customer from signing up and churning a month later, and the fastest way to earn trust from a good-fit one.
Worth stating plainly:
- The sizes and rates the product is built for, and what happens above them.
- Platforms, formats or versions that are not supported.
- Work that docs deliberately leaves to other tools.
Fill this in: the limits you already quote on sales calls. They belong on a public page, not only in an inbox.
Next steps#
- Getting started — set it up before reading further.
- Invite your team — the rollout guide.
- FAQ — short answers, including the ones about limits.