Quick Tip: Don’t cross the red line
Companies doing their first-ever white paper often suffer from what I call “The Kitchen Sink Syndrome.”
They tell me they want to generate leads.
But they’re also dying to tell the world about their brilliant new product.
And then they come up with a listicle or two.
So they dump all that into one document.
That ends up as a mishmash with no clear narrative thread.
I tell my clients they will get far better results if they separate that content into two or three different documents:
- To attract fresh prospects, use a problem-solution (chocolate)
- To re-engage prospects in the middle of their customer journey, use a numbered list (strawberry)
- To beat competitors in a product evaluation, or to support a new product launch, use a backgrounder (vanilla)
And here’s a simple way to say all that in shorthand.
Set a red line that a white paper must not cross
Politicians love to set “red lines.” Even when—as John McCain said—these seem to be written in invisible ink.
So here’s how you draw your red line for a white paper, based on the audience analysis you did before you started.
(You did an audience analysis, right?)
It’s a simple box with one line through it, as shown above.
On top, you write: “What readers need to know.”
Below the line, you write: “What they don’t need to know.”
How to use your red line
Whenever you hit irrelevant material or a suggestion to go into some side issue, ask this question: “Do our readers need to know that?”
To push back some more, ask, “Really? Are you sure about that? Why?”
An inexperienced client may be uncertain about what a prospect knows and what they don’t.
In that case, layer in some background as described in my article “How to write a white paper for multiple audiences.”
Sometimes a SME wants to include a step-by-step “history lesson” on how the product was developed.
In that case, gently tell them, “Yes, that’s interesting to us. But I’m concerned that your prospects might stop reading if we go into that.”
All in all, I urge you—marketers and writers both—don’t cross the red line.
Thanks to Manny Gordon for this concept, which he used when interviewing software developers for technical writing projects.
For more quick tips like this, subscribe to my free newsletter.
