Product Documentation Strategy - Kay Miles

Product documentation strategy is the missing layer that turns fragmented, product-by-product documentation into a consistent, intelligent content system—so users can find answers reliably across devices and contexts. Kay Miles, an information architect at National Instruments, argues that many technical writing organizations fall into “band-aids above the surface”: writers patch individual complaints without fixing the underlying information and content infrastructure. The result is escalating inconsistency, writer burnout, and content that can’t keep up with modern expectations for seamless, Google-like answers.

Miles describes a documentation ecosystem at National Instruments where multiple teams produce technical documentation for modular software and hardware products, bundled into “systems.” While a shared umbrella—style guides, templates, process documentation, and a centralized wiki—helps keep outputs aligned visually, long-running differences in how teams build and publish content have created silos. Software writers focus on API reference and contextual information inside software; hardware writers prioritize printed documentation, specifications, and safety/compliance. Systems writers, tasked with supporting bundles that combine products, often inherit siloed processes that “don’t play nicely together,” pushing writers toward troubleshooting and technical work rather than writing.

To address this, Miles reframes “strategy” as a practical discipline already present in good writing: deciding who the users are, what they need, and when they need it. Documentation strategy makes those decisions explicit and shifts attention from a single product mindset to the entire content creation ecosystem. She breaks the work into three roles that function like a pipeline: information architecture (designing the structure of information spaces—navigation, content types, and where content belongs), content strategy (designing content assets and buckets to answer user needs across contexts), and content engineering (building the mechanisms—CMS, sourcing, publishing, and delivery—that make the design real).

The core problem, Miles says, is that user expectations have changed faster than internal infrastructure. In an Internet-of-Things world, users expect consistent answers whether they search from a watch, a laptop, or a store kiosk—without caring which internal team wrote what. They also expect search behavior shaped by Google: answers should appear early in results, and systems should anticipate questions. When content isn’t structured and connected enough, teams resort to ad hoc fixes that preserve chaos.

Miles offers a concrete example from her own experience: a legacy internal tool that converted CHM help files into static HTML for the web. Over time, the tool became an “orphaned” maintenance burden passed between teams, forcing writers to spend over 2,600 cumulative hours wrestling with finicky conversions. Meanwhile, more than 1 million static HTML pages existed, with roughly 800,000 receiving zero views—suggesting that even accurate content wasn’t findable. The organization made a difficult decision to stop relying on the tool, remove large volumes of dead pages, and redirect effort toward a new content ecosystem aimed at “content intelligence.”

The takeaway is not that intelligent content is easy, but that it’s necessary: investing in information architecture, content strategy, and content engineering creates a stable foundation where writers can thrive and content can adapt to new technologies without rewriting everything. Miles closes by recommending books on content modeling, information architecture, intelligent content, and information experience—positioning documentation strategy as a long-term infrastructure project rather than a set of templates.