Has this ever happened to you?
You’re with your spouse, or a good friend. They start telling you something. As you listen, you realize that you have no idea what they are talking about. They might be talking about someone you both know. They might even be talking about a place that you both know. But other than that, you have no idea why they are talking about what they are talking about.
If you’re like me, you have to stop the speaker, very politely, and say something like, “I’m sorry, but you’ve lost me here. I don’t understand what you are talking about. Can you fill me in on some details, so I understand where you’re headed?”
What I have done is ask my spouse or my friend for context. I’ve asked them for some background. Because any conversation, unless it is based on a common set of facts and assumptions, is hard to understand.
When you sit down to write a white paper, you follow a logical order. You write a title that names a problem and hints at a solution. You create a table of contents that outlines your document. You write an executive summary that summarizes your document. You write an introduction that introduces your topic, names a problem, and outlines a solution.
If you are like many writers, you are now tempted to write the solution part of your white paper. You’ve just named the problem you are addressing, and now you want to address it. But going from your introduction right to your solution skips a vital step—context and background.
You must assume that some of your readers will not be as familiar with your topic as other readers are. You must assume that some of your readers are in the position you are in when someone is talking to you about someone you know or a place you know, but you don’t have a clue what they are talking about. You need context and you need background.
In your white paper, you may need to describe a trend that brought us to where we are today. You may need to define some key terms that are unfamiliar to some of your audience. You do this with a background section.
Example one
Here’s an example of what I mean. Here’s a white paper called, “How CIOs Can Improve Supply Chain Management, Even with a Tight IT Budget.”
The white paper begins with the problem statement. “Nearly all CIOs today are under pressure to contain costs; in fact, many are being asked to cut IT budgets by 20%. But the
challenges of dealing with the recession have not gone away, even if the budget has. In fact, these have become more acute.”
The writer now states the solution: “This white paper looks at one way CIOs can roll out significantly more powerful supply chain functions at an affordable cost: by extending existing systems with specialized software delivered as a service (SaaS).”
As you scroll down to the next section, you may be expecting to see a description of the solution. But you don’t. That’s because this writer knows that some readers need context and background before understanding the solution.
So, the writer gives you background on the issues at hand. The writer does this in a section called, “The limitations of traditional tools.” Excel? Not robust enough. ERP? Focused on transactions. Legacy planning? Designed for yesterday.
The writer then supplies a table that describes the four types of software used for sales and operations planning. At the bottom of the page, the writer names the solution again: “SaaS can be a game-changing alternative to the traditional ways of buying and using enterprise software.”
And as you scroll down, you see that the background section is followed by the solution section: “Extending your sales and operations planning with software as a service.”
Example two
Here’s another example from a white paper about “Hyperledger Blockchain Performance Metrics.” The white paper begins with an introduction that introduces the topic and describes the problem. “While blockchains may appear similar to distributed databases, they are typically implemented without a central authority and central repository. This makes measuring and comparing performance between different blockchains very difficult.”
The writer then outlines the solution: “To help precisely and consistently evaluate the unique performance attributes of blockchains, this paper defines many relevant terms and metrics, and discusses some complex issues.”
But the writer doesn’t jump from the problem to the solution. First, the writer makes sure that all readers are working from the same set of definitions and terms. Only then can the writer expect the readers to understand the solution.
The writer first defines blockchain terms, then gives definitions of key metrics. After giving this background and context, the writer moves onto to discussing the solution, in a section of the white paper called: “Considerations for Blockchain Performance Measurement.”
Not every white paper you write needs a background section. For some of your white papers, terms, definitions and trends are well understood by everyone in your industry. If this is the case, leave it out.
But if the topic of your white paper is novel, if you are taking a unique spin on the status quo, you may need to give your readers some context before you jump into your discussion of solutions. You may need to describe the events and trends that brought us to where we are today. You may need to define some new terms, or give a name to a new problem.
Remember, a whitepaper is a persuasive, authoritative, in-depth report on a specific topic that presents a problem and provides a solution. You can only be persuasive and authoritative with your readers if they understand what you are talking about. To do that, give your readers context and background. They will thank you for it.
………………………………………………………………..
Alan Sharpe is an inbound writer & strategist who helps HubSpot Partner Agencies deliver effective inbound content for their clients.
Recent Comments