Your Marketing Collateral Needs a Checklist

  1. Is your product or service clear in the collateral? It’s easy to assume that readers know what you’re talking about; when unbeknownst to you they don’t have a clue.
  2. What are the features that will interest your audience the most? There is a huge dependence on “benefits” in marketing writing. This is a mostly a good thing, but in technical marketing collateral you have to get your features across too.
  3. How are you different from your competitors? Unless you’re doing a competitive positioning piece you might not mention your competitors by name, but you had better not be doing a second-hand echo of their positioning, especially if they’re a lot better-heeled than you are. (Avis may have developed their tagline in response to Hertz, but that tagline has made them billions.)
  4. What are your customer’s pain points? Mentioning them is critical in a white paper, but even in other formats you should know why your audience is going to care about your offering in the first place.
  5. Do you know who your prospects are? Small, medium or large enterprise; large mid-range; small mid-range; SOHO; data center managers; CIOs; etc. Know who you’re trying to reach with what collateral.
  6. Is your collateral easy on the eyes? IT staff and engineers want technical collateral, but that doesn’t mean they’ll wade through writing that is dull and dense. And executives won’t stand for it. Design your collateral for logical and headache-free reading, and write using strong words, a clear structure, and an active voice.
  7. Involve your sales team. You just know they’re going to change things around anyway.

Dreading the Writing Assignment? Use Outlines

Writing technical articles is a challenge. There you sit, surrounded by reams of research, notes and interviews. Where do you start?

Remember 5th grade English? You start with an outline.

Outlining has fallen on hard times lately. Mind mapping and brainstorming are much more fashionable. These techniques are great when generating ideas, but once you’ve got your ideas germinating you’ve got to outline them.

Don’t let this happen to you – outline. If it’s been a while since 5th grade – or if your “progressive” school didn’t stoop to teach you actual English skills – let me remind you why it’s important and how to do it.

Outlining keeps you from writing an unstructured mess. Readers, especially American readers, prefer distinct sections in their media. For example, look at American screenplays. Movies invariably have three acts, and anything that doesn’t have them is considered an art film. Effective speeches often contain three parts, and readers like three points because the structure makes it easier to retain information.

Outlining shrinks your writing time by a third to a half. How do you whittle down that pile of research notes and interviews into an article or white paper? You guessed it – outline it. By assigning sections to your notes before you start writing, you’ll categorize, simplify and clarify. Not bad before you’ve even written an introduction.

How White Papers Support Marketing

A white paper supports PR, marketing and sales because it works for all levels of decision makers. Engineers and executives may not be too impressed by brochures, but they are impressed by well-written white papers. (The same thing goes for trade journal articles – more about that in a subsequent piece.)

Good white papers sell products because they pack a lot of useful information into a clear and readable structure. Warning — don’t take any old brochure or product brief, print it on 8-1/2×11″ paper and call it a white paper. Decision-makers hate that, don’t let this be you! Good marketing white papers contain both technical and marketing sections in a balanced format, and then throw in some other great stuff. A good white paper may start with an executive summary – my general rule is a 5+ page paper needs one – but it will follow the same structure as below, abbreviated to one page.

White papers should include:

  1. Throw down the challenge glove. Describe the pain the prospect is experiencing. (That you can help with, anyway!) Describe the problem from their standpoint, and be sure you know what that problem is.
  2. Talk about how your technology will solve their problem. Bore in on the technology behind the product and how it will make their lives easier. Be sure to include some technical detail for the engineers and technology journalists who are sure to read it. No one is asking you to print the code for heaven’s sake, but they do want some indication of how it works.
  3. Get specific on product benefits. This section combines with the technology section and includes ways that the product meets the challenge. You can also use this section to contrast your approach with other technologies, especially if your product is innovative. We all know the sad fate of disruptive technologies, but readers do want to know what your product does differently, how it does it, and why it does it better.
  4. Push a positive return on investment. ROI has always been a big deal, and with reason. If you have great hard cost numbers, terrific – don’t hesitate to use them. Longer white papers have room for graphs and charts, but even shorter ones can refer to positive ROI. Newer ROI analysis methods factor in “soft costs” – employee time, improved infrastructure, etc. – so don’t hesitate to talk about those too.
  5. Add some case studies. Actual case studies with actual customers are ideal, but if you can’t mention customer names (common in the financial world), it’s fine to speak more generally. “A Fortune 100 finance company recently deployed…”
  6. Conclude with how great your product is and contact information. Here’s where you can use the marketing mottoes, just keep it to 1-2 paragraphs. And include your contact information!

Well-written white papers have lots of good uses. Here’s a run-down:

  • Sell a product – its ultimate purpose, of course
  • Differentiate product from competitors
  • Place company in leadership role
  • Promote bylined author as a subject matter expert. (Which they should be, even if a professional writer actually wrote the thing.)
  • Help journalists research their stories (note: journalists are not helped by sales brochures)

The Working Case Study

Next to white papers, case studies are the most popular tool in the technical marketer’s toolkit.

The ubiquitous case study can range from a 3- paragraph online snippet to a full-blown magazine article. The most popular case study in the marketing/PR arsenal is the 500-700 word success story. They’re not as challenging to write as white papers, but you should structure them for maximum impact.

Different companies use different structures for their case studies, but all should follow the same general pattern: 1. Company overview and challenge 2. Project details 3. Positive results (of course)

Customer Overview and Challenge

Start with a 2-3 paragraph overview of the customer’s company. This should be very positive – since you’re going to detail a problem the customer was having, the last thing you want to do is make them sound like jerks. So compliment them. Feel free to adapt the overview from their own Website text, where they’re already placing themselves in the best possible light.

Then move on to the business challenge. Don’t make the customer sound stupid or incompetent. The challenge should always be centered on something good that is happening to them – fast growth, industry prominence, strategic IT changes – whatever. Their challenge should be applicable to your readers’ own business issues.

Project Details

No project goes perfectly, but save the debriefing for the longer-form trade journal article. These short case studies should report on the successful project by briefly discussing specific products and benefits.

Don’t go all over the map. If the project is fairly narrow or specific, you won’t have any trouble sticking with the main point. In the case of large and complex installations, concentrate on the main point. For example, Microsoft Great Plains has more modules than you can shake a stick at. Concentrate on the ones that had the most positive impact on your customer.

Business Benefits

Always quantify improvement when you can. Numbers can be dollar savings, percentages, or other measures of saved staff time, more efficient workflows, better customer service, etc. Be sure that the benefits you list are the benefits the customer perceives – hard costs are most easily quantified, but soft costs may have the higher perceived benefit to a customer. Ideally you will list both.

When NOT to Write a Case Study

What are the most common blocks to partnering with a customer for a case study?

  1. Your customer is really unhappy. They’d do a case study all right, but you wouldn’t want them to. If you’re the hapless individual setting up the initial interview, be sure that the customer really is happy and is open to talking to you. Otherwise they’ll just give you an earful. Fix: promise the customer that you’ll pass on all of his comments to the technical support team, or whoever you think will best handle it. Then do it, and forget about it.
  2. Customers who fear their market will punish them. Prime example: legal firms with security issues. Sure you helped them through a security project and now they’re Fort Knox, but they don’t want their clients to dream that a problem ever existed in the first place. Fix: Forget it. They’ll never give you permission to produce the study. Besides, they’re probably right.
  3. Your customer is an exacting IT type who is suspicious of the success story format. This customer considers the project a success too, but they dislike purely positive spins – and no project is perfect. Fix: If they are happy for the most part, get a buy-in that the project really was successful. Don’t put him off about the negatives, capture those comments too and promise to pass them on. (Then do it.) This is usually enough to secure the interview.
  4. Your customer is scared to be interviewed. This is usually the IT guy who did all the footwork, and prefers to stay behind the scenes. He (or she) will either be too nervous to talk, or will despise you because he doesn’t think you’ve got the technical chops. Usually both. Fix: Understand the technology you’re interviewing about. You don’t have to be an engineer, but you should understand IT pressures and issues. Ask leading questions, but if they clam up and won’t talk, thank them and hang up. Tell your customer contact that you’re so happy you got to talk to the technician, and now could you talk to a project manager too?