Writing process overview

I don’t start with words.

I start with constraints: audience, use case, product reality, and what “done” means.

This is the end-to-end process I use to ship documentation.

The workflow (high level)

1. Intake and scope
2. Discovery and research
3. Outline
4. Draft
5. Review and revision
6. Publish
7. Maintenance

What I optimize for

• Time-to-first-success for the reader
• Fewer support questions caused by missing context
• Content that stays maintainable (so it doesn’t rot quietly)

Quality gates

I treat these as “stop points” where I either fix issues or explicitly accept tradeoffs.

• Before outlining: scope is clear enough to write
• Before drafting: outline answers the reader’s questions in the right order
• Before publishing: links work, examples are consistent, terminology is stable

Key artifacts

• Discovery brief (inputs, assumptions, risks)
• Outline (intentional structure)
• Draft
• Review notes + resolution log
• Maintenance notes (what will change, when, and why)

What changes as I learn

This manual is allowed to evolve.

I’ll update the process when:

• A step consistently causes rework
• Stakeholders get stuck in the same place
• Readers ask the same questions repeatedly