|
Copyright © 2004, SoftwareCEO Inc. Reprinted with permission.

For his part, Jeff Ramminger, executive VP of products, technology and services for
KnowledgeStorm knows a little something about white papers, too.
His firm's website gets 1.6 million visitors a month, all seeking technical information.
They began hosting white papers about a year and a half ago.
SoftwareCEO asked these two executives how software firms can use white papers to grow a healthy crop
of leads; here's the advice these two veterans gave us.
Technology buyers read white papers. The more complex and the more expensive the technology,
the more white papers they read. And vendors routinely publish them.
A recent Bitpipe survey showed that 75 percent of technology marketers used white papers to
generate leads last year, while 82 percent planned to in 2004.
Another survey revealed that IT professionals download a median of 30 white papers every year.
And 89 percent say a high-quality white paper makes them view a company or its product more favorably.
The only question is: What the heck is a white paper? I mean, exactly?
When they get through chuckling, both executives grope for an answer.
"I don't believe the trade press is doing a great job educating the IT community about technology,"
says Bitpipe's Habegger. "They just can't keep up with the pace of change, they can't cover all the
essential details, and their authors don't have the technical depth.
"And the best technology book publishing is by necessity nine to 12 months behind the
state-of-the-art.
"People today are bypassing the trade press and using the 'net to surf for information.
So the best white papers have become the primers, the tutorials that a whole generation of
technologists are learning from."
Interesting.
"From our perspective, a white paper is a document design ed to educate a potential buyer
about a business problem and the associated solution that you provide," says
KnowledgeStorm's Ramminger.
"So you're trying to marry a set of needs or business problems with a particular approach on how to
solve those problems."
OK, now we have some working definitions.
So where should a software firm that wants to create an effective white paper start?
"When a customer says, 'I'm going to do a white paper, what should I focus on?'
we tell them three things," says Ramminger.
"Figure out who you're trying to target, make sure you teach, and make the length of your paper
appropriate."
"We've seen people try to talk to too many people at once. In that delusion, they lose the ability
to get the attention of the person they're really after," says Ramminger.
"The more targeted your white papers are, the better-especially if you can articulate the precise
market segment or job title you're after."
Everyone has a different agenda. Your white paper must speak to your audience's agenda,
or they'll ignore it.
I once overhead a VP of marketing declare, "A white paper is that very rare thing
that can be all things to all people."
He really should know better.
"I can't tell you how many clients we see that say, 'We just want leads,'" says Habegger.
"But they really want leads in a particular place, which implies a particular audience,
which implies a particular message.
"And that demands the discipline of sitting down and asking, 'Who is my audience, and
what am I actually trying to achieve?' That's where a lot of this stuff goes off the rails.
They've never really thought through who their audience is and what they're trying to achieve.
"To put it in concrete terms, if you're selling a CRM system, the VP of sales probably has to
raise his hand and say, 'OK, I agree.' But so does the CIO. And the criteria they each use are
completely different. So you need to influence both of them with different messages.
"And the person sitting down to write that document needs to understand that."
No white paper can be all things to all people. The more granular and focused you can make it,
the more effective it will likely be.
Both executives stress that more people read white papers than just
IT propeller-heads.
"If you're a VP of manufacturing, you're not going to let some IT person go off and make a
decision about an application to support your manufacturing process without you or some of your
people being involved," says Ramminger.
He's seen this change over the past 15 years.
"When I was selling for IBM in the late 80s and early 90s, you didn't always run into a
line-of-business person in the middle of the decision. But I dare say that the vast majority of
decisions are now driven by people outside IT."
That means your white paper may well need to cover the business benefits of your offering as much as
the technology under the hood.
Both executives agree that effective white papers focus on educating their audiences.
"Vendors gain the most influence if they use content to educate their different constituencies,"
says Habegger. "The best white papers come at it from an educational tone focused on learning vs.
a preachy approach."
Use your white paper to explain how your offering solves a real business or technical problem.
Don't just declare that you're the best; prove it.
This point is so important, it's worth repeating.
The trick is to explain now, so you have a chance to sell later.
In other words, you've got to prepare the ground before you plant the seed for a future sale.
And a sales pitch masquerading as a white paper will surely fall on barren ground.
"We've seen the most success with people who use white papers to educate and teach, as opposed to
selling," says Ramminger.
"A lot of people lose the reader where they haven't done a good-enough job of teaching the basic
concepts, or illustrating how a concept might resolve the business problems that reader has.
"If you do the right job of educating, people come back to you because you're a source of
intellectual capital. And at the right time, they'll allow you to talk about your product."
"We often run into people who want to put too much content into one consumable.
And they are going to lose people," says Ramminger. "The length of your white paper has to be
relevant to the audience."
Flexibility is the key here.
"There is no one single answer, because white papers have multiple purposes and different audiences,"
says Habegger.
He goes back to his example of the VP of sales vs. the software architect.
"What the architect is looking for is highly technical, no BS, no marketing, no talk about ROI,
just lots of technical detail that really burrows into the architecture. And those kind of white
papers can go to 50 pages and still work well.
"But something like that is clearly DOA for a VP of sales trying to think about his contact
management problem. That's a completely different kettle of fish. For that type of white paper,
any more than five pages is probably too long."
Ramminger likes things even shorter.
"For the CIO-level, it's got to be less than five pages. At mid-level down to system analysts,
10 or 12 pages work well. Beyond 15 to 20 pages, we've not seen a lot of success," he says.
Like many executives, he catches up on reading on the weekend, so he personally prefers just two
or three pages.
"I can carve out enough time to go through two or three pages. And in that length, it's either going
to make an impression on me, or it's not."
Here's an intriguing rule of thumb: Make each white paper as short and specific
as your budget allows. That way, each one is as short and focused as possible.
So, if you have four key points to make and can afford to publish a white paper on each one, do it.
If you can only do one paper, you're got to cover all four points in the same document.
More on budgeting later.
"People don't go looking for products, they go looking for topics," says Habegger.
"The most likely thing a potential reader will see is a title and a short description.
So effective titles are essential."
He cites a recent white paper called "What Hackers Know That You Don't," from wireless LAN security
supplier AirDefense. Habegger says its downloads are "off the charts"—partly because it's good,
and partly because it's got such a great title.
"That title is as perfect as you're ever going to get: It's catchy, it's pithy, and
it contains a benefit statement right inside it," says Habegger.
Alright then, why doesn't everyone come up with catchy titles?
As Emerson observed, "a foolish consistency is the hobgoblin of little minds."
In other words, some vendors may want every document in their library to line up in a neat pattern.
But Habegger warns against this.
"If you're putting together a collateral kit, and you have Product A, Product B, and Product C,
there's a temptation to say everything for Product A should be called 'Product A: The White Paper,'
'Product A: Our Technology Capability,' and so on.
"Well, that works fine in the collateral kit," he says, "but it's the kiss of death online."
Why is that?
"We find that any white paper with a product name in the title does anywhere from
50 percent to an order of magnitude worse than if the title contains an educational
or benefit statement."
So you can't sell in a white paper, and you can't even name your product
in the title. What can you do? For answers, let's drill down to see how prospects
actually become buyers.
KnowledgeStorm encourages clients to think of every sale in four phases:
1. Vision
2. Planning
3. Evaluation
4. Acquisition
Each phase ends when a certain document is written or a certain decision is made.
Ramminger walked me through each phase to show where using white papers makes the most sense.
"In this phase, a prospect realizes there is something they'd like to
improve in their business. They are trying to imagine some way to solve a problem.
They start to believe there could be a solution, but they're still figuring out their requirements."
This phase is complete when a prospect draws up a set of business requirements—anything
from a formal needs analysis to a wish-list on the back of an envelope.
In this phase, a prospect looks for any software that can make
their vision a reality.
"In the planning phase, the Web becomes a critical resource in helping them translate their
business requirements into some sort of functional requirements," says Ramminger.
"They start to say, 'I know how to solve my problem, and I know that solutions exist.
Now I want to start getting specific.' So they're starting to discover what a solution might
look like for them."
This phase is complete when a prospect draws up a set of functional requirements, and
confirms that some product(s) exist that could more or less meet those needs.
Depending on the size of the company, the severity of the problem, and the cost of the solution,
this could be a formal set of functional requirements, or a list of features on the back
of an envelope.
"In this phase, a prospect looks at the best players to consider, and then all kinds of
interesting data become important," says Ramminger. "They cull through all this information
and establish who are the credible players."
This phase is complete when a prospect draws up a short list of possible vendors.
For an enterprise system, this can take months. For a smaller purchase, it might take a few weeks.
"In this phase, they talk to each vendor on their short list to arrive
at the point where they can say, 'OK, you are the right vendor for me to buy from.'"
This phase is complete, of course, when the prospect actually buys some software from somewhere.
Now, let's get back to our discussion of strategy:
How do white papers fit into these four phases?
Certain information is clearly useful for each phase.
Thus, the proper type of white papers can help move a prospect smoothly along the process.
"In the vision and planning phases, white papers make a tremendous amount of sense,"
says Ramminger. "They can be very useful for educating a prospect about a set of concepts
they might not understand at that point."
In the first phase, vision, a prospect is simply imagining how to solve a business problem.
At that point a high-level white paper focused on business benefits can help them visualize
the possibilities of using your software.
In phase 2, planning, a prospect is trying to map a set of functional requirements to your software.
That's when a more detailed, technical white paper can help them understand how your solution
would work in their environment.
"White papers are one useful element, but not the only one," says Ramminger.
"By the time a prospect gets to evaluation—looking at who can meet their functional
requirements—white papers are not as critical."
In the evaluation phase, he says, case studies become supremely useful.
"If a prospect is interested in your case study, it says they believe your system can support
their functional requirements. Until then, they're probably not interested in your case study."
Ramminger says case studies are ideal for showing off your successes.
They can get a prospect thinking, "You know, this company looks kind of like we do,
and they're using this product..." And then, you're getting close to the short list.
Up to this point, we've talked about when and how to deploy white papers.
But who should write them in the first place? How should they sound? And how much should they cost?
Who writes the best white papers? A product manager? A support whiz?
A software architect? An in-house technical writer? An outside journalist?
Like many wise answers, the best one here is: It depends.
"I think it's very case-specific," says Ramminger. "I've seen great papers written by internal
people, especially someone who is very knowledgeable about the industry or the product offering.
"But, personally, I feel it's better to have someone outside the company as the final writer.
Someone who has done a lot of writing for periodicals can probably create a more consumable
document than a product manager."
Habegger takes a similar view, more or less: "I find that the absolute best white papers are
written by company insiders," he says. "But not everybody has an insider who can actually do the
authoring. The thing is to find somebody who can write decent prose in a timely manner."
Wherever you can find it, make sure to line up proper writing talent.
More than one white paper has died on the vine for lack of careful and consistent review.
To keep the process going, you'll need two or three well-chosen editors.
"People start out with great intentions, but it's a lot of work to get one of these things produced,"
says Habegger. "So they sometimes give up after the first draft. Or it drags on for a long time,
and they wind up blessing the first very rough draft."
Who should be driving your white paper publishing process?
"I think it's a cross-functional task," says Ramminger. He suggests putting together a small team
of both marketing and product people.
"The product people can help tone down—maybe that's the wrong term—help 'manage'
the level of marketing information that comes across, to help focus not on shilling the company,
but on educating the audience."
Habegger goes even further: "To be quite candid, in many cases the marketing department is the last
organization you want having editorial control over a white paper.
"What they will do is naturally try to make it parrot the marketing messages they developed.
But if they go in and start dropping marketing-speak into your white paper,
that's the kiss of death."
This touches on another key strategy:
Get rid of the marketing jargon and buzzwords.
It just doesn't work in white papers.
Both executives have years of field research to back up that view.
"The worst performers are essentially extended brochure-ware with exclamation points all over the
page," says Habegger.
"You don't have to read very far to figure out if a white paper is well-written,
if it has a nuanced point of view, or if it's essentially blaring exclamation points:
'Our product is great!!' 'Trust us!!' And the IT audience has no patience for that."
"We find the less marketing-speak, the better," agrees Ramminger.
"I'm not judging this from what I'd like to see personally. We have proof over time that better
leads are created by content that's more to the point than by content that has a lot of
marketing-ese in it."
Software firms can spend a little or a lot to commission a white paper.
"The cheapest way to produce a white paper is to do the writing and graphics in-house,"
says Habegger. "It's not only the cheapest way, but the best when your paper is aimed at a
highly technical audience."
Naturally, the cost goes up if you hire a freelance writer.
"The next step up is a 'non-brand name' freelance technical writer or journalist.
Depending on the expertise of the person and the length of the document, that can be anywhere
from a few thousand up to maybe $10,000."
Another source from Bitpipe confirms that small- to medium-sized software firms can expect
to pay $3,000 to $5,000 for a white paper from an outside writer.
"Then you get to what I call 'brand-name' third parties, Aberdeen and people like that,
who do white papers for hire," says Habegger. "For them, the sky's the limit.
You can pay $100 grand plus. I don't have their pricing sheets in front of me, but their entry cost
certainly starts in the teens and goes up from there."
"How much?" is usually followed by "How long?"
Again, it depends. How long do you have?
"You know, I've seen clients literally drag them out for years, and I've seen stuff done overnight
in anticipation of some campaign," says Habegger.
"I would say a 'non-rush' time frame is probably two to three months, allowing for back and forth,
edits, and final production."
This rings true with my experience. And a "real-world" deadline that can't slip—for example,
tying your white paper release to a particular trade show—gives everyone a compelling deadline.
Let's say you've carefully followed this advice, created a bang-up white paper,
even syndicated it through Bitpipe or KnowledgeStorm, and generated a fistful of leads.
Now you can just hand those leads to the sales force to close, right?
Not so fast.
Tossing leads to sales prematurely is "one of the cardinal sins," Ramminger says.
"The worst thing that can happen is for the marketing department to hand a bunch of leads to a
sales team. If someone downloaded a white paper in their vision phase and are still trying to
understand what CRM is, they aren't ready to talk to a salesman.
"So if a salesman calls, it makes the prospect mad. And then the salesman says,
'The leads from these white papers are no good! These people don't want to talk to me!'
"That person probably still needs to be nurtured, not sold. It's important to work with that
prospect to make sure they're ready to move on from being a researcher or a prospector to
being a buyer."
All right, how do you nurture someone who isn't ready to buy?
"One of the techniques we use with complex products is 'waterfall white papers,'"
says Ramminger, "meaning different levels of information. So there's a white paper with the general
concepts, there's one with the next level of detail, and so on."
Naturally, this approach of cascading information works best when each white paper is focused
and specific.
The bottom line is this: Using white papers strategically means
evolving from old-fashioned "interruption marketing" to today's so-called "permission marketing."
Interruption marketing means making cold calls, banging on doors, and phoning people
while they're eating dinner, all in the vague hope that somebody out there has to be interested
in whatever you're selling.
Permission marketing, on the other hand, means engaging a prospect in a kind of dialog-on-demand,
building their trust by sending them helpful information when they request it, and drawing them
into your sales funnel at the pace they want to come.
"The biggest thing is to establish that a person is willing to accept content from you,
and then to send them content regularly," says Ramminger. "And always give them the opportunity
to raise their hand and say, 'Could somebody call me about this?'"
That's when you call in the sales force, and not before.
Until then, white papers can help build your credibility without hype, and explain your
technology without selling.
This approach calls for great patience and restraint. But using white papers this way can pay off
in a steady crop of great leads that blossom into happy customers in the proper season.
|