People who have not worked inside a regulated business sometimes hear "documentation" and picture bureaucracy. I picture the opposite. Every document I write exists because, at some point, a decision needed to be made by people who were not in the room, or defended to people who arrived later, or tested by an engineer who needed to know exactly what "correct" meant. The paper is how a product survives contact with the organisation.
It starts with a data analysis report, and my preferred structure uses the same three families of metric, in three kinds of number. Input metrics are the things we control — volume in, coverage, configuration, how many operators have finished training. Output metrics are the results — cost per unit, throughput, conversion, cycle time. Defect metrics are what we broke along the way — error rates, exceptions, rework, false positives. A report with only outputs is a victory lap; a report with all three is a decision. The dispense-context analysis was a data analysis report. So was the quote-funnel analysis, and the claims sample that led to a broader investigation.
Then the press release and FAQ — the announcement for launch day, written before anything is scheduled, followed by the questions a customer would ask and the harder ones an executive would. If I cannot write the press release, we do not understand the product yet. I wrote PR/FAQs for the clinical copilot and the care platform. For the hosted catalog, I used a vision document and versioned requirements.
Above that sit the long-arc documents. A vision document for a product line: current state with numbers, future state in the operator's terms, and the staged path between them — assisted, then primary — with the evidence required to move a stage. A product strategy: three to five bets, the metric each moves, the order and the reason, and what we will stop doing. A three-year plan with year-one indicators that predict year three. And the enterprise strategy narrative that connects all of it to the company's own plan — the annual operating cycle where a product line states its goals, its headcount, its funding and its dependencies, and is held to them monthly. I wrote the AI-assisted-to-AI-primary theme for a pharmacy operation that way, and the funding case for a data platform, and contributed to the Pharmacy AI Three-Year Action Plan.
When a product has to reach customers, a go-to-market strategy: segments, adoption target, and every lever with a number on it — sales goals by vertical, a professional-services onboarding framework, self-serve tooling, marketing, partner-generated leads — and onboarding time treated as a product metric. The one I wrote for a large enterprise integration channel had five levers and one enemy: lengthy onboarding.
Then the build documents, in order of altitude. The business requirements document: problem, users, scope, non-goals, success criteria with target values, functional requirements by workflow with the exceptions written out, a risk register, and a version history — iterated in numbered versions, with a decision point for further drafting versus a pilot. The functional specification: every screen, rule and message, precise enough to build and test from; the paper-to-electronic claims conversion ran on a detailed specification. The design document, where the engineers own the architecture and I own the problem statement, the constraints and the alternatives — because the alternative you rejected is the decision. The data-mapping specification: source field, target field, transformation, default, reject, for every attribute, with sample records that become the test set. And the interface contract: what the caller sends, what comes back, what happens when it does not — request and response schemas, event schemas, file layouts, error semantics, idempotency keys.
Finally, the launch and operating documents: the work-back plan from the immovable date; the test plan with traceability from requirement to result; user acceptance scripts in the operator's own words; the parity report that is the evidence at go/no-go; the go/no-go record itself; the dial-up plan; training decks and standard operating procedures; the launch announcement written against the criteria from the requirements document; and, every month after, the business review and the Correction of Errors when something breaks.
Not one of these artifacts is written for its own sake. Each is the smallest record that lets a decision be made, defended or tested by someone who was not there when it was taken.
Tools and methods referenced in this chapter Confluence · Quip · Jira / Jira Align · Excel and SQL analysis · wireframes · interface and data-mapping specifications · versioned documents with named reviewers.