Virtually every tech business posts stories about their customers’ wins with their products or services. Call them case studies, customer successes, or use cases, these pieces follow a standard pattern: the customer (a business) has a problem. They find a technology solution. They get positive results, preferably quantified with numbers. Happy ending.

These stories obviously serve a purpose—proving to prospective customers that your products and services really do work in the real world. But do they have to be so boring?

I recently wrote a case study for a tech vendor (who shall remain anonymous) that was full of human drama: a networked health organization was losing track of cancer patients as they went through its distributed clinics and specialists, because the patient records weren’t accessible by all stakeholders. Patients got lost in the system. Some didn’t get the care they needed. Some died before their time.

Although they obviously couldn’t be too specific about individual patients, the people I talked to—whether technologists or doctors or administrators—were obviously, deeply, and personally distressed at what was happening. Lives that could have been prolonged or even cured by the right treatment at the right time were being lost. This was a significant story, with lots of the personalities of sources, and the real importance of the role technology had to play in saving lives shining through. I wrote it up, including, of course, plenty of kudos for the vendor’s products being a major part of the solution.

The vendor came back with a big no. The story wasn’t about lives being saved, they said. It definitely shouldn’t focus on the emotions of individuals within the company—or even of its customers (patients). It was about the improved scalability, performance, and security of the systems. So I rewrote it to their specifications. They loved the rewrite, which is bland, emotionless, and much, much, less powerful.

Contrast that with this story on another vendor’s website.  The company’s goal was to highlight how its app development tools were making it easy to create mobile applications across a broad spectrum of health use cases. Sounds pretty dry, doesn’t it?

The story couldn’t be less so. It starts with what journalists call an “anecdotal lede”: of a Black mother who didn’t receive the medical care she needed post-pregnancy, and who died of birth complications. The woman was named; her mother and friends interviewed; you had a rich view of an accomplished life well lived until a tragic, early death.

The focus of the article then broadened to talk about inferior healthcare for women of color, and how mobile apps were being developed to eliminate these systemic gaps in care. The apps were discussed, as were the vendor’s tools used to develop them, and the story of how easy-to-use and powerful the tools were came clearly through.

So the vendor got its plug—unequivocally—with a story that lingers in the mind far longer than a simple challenge-solution-results case study ever could.

[inlinetweet prefix=”” tweeter=”” suffix=””]Stories don’t have to involve life-or-death scenarios.[/inlinetweet] Think of a hypothetical story of a datacenter tool that makes systems more scalable, high-performing, and secure. How could you make that interesting?

Focus on the personal.

Say, because of the reliability of the system, data center manager Samantha Smith was no longer awakened in the middle of the night—and she was able to retain her IT operations team Jeff, Wayne, and Rebecca, because they also were no longer losing sleep (literally) due to outages. Talk about stress on their families dropping off a cliff because they made it home for dinner and didn’t miss breakfast after a long night. Show Rebecca getting a bonus because users were so happy with being able to get their work done on time. Interview actual users to talk about how they didn’t have to stay late or work overtime to finish their tasks for the day, giving them more time for their kids, or playing piano, or golf.

As I’ve stressed before in this blog series, the devil is in the details. Get them. Don’t be afraid to ask questions that bring out the human side of technology.

The question is, why aren’t we doing more of these kinds of stories? They’re harder to do, for starters. You have to interview more, and more diverse kinds, of people. You have to question people on a level you probably haven’t done before. You might be comfortable asking about bits and bytes, and less about how a person responded to their IT-worker spouse getting a promotion. You’ll have to act out of your comfort zone.

And, of course, the biggest obstacles are the gatekeepers to these stories getting published—the marketing managers and content strategists who are married to tried-and-true, narrow and bloodless, case study templates.

I don’t know any way to get around that except by example. Writers should show their bosses/clients examples like the one above. Ask if you can write a prototype. Ask if you can do an A/B test with a traditional story and a human one. Try sneaking colorful personal details into the stories you are assigned to write.

Keep pushing the envelope. Aside from all the benefits to the tech companies you work for, it’s deeply satisfying to write these more human-oriented stories. Your portfolio will be stronger, and you’ll have a greater sense of accomplishment of perhaps making a difference in the world by telling people’s stories that go beyond merely selling software or hardware.