Documentation Strategy

Documentation Strategy

Decide what gets documented, where, by whom, and how it stays fresh. Stack-agnostic. Applies to internal team docs, product docs, runbooks, READMEs, and knowledge bases.

When to use

• Setting up documentation for a new team or product
• Auditing existing documentation
• Fixing stale or scattered docs
• Choosing a documentation tool or platform
• Defining what gets documented and what doesn't
• Establishing maintenance cadence
• Scoping technical writing work
• Designing onboarding documentation (use alongside team-onboarding-playbook)

When NOT to use

• Writing the actual content of a single document (use content-and-copy)
• Customer-facing knowledge base copy (use content-strategy)
• Code comments and inline documentation (covered by code-review-web)
• One-off blog posts or articles (use content-and-copy)

Required inputs

• The audience (internal, external, customer, dev, exec)
• Existing docs and their state (where, what shape, last updated)
• Team size and growth trajectory
• The kinds of work that produce documentation (engineering, product, ops, support)
• Tools currently in use

The framework: 4 categories of documentation

Different categories of doc serve different purposes. Conflating them is how docs get bad.