White Paper Work
After reading some convoluted white papers recently, I thought it might help to lay out my personal process for writing a white paper that works.
Works means that the white paper breaks through the noise to, first, actually be read and, second, encourages the reader to take an action. A working white paper work needs a clear, concise argument as to why the reader should take the slightest interest in your software product or service. It's useful to think in terms of five, distinct roles when writing a white paper: analyst, scientist, architect, carpenter, and judge. And this framework stems from Bryan Garner's "The Winning Brief."
The analyst: agree the brief
Writing a white paper starts with getting a clear brief agreed. You need to agree objectives and outcomes and answer key questions including:
Who are the main users of your software?
What job do they hire your software to do?
What is the single most important benefit your product offers?
What is the target audience for your white paper?
What is the core message to communicate to this audience?
What are vital few key words that you want to target?
Flimsy, unclear requirements are the source of most trouble in software development. It's the same when writing a white paper.
The scientist: dig deep and research
White papers start with a clear brief, but compelling copy is built on research. And deep research takes days, not a snatched hour here and there.
Technology white papers typically need to translate complex software into straightforward messages. In the Scientist phase, you need to dig deep to understand your product: where it's been and where it's headed. You also need a demonstration and an understanding of the strengths and weaknesses of your competitors. Finally, you start building communication elements for the white paper including:
Function. What the product does -- its primary attribute, feature, or function.
Benefit. How the product helps a customer do their jobs better -- why it really matters or how it makes a difference?
Philosophy. Define a one-sentence purpose of the product.
The architect: structure the content
Writing a white paper that persuades or presents an interesting point of view depends heavily on the quality of the overall argument and structure. At this stage, you should outline your white paper including:
Piece all the points together into a coherent, overarching structure. The most useful thing I ever learnt as a management consultant is to think through arguments using The Pyramid Principle, designed by Barbara Minto, when she worked at McKinsey.
Develop a theme statement. It's your central point, defined in one sentence.
Craft a headline. The first requirement is to get read and the headline is critical. You need to promise a benefit to the reader for reading the white paper. Why is this white paper worth the reader's time and attention?
Outline the body of the white paper. Include all the major copy points in order of relative importance.
The carpenter: write the draft
Writing a white paper has two steps:
Write a first-draft white paper including graphical elements. Review and edit for major structural and writing issues. Shorten, simplify, and sharpen.
Revise and produce a second-draft white paper. Review and edit for minor structural and writing issues. Strip away all unnecessary words. If it isn't essential, cut it out.
The judge: polish and publish
Time for the white paper to work and put it out there to differentiate your product (and you) and start generating leads. The steps here are:
Provide final proofreading.
Track lead performance.