Before the cloud
was a given.
- ClientAmerican Megatrends — MegaRAC XMS server management platform.
- ProblemA complex enterprise data platform that needed a long-form whitepaper for a B2B technical audience.
- What I didResearched, structured, and wrote a 24-page whitepaper. Coordinated with engineers to get the technical detail right without losing the reader.
- OutcomeWhitepaper used in pre-sales conversations and technical evaluation cycles for a globally shipped product.
The brief, in plain English.
AMI needed a whitepaper that would make an IT admin — someone who sees dozens of vendor PDFs a month — actually finish reading it. The product was a centralized management suite for heterogeneous client platforms. The challenge was that nobody wakes up wanting to read about "centralized management suites."
The year is 2013. Enterprise IT looks nothing like it does today. There is no Kubernetes. AWS is still the new cloud. Most companies are running heterogeneous fleets of physical machines — x86 alongside PowerPC, Windows alongside Linux — procured from different vendors at different times, and each vendor ships its own management tool.
The thesis of the whitepaper writes itself, in retrospect. But at the time, convincing a buyer to standardize on a cross-vendor management layer required arguing through three interlocking pains: procurement sprawl (too many vendors), operational drag (too many tools), and cost compression (shrinking IT budgets). The document had to name the pain before it named the product.
AMI's instinct — correct — was to avoid a feature-forward whitepaper. The draft needed to open on the reader's reality, not on the product's capabilities. That reframe became the editorial spine of the whole piece.
Four constraints, one document.
A whitepaper is the hardest format in B2B technical writing because it has to do four incompatible jobs at once. Every paragraph is a negotiation between these four audiences.
Five editorial moves.
These were the structural decisions that shaped the final document. Each one was about sequencing — which argument lands first, which one does the persuasion work, which one does the credibility work.
How the document actually opened.
The opening sequence was the most-revised part of the document. The version that shipped does one specific thing: it makes the reader feel seen before it makes them feel sold to.
Notice what the opening does not do. It does not introduce the company. It does not name the product. It does not describe a capability. It describes a person — an administrator — and the physical distance between them and the machines they are responsible for. That's a whitepaper opening doing the work of narrative fiction.
The product name arrives five paragraphs later, after the reader has read the words "complexity," "downtime," and "cost" enough times to feel the shape of their own problem. By the time MegaRAC XMS shows up, it's not an interruption — it's a relief.
The category renamed itself.
The writing problem didn't.
What this whitepaper called "centralized client management" is today called observability, fleet management, AIOps, and infrastructure-as-code orchestration. The vendors changed — AMI, Dell, HP in 2013 became Datadog, Chronosphere, Grafana, Honeycomb today. The problem did not change. Heterogeneous fleets. Distributed workforces. Compounding complexity. Budget pressure on IT.
Outcomes, honestly stated.
Metrics from this era are incomplete — most B2B content in 2013 wasn't instrumented the way a modern SaaS funnel is. What follows is what can be said with confidence, and what can be said only qualitatively.
Good technical writing ages by getting more relevant, not less.
The test of a technical document is not whether it sold the product. It's whether the argument still works when the product is gone. This whitepaper passes that test. Read it cold today, swap the product name, update three nouns, and it is indistinguishable from a modern observability vendor's cornerstone content.
That's not a happy accident. It's a consequence of editorial choices made at the draft stage — leading with the reader's pain, naming the economics before the features, treating the differentiator as a promise rather than a slogan, and respecting the difference between a whitepaper and a datasheet enough to ship both.
Those rules still work. The surfaces have changed. The craft hasn't.
The XMS whitepaper is archived in this portfolio as an example of persuasive B2B technical writing in the pre-cloud era. It is presented here not as a product pitch but as a structural artifact — a document whose shape is the thing worth learning from.