As a writer and marketer, I’ve had the opportunity to write case studies for startups, established firms, and even publications. Consequently, these experiences have left some indelible marks on me on the art of case study writing.
The easiest time I had writing case studies was writing for ZDNet and TechRepublic back in the day. The reason was that it was a story in an industry publication that everybody could read. I had PR people going out of their way to help me get what I needed for the case study I wanted to write. This experience spoiled me for years after.
The most challenging experience I’ve had writing case studies is for startups, and I’ll tell you why. One reason is that startups can’t garner the attention for a case study like when I was writing them for publications. The startup is the primary beneficiary of the case study. There’s no real benefit for the startup’s client for participating in the writing of a case study. Thus, it’s important that the startup’s sales, sales engineering, and marketing team develop positive relationships with the customer and do whatever they can on their side to make the interview, writing, review, and publishing of the case study as straightforward as possible on the customer project they’re profiling in the case study.
Another challenging experience I’ve had with case studies is writing case studies for federal government projects. Among the many rules that surround government contracting is one that says that a government agency can’t show preference to one vendor over another. Government agency approval processes for case studies can be long and arduous if the best of you can get you, a federal agency client, to play in the first place.
Then again, the evolving nature of cybersecurity is also changing how deep you can go with a case study, which certainly impacts how much a client you want to profile in a case study. It’s not prudent to tell your whole security story in a case study that your potential attackers can find during a Google search and use the information against you during an attack.
Case studies — like the rest of marketing collateral — invite mixed expectations from corporate executives, stakeholders, and others on the author’s side that don’t click with the reality of the situation. Take, for example, a security startup writing a case study about an implementation at a mid to large-sized customer. The client is somewhat cooperative with the case study but won’t part with the numbers and metrics that would satiate the executives and stakeholders.
Experience tells me that everybody involved in the case study, starting with the writer, the executives, and stakeholders over the writer and the client, needs to adjust their expectations in the current day and age. If numbers and metrics are off the table and unavailable, then look to tell a story about the case study about process and level of service. Look for other stories that’ll show you left the customer better than before the start of your project.
Will Kelly is a product marketer and writer focused on DevOps and the cloud. His technology interests include enterprise mobility, collaboration tools, and remote work. He has written for TechTarget, Opensource.com, InfoQ, and others. Follow him on Twitter: @willkelly.