Provide more than the stump speech
Your experts, whether they’re SEs, engineers, tech analysts, or CTO types, are probably so amped up on their technologies that they can speak for hours uninterrupted. All they need is the go ahead.
But that’s not what what you or your readers need in your whitepaper. Sure, it’s good color. But you don’t want to rehash something your prospects might’ve already heard (or might soon hear) in another step along the sales cycle.
You should provide something original, something your prospects will stop dead in their tracks to read. Sounds like a great idea, but it’s hard to do. That’s why most whitepapers are dull as dishwater. The title or headline might get a download and a lead. But the content? It’s usually a real yawner.
So push your experts. Uncover business and tech issues and provide guidance to your readers that they won’t get elsewhere.
And, above all, keep the language and approach simple. Avoid trendy locutions, as William Safire once wrote. Don’t use big words. jargon, abbreviations, acronyms, etc. Don’t leverage buzz words. Change the paradigm and avoid cliches.
Follow accepted grammar rules. And decide at the beginning whether you will spell things the American way or the British way. Then be consistent. You’ll soon realise the benefits of this approach. And you might even realize it, too.
Your writer, hired at great expense at the beginning of the process, will help you avoid those traps, and should write in active voice (I’ll have another rant on active voice, style, spelling and writing soon). But be there as every draft comes in to ensure the jargon and other problems don’t slip in. Edit with vigor; cut out the obvious and emphasize the important.
OK–so who’s reviewing this thing anyway? Maybe you (as if you don’t have enough to do); your experts (if you can get their attention for long enough) who are scattered around the globe; maybe a couple of field people who’d rather not think about it; your channel manager in Milan; that hot shot sales rep on the west coast who hasn’t replied to your emails in more than a year; the product manager who’s speaking at a conference next week and then is on vacation the following week, travelling to the Far East for a week and a half after that; then a product marketer who will talk endlessly about a lack of product mentions in the paper.
So, a short 16 months later, you’ll have a whitepaper.
That approach just won’t work.
It involves too many people, and you’ll miss your deadline. You won’t just miss it. You’ll be so far off track you’ll barely even know it was there. You’ll get nostalgic for the bygone days of your deadline.
So it’s critical at the outset, and at every step in between, to control the review cycles. Not because you want to keep information from certain people (although that may well be one reason) but rather that the larger the reviewing entourage, the more likely problems will arise.
Start big; end small.
At the start, distribute your whitepaper brief to everyone who wants to read it–and even some who don’t. Feedback then (before the drafting starts) is critical. Once you get the buy in on the concept, then march ahead with 3 people on your review team. The smaller the posse at this point, the more likely you’ll meet that looming deadline (which, as I think I have noted, always comes too soon). If there are issues that need clarification, excise them from the report and run that piece by the person who knowsthe answer.
All of this–every step–will help you avoid producing a paper that will have your readers reaching for the NoDoz.
And another way to keep your readers from falling to sleep is to never, ever, focus on product. Never.
How you can pull that off, along with other witticisms, in the next post.