The art and practice of documentation triage - Neal Kaplan - Write the Docs Portland 2018

Documentation triage is the discipline of deciding—fast, ruthlessly, and with evidence—what documentation is truly critical right now, then shipping a minimum viable set that can improve through feedback. For new documentation owners, the biggest risk isn’t a lack of writing skill; it’s getting paralyzed by a wide-open field, too many options, and the temptation to chase “perfect” instead of “done.” The practical takeaway is to treat documentation as a craft with a repeatable process: identify high-value needs, prioritize ruthlessly, plan “good enough,” publish quickly, and iterate.

The starting point is clarifying who the documentation is for and what those people need to succeed. That audience work isn’t guesswork. It comes from building relationships across the company—customer support and customer success for real questions customers ask, product management for the business case and why the product exists, marketing for personas and positioning, and sales or professional services for what prospects ask during presentations. Once those conversations happen, the next step is a content hunt: gather everything that might help (not just formal docs, but internal wikis, email threads, and tribal knowledge), then run a content audit that labels each item as redundant, outdated, or trivial. Each piece gets a rough “level of effort” estimate and notes about where it came from, so the team can revisit decisions later.

With audience needs and existing content mapped, triage becomes a gap analysis. The method is to plot “business value” against “level of effort” and focus on the sweet spot: high value, achievable work. Some tasks—like reset password instructions—may be easy but low value; others—like deep onboarding into a complex domain—can be extremely valuable yet too costly to tackle immediately. The goal isn’t to do everything; it’s to push the most important work into reach by recruiting help, such as operations teams for install checklists or professional services for edge-case setup knowledge. When something can’t be done, it should be dropped with a clear conscience and left for later.

Planning is required, but it should be “good enough,” not perfect. The process explicitly rejects the myth that triage means writing immediately and never planning. Instead, it uses lightweight scheduling and estimates (even if they’re wrong) to prevent overwhelm and burnout. Documentation owners also need to treat feedback as part of the system: readers become QA only if there’s a clear feedback path, and collaborators must be welcomed rather than shut down. Accepting criticism with sincere appreciation keeps the feedback loop alive.

Finally, documentation triage is an ongoing cycle. Research and writing should be investigative—information rarely lands in a writer’s lap—so assumptions must be challenged and drafts validated against reality. After publishing, the work shifts to promotion: coworkers must actively use and share the docs with prospects, customers, and internal teams, because nobody refreshes a docs site waiting for updates. The overall message is that documentation grows when priorities are defended, feedback is evaluated and reprioritized, and the team learns what it can safely let go—backlog items, “ice box” ideas, and everything that won’t fit into limited time.