How to write a great developer case study

Social proof is a critical component of any go-to-market plan. As you grow, you will accumulate customers you want to tell the world about. After all, most potential customers are only interested in products after people like them give the thumbs-up.

The traditional approach is to write a case study. A case study is a glossy, “print-ready” or well-designed artifact that generally follows this outline:

1. Headline with bottom line business benefit
2. Quote from an executive at the customer
3. The customer’s company and its mission
4. The problem the customer was facing (before)
5. Why your company was able to address that problem (after)
6. Why the customer chose your company, especially if it was a bake-off with one of your biggest competitors
7. Metrics and other information about how the customer has succeeded

Case studies can still be somewhat technical but have a very strong business value component. The tone and content are aimed at a decision-maker audience vs. an individual developer audience.

In the past, the case study was a beautiful PDF file, which sales reps loved to attach and share. Increasingly, the case study is more long-form and hosted on your website. It still has a strong business value component, but the layout of a PDF file no longer constrains you and you can get into more detail.

There are many advantages to case studies:

1. They are wonderful pieces of collateral for your sales team
2. They typically include a quote from a high-level executive and are vetted by the company’s PR and legal teams
3. They are typically from very well-known companies whose logos would be very effective additions to your website
4. They represent an important milestone in your relationship with the customer. They’re willing to put their reputation alongside yours and vouch for you.

The Developer Q&A: technical case studies for technical products

Many of the products I’ve worked on have been very technical. Presumably, since you subscribe to this blog, your products are also pretty technical. In the early stages, the adoption curve for these types of products starts with individual developers who see value in your technology, adopt it and test it under real-world conditions, and then make the case on your behalf to invest further in the product and increase spending on it. Sometimes, a decision maker is intrigued by your product and assigns a technical person or team to complete a thorough evaluation.

Because a technical person is almost always involved at some point in the ultimate decision to select a technical product, I’ve always believed that case studies are necessary but not sufficient. You can and should do more if your product is aimed at a technical audience.

To accommodate both the business decision maker and the technical evaluator, you must build additional artifacts, adjusting your tone and content for an individual developer audience.

This is where the Developer Q&A comes in. Sometimes, I affectionately refer to the Developer Q&A as the “B-Side case study,” the technical version of the business case for selecting your product. Where case studies are published on the main website, with beautiful graphics and imagery, I often publish Developer Q&As on my company blog as a transcript of an interview.

The style of Developer Q&A that I love to produce is simple. I send over a bunch of questions to our technical advocate within the company. They take the time to write their responses, and apart from some light editing for grammar, consistency, and links, I publish the “interview” as-is. You could also do a Zoom interview with your technical advocate and publish the transcript (with an embedded video of the recorded interview.)

The technical interview then becomes the basis for not only the Developer Q&A but also the full case study and other materials.

The Case Study Package: pulling it all together

The bottom line is this: once you’ve secured permission from one of your customers to do a case study, you need to maximize your opportunity. Case studies don’t come along often, after all. This is why I like to put together a full case study “package.” You will produce all of this material simultaneously and get approval for the whole package:

1. The business decision maker case study
2. A well-produced video case study featuring the customer. (here’s a good example from WalkMe) Often, this will require securing a video crew and permission to interview the customer. If you’ve got the budget, a handful of these are worth it.
3. A Developer Q&A on your blog
4. A recorded Zoom interview of the Developer Q&A
5. 1-3 approved quotes for use in multiple places: press releases, blog posts, and your website or other collateral

One technical interview plus a handful of emails to executives to secure quotes and you’re able to produce a full package of materials that establish your company as a force to be reckoned with.

That sounds like a highly optimized use of time and resources.

As an aside…

I’m going to let you in on one of my least likable traits: I love puns. I have a friend from my time living in Seattle who loved to throw a random animal into our conversations, which would then trigger me into unleashing a torrent of puns. He’d mention a duck. I’d quack him up with an eggsplanation of why he should foot the bill for our bar tab.

For this reason, I love love love to insert puns into the case study headline.

I once wrote a case study of a shipping company that used one of my products. The headline I wrote: XYZ Shipping Company Floats to the Top with Amazon Web Services.

Don’t worry. I hate myself for this, too.