Why do some case studies work so well, while others don’t?
Why are some so dazzling, while others are dull as dishwater?
Over many years of writing and reading case studies, I’ve noticed several blunders that writers often make.
You can take your next customer story from feeble to forceful by fixing these top seven blunders.
Note: This article uses “customer” for the company with the problem, and “client” for the company that helped solve the problem.
Case study blunder #1: No compelling lead
How many case studies have you seen that start like this:
“Acme Software is a leading provider of enterprise productivity solutions delivering best-in-class reliability, availability and scalability”?
What a snooze-fest?!
Lazy or inexperienced writers often begin by pasting in the “About the Company” blurb from the customer’s website.
This wastes a golden opportunity to snag the reader with a true magazine-style lead.
I consider this the biggest single blunder that destroys the impact of many case studies. And the real shame is, it’s so easy to fix.
“What’s a lead?” you ask
A lead is the first sentence or two of an article designed to get the reader’s attention and propel them to read on.
This may sound difficult, but there are examples all around us. Pick up any magazine and read the first couple lines of every story.
For example, Inc. magazine does a great job on leads, making the world of independent business come alive with drama and passion.
Some sample leads I’ve written
A bold assertion:
Few people in the world know as much about USB as John Hyde.
― case study on a USB protocol analyzer
How do I pick up the box in Leonardo da Vinci’s studio? And where can I get an extra-large pouch for my throwing knives? Can you answer questions like these in 11 different languages?
― case study on a company that does tech support for computer gamers
A symbolic link between customer and client:
When your business is named after the winningest coach of all time, you can demand the best of everything… including your business systems.
― case study on software used in a chain of restaurants
Case study blunder #2: No application snapshot
While this doesn’t belong in your lead, you do want to tell your reader about the customer that your client helped.
This calls for some background (or exposition, as fiction writers call it).
The problem: Exposition interrupts the flow of a story, slows down readers, and even makes some quit reading.
The solution: Move the background details about the customer into a sidebar or “snapshot” on the front page with a few concise headings such as:
Sometimes I include “Quote” for a juicy quote from the customer.
Many companies have an established set of headings to follow. For example, when I wrote case studies for Google, the company used:
If you’re breaking new ground for a smaller company, you can create your own headings.
For example, for a case study on smart boards aimed at computer lab teachers, I set up a snapshot with these headings:
Number of Computer Labs
Impact on Learning.
Whatever you call them, use a sidebar to sum up the high-level details… and keep the exposition out of the way of your story.
A sample snapshot (above)
Notice how you can use bullets to give more than one point under a single heading, such as Results.
Case study blunder #3: No story
An inexperienced writer who never finds the real story may fall back on a tired formula:
About the customer
+ the wonders of the solution
+ how happy the customer is today
= one complete case study
But this completely glosses over the problem that bothered the customer enough to search for a solution. A story with no problem has no drama. And a story with no drama has no readers.
For a case study to work well, it must show how unhappy the customer was before seeking out the client’s solution. This contrast between the problem and the solution, before and after, makes the story.
If you don’t have the story yet, don’t start writing. You’re not finished your research yet. Keep digging.
Case study blunder #4: No concrete details
I once interviewed the head of IT at a city college who told me, “Our legacy system couldn’t maintain adequate throughput. Our back-office productivity was being impacted.”
When you hear something like this, your job is to delve deeper. Why? Because this description is abstract: It doesn’t paint any real-world picture of the problem.
The key to any case study (and really, to any great piece of writing) is the concrete details: things you can see, smell, touch, hear, or feel.
When faced with an abstract description, press your subject for more. Some useful questions are:
- What did this look like?
- How did this affect your team day-to-day?
- What about your clients, did they notice anything?
When I asked the school administrator for more, he was happy to elaborate.
“Our system was going up and down like a yo-yo,” he said… a truly memorable quote!
He explained that the legacy system would crash at least once a day, deleting records of student grades and tuition payments. Every day his team had to look into their backups and pray the system lost only a few minutes―not a few hours―of transactions. Office staff were getting unruly. And his manager told him, “Fix it or else.”
Now I was getting somewhere.
All those unhappy people made some nice scenes I could paint with words.
See what a difference that kind of concrete detail can make?
Case study blunder #5: No ending
Ask any writer and you’ll find that endings can be the hardest part of writing a story. A story without an ending doesn’t feel complete, any more than a dinner out without dessert or coffee.
One trick that works for me: Go out where you came in.
If you can return to the drama you used for your lead, and show how everything turned out, your reader will feel satisfied at the end.
Here’s another take on this, a technique you can borrow from fiction writing: The end is in the beginning. Your story poses a question: Will the hero fix the system and save his job? Will the winningest coach of all time flub it with his restaurant software?
The answer forms the ending to your story.
For example, here’s how I finished up the story about the coach’s restaurants:
All in all, [product name] has become one of the most valuable players in the lineup at Shula’s Steak Houses, supporting the owners in their ongoing quest for the best.
A great case study photo: retired football coach Don Shula holding one of his famous steaks in one of his restaurants
Case study blunder #6: No photos
Speaking of photos, you do have a photo of your customer to include, right?
Nothing says “real world” more than your case study source standing in their office, factory or warehouse and holding up one of their products, like in the sample above.
Unfortunately, very few business people have publicity photos of themselves. They just don’t get asked for one… ever!
The main excuse for not using photos is lack of budget. Here are a few low-cost options for getting photos for a case study:
Local photographer: If you have a few dollars, hire a photographer from the local newspaper in the customer’s town to go snap a few candid digital photos. This shouldn’t cost more than $150.
Student: If the town has a college with a photography class, ask the instructor if their best student could take a picture for you. They can likely come up with something for a modest honorarium like $50.
Publicity photos: Ask the company’s marketing department what they have. Don’t just download one from the website, since these are usually only 72 dots per inch and you need a higher-res version for your designer, more like 300 dpi.
Google Maps: This is pretty desperate, but if you really need an exterior view of the customer’s premises, you may be able to capture one from Google Maps, by entering the address and then switching to street view.
Stock photo: If all else fails, try searching for a stock photo that shows people using the customer’s product… or one close enough that no one can tell the difference. Just avoid those annoying “smug shots” of happy people in their happy lives that everyone knows are fake.
Customer’s logo: By all means, include this as a graphic. This will likely be the most scannable element on the page.
Other than logos, I don’t like to use graphics or clip art in case studies. They just don’t say “real world” the same as a photo.
Case study blunder #7: Not scannable at-a-glance
Busy executives won’t likely read every word of your case study from start to finish, especially when online.
Busy people skim, scan and skip… so you’ve got to achieve the main purpose of your story at a glance.
To my mind, the main point of a case study is to give new prospects a warm and fuzzy feeling about dealing with the client.
The headline, photos, snapshot, and subheads must all support a “quick scan” that gives casual readers the gist of the story in an instant.
“Oh, I get it,” you want them to think, “This city college used Acme Software to replace their flaky old system, and it turned out great.”
Make sure your designer understands this concept and makes your pages easy to scan.
The biggest danger is too many words. So don’t be afraid to trim down your text. About 700 or 800 words is fine for most customer stories… if those are well-chosen words.
A powerful case study includes:
- a strong beginning (lead)
- a summary sidebar (snapshot)
- a dramatic story
- lots of concrete, sensory details
- a satisfying ending
- a design that’s easy to scan
- a great photo of your customer
If you can develop all these elements, your next case study will be truly outstanding.