Many organizations develop technical white papers to explain the advantages they offer or to educate their stakeholders about situations or issues. And all too often, those technical white papers perform poorly. So the stakeholders come away not knowing any more and the organization’s team has essentially wasted the time they spent developing them.
Why do technical white papers fall short of their objectives? Obviously, there could be any number of causes — not the least of which might be the inability to write well — but in my experience, there are four common ways technical white papers fail to connect with readers.
1. Technical white papers go above readers’ heads
One of the most common reasons technical white papers aren’t successful is because they’re written to the organization’s level of knowledge instead of the customer, prospect, or other stakeholder’s level. In simple terms, it’s what happens when we fail to recognize others may not know the same things we do. The phenomenon is so common it’s earned a name: the curse of knowledge.
Nobody is saying knowledge is an inherently bad thing (although I can remember some classes that likely qualified). Every society and organization needs smart people who have learned how to figure things out. If your appendix starts throbbing, you’d rather check in with a doctor than the accountant who lives two door down. But if you get a personal note from the IRS, you’d turn to the accountant without hesitation.
2. Technical white papers can be unbalanced
The problem occurs when there’s an imbalance, such as when the person who is sharing the information has greater knowledge on that subject than the sharer’s target. Sometimes it’s an educational difference, but more often it’s a degree of awareness. If you’ve repaired a couple thousand hernias you regard them differently than your next patient. When you talk with other docs, you use a lot of shorthand and abbreviations.
But as you explained the surgery to the patient, you threw in several of those abbreviations and used some of that shorthand. The patient nodded, since they didn’t want to appear to be stupid, but they understood very little of what you said. You’re frustrated because the patient seems to ignore your advice. They’re frustrated because they don’t understand that advice, but are too intimidated to ask for clarification. How many times have you heard a friend or family member tell you they can’t understand what their doctor told them to do?
So if your technical white paper writer is a highly trained graduate of one of Indiana’s many esteemed engineering programs, they might not realize the high school grad who worked into a supervisory role in the plant doesn’t share their deep background in metallurgy and physics. When the reader encounters that common formula everyone in the engineer’s 200-level course had to memorize, two things happen. First, they get frustrated and embarrassed. Second, they stop reading because they assume they won’t understand any of it. If you want to connect, write at the reader’s level, not yours.
3. Technical white papers use jargon
Every profession, industry, and company has its own argot — a unique language shared among those within the profession, industry, or company. Using that language is okay when communicating with peers, but when the audience is an outsider, it’s going to be confusing at best and indecipherable at worse. The same is frequently true among people who write technical white papers.
Consider the parents who learn at the parent-teacher conference that little Johnny ranked at the 74th percentile on a norm-referenced summative assessment. They don’t know what that means, so they aren’t sure whether they should be proud or humiliated. The teacher was pleased Johnny scored better than nearly three-quarters of kids his age on a test that measures what they learned. If the teacher had said it that way, the parents would have understood. Save the jargon for your next meeting and keep it out of the white paper.
4. Technical white papers are complex
Another tendency among well-educated staffers who write technical white papers is to express things with a great degree of complexity. As with jargon, that’s because they’re comfortable with that complexity. Often, though, readers are either overwhelmed, confused, or even repulsed by complexity, so they don’t come away with the desired message.
Once I had to share an automotive engineer’s explanation of a physics property known as rubber’s memory with auto mechanics. I could have provided long explanations of the effects at a cellular level, but instead used rubber bands as an analogy. Stretch a rubber band as far as you can, and it snaps back to its original size and shape. That’s memory.
5. Technical white papers are detailed
Technical white papers are expected to share a substantial amount of information, but often they provide far too much. It isn’t that the extra information isn’t valuable; it’s that it dilutes the impact of the most important messages you hope to convey.
By scaling back the degree of detail, you allow the white paper to focus on those important messages. Instead of getting bogged down by every potential circumstance, the reader walks away from your technical white paper with useful knowledge to help them make more confident decisions.