Great business books include case study stories. They also include frameworks and analysis. For maximum effectiveness, never mingle the two.
Here’s an example to clarify what I mean. In The Age of Intent, the book I ghost wrote about artificial intelligence last year, there is a story at the start of the customer service chapter about how Dish Network executive Lucky Rai implemented automated customer service agents. The point of the story is that customer service chatbots can improve quality of customer service in areas like consistency, uptime, capacity, speed, and productivity.
The case study story starts like this:
Lucky Rai was a Dish Network customer long before he started to work there. His first exposure to the satellite TV service was as a child in a first-generation family of immigrants — a family for whom Dish Network’s dozens of authentic Indian channels were an essential part of the family’s home entertainment.
As you can imagine, this continues with a description of how he grew up, got a job at Dish Network, rose through the customer service organization, helped the company to decide to implement chatbots, and generated favorable results.
There are three ways to approach the question of how to write the case study and the analytical framework it reinforces:
- Describe the framework, then tell the story and point out how it relates to the framework.
- Interweave the case study story and elements of the framework in a combined description.
- Tell the story full, then at the end, refer to it to clarify what the framework is and how it applies.
People who haven’t written business books before often choose 1 or 2. But 3, in which the case study stands alone and unsullied by argumentation, is almost always the better choice.
Why you should do the case study first, then the analysis
Stories are magic. People will read them to the end. If you’ve done a decent job of writing the story, you count on retaining the reader’s interest.
Of course, while you’re writing the story, you are thinking “this element reinforces this point I want to make, and this other element reinforces this other point.” It’s natural to include those points along with the story.
Don’t succumb to the temptation to do so.
Think of it from the reader’s point of view:
- Stopping the story narration to make your own points interrupts the reader’s flow. The reader has to stop thinking about the story, then pick up the thread again as you continue narrating. You lose the main power of stories — to retain the reader’s attention.
- You also attenuate the effectiveness of the analytical frameworks or points. You’ll doubtless want to reinforce the points after the story. This creates duplication — the reader thinks “Am I supposed to keep track of these points? Wait — now I’m reading something I read before.” Repeating points doesn’t make them more convincing.
A much better sequence is to write the story through from beginning to end first. Include a section head to signal a shift in tone, then explain “the moral of the story” — the point you want the case study story to drive home.
The first set of insights after the story are what I call “the pivot.” The reader, having read your story, is open and ready to believe. That’s when you get to show them the meaning of what they just read.
For example, here are excerpts of what follows immediately after Lucky Rai’s Dish Network story in The Age of Intent:
A new day for customer service
Customer service has been squeezed between costs and quality for decades. . . . Each of those changes [that happened over those decades] reduced costs. But each also created new challenges for customers navigating the system. . . . Customer service is a customer reaching out to have a conversation. It’s an opportunity to shine.
And these days, the more effective you are with digital tools, the brighter you’ll shine in that interaction.
Have faith in the story and the reader’s attention
This is a hard lesson to learn. Writers often don’t trust readers. They tell me “I need to explain what’s coming. I need to explain why what happens in the case study is important.”
You don’t. Trust me. Trust your reader. They’ll be patient enough to read through the story and then wait for the insights.
If you must tease what’s coming first, go ahead. But keep it short.
Tell the story. Include only the elements that reinforce the points you’re trying to make, or make the narrative interesting. Tell it in chronological order to make it easy to follow. And keep the narrative tight, to ensure that readers don’t lose interest.
Then explain the framework or general points you want to make, referring back to events in the story to reinforce those points. The reader reading this will have an “aha” moment. They’ll see the story in a new light — as an icon of the framework or point you are revealing. And they will never forget it.
They’ll forever think about that point in the context of the story. That’s how they’ll remember it. “That’s just like in the story about the customer service chatbots at Dish Network.”
So have faith in the story. Tell it. Reveal what it means afterwards. Your reader will internalize those lessons. They’ll think you’re smart. And they’ll feel like they’re smarter. And that’s the whole point, isn’t it?