You know that sinking feeling you get when you read through a customer interview transcript and think: “Oh dear.”
Or maybe something a bit stronger.
There can be any number of reasons why you didn’t get what you wanted or needed, so what can you do?
Here are a few tried and tested ideas:
Follow the threads
When you read or listen back to your case study interview, what catches your attention?
Let’s say your case study is about your customer using a security platform. They mention that during implementation, an unexpected new risk emerged.
That’s something your reader will also be interested in, as they won’t have expected it either. Additionally, it’s also a ‘hidden benefit’ of using your platform, which is always a bonus.
Look for patterns as well. Did something keep getting mentioned in different ways? Maybe it was comments about how staff used the previous system.
Repeated themes can be another good source. Let’s say you hear or read comments like these:
“We needed to get buy-in from the relevant department managers.”
“Training people was important.”
“Staff were nervous about the change in platform.”
“We organised regular meetings, updates through our messaging channels and kept everyone up to date with what was happening.”
“We gathered feedback during the process.”
The theme here is trust. If trust was important to your customer, it’s likely to be important to your reader as well.
Search for the story
A story involves people, a change or both.
Often, the two of these come together. Let’s say you have a passwordless authentication product that your customer is using.
Your customer says that staff were constantly changing passwords because they kept forgetting them, creating a security risk.
Further on, they mention that a new security risk appeared as staff didn’t like the new MFA (multi-factor authentication) and kept trying to find workarounds.
These three points provide the structure for a good case study story.
The two failed attempts (passwords and MFA), the increased security risks, the frustrated and fed-up staff, and now another change: passwordless authentication, and how that worked for both the company and its staff.
Your reader will want to know what happened because they may be facing the same issues.
Even if you don’t have much more than a few comments, you can add relevant information, use the comments as quotes, add statistics and metrics, and bring in a comment or two from your own team.
Find supporting materials
If you’ve gone through your transcript and found something/s that will work with a bit of extra information, the good news is you can probably find what you need.
Good places to search include press releases, media kits, reports, white papers, product sheets, analyst reports, the company’s website and social media, discussion forums and so on.
You could also look outside the company. Do background research; use sources such as specialist research databases and sector-specific reports.
If you quote from these, you will need to credit the source and get their permission. It’s worth the extra work, as few case studies do this, and it adds depth to your case study.
Other places to look in the interview
Another way to find what you need is to look at the timestamps of your interview and note down which topics led to shorter or longer timestamps.
You might find the interviewee spent 5 minutes on market trends, 16 minutes on their staff and your product/service, and 21 minutes on regulatory issues.
These might not be in neat blocks of time, or you might be lucky, and they are. Either way, by gathering together specific themes, you can get a good idea of what’s important to the customer.
Listen for emotional wording. By this, I mean phrases like ‘limited time,’ ‘too many requests,’ ‘staff overwhelm,’ ‘problems with something,’ ‘pressure to do more,’ and so on. These emotional clues can also help you piece together a real issue they were facing.
Bringing all this together. Method One.
OK, how do you make sense of what you’ve found? Here are two ways.
One way is to use a journalistic format to find a story.
- Who. Who is affected or involved?
- What. What happened? What was the issue?
- Why. Why did they choose your product/service?
- Or Why. Why did they decide they needed this type of product/service?
Taking the example of passwordless authentication.
Who? The customer’s company, its staff, and security teams
What? The different security methods they’d tried, the increased security risks, and their unhappy staff.
Why? The customer needed to find a way to keep accounts secure while providing a process that staff could easily use.
Bringing it all together. Method Two.
The second is to write a paragraph explaining the case study to yourself. It doesn’t need to be long or detailed.
Using this method can help you find the focus you want. Sometimes, you write this and then realise the real story is something else.
For example, you might write:
“Our customer needed a zero-day security solution. They were concerned about how this could be implemented, given their legacy systems, and several teams were worried about how they would be expected to use the new system. We found an unexpected benefit during implementation and discovered that trust was important to the customer and their team.”
Then, when you read it back, you notice you mentioned trust. Is there a bigger story there? When you go back to your notes, you can see mentions of getting team buy-in, training, nervous staff, and regular meetings to update everyone.
With such a big change, keeping staff on board, listening to their concerns, providing them with the right training, and showing how you helped the company manage it gives you a great story and case study.
The unexpected benefit fits in nicely with this, as it’s part of the process, and it would make a good sidebar.
A final bonus tip
If you can, leave the transcript or recording for a day or so and then come back to it. You’ll often find your mind has made connections you didn’t see before, and they could be just what you need.
The next time you’re stuck with a case study interview, you can still use it, as you’ll have a ‘back pocket’ set of tips and ideas you can use.
I’m Sara Edlington, a B2B technology case study writer.
With twenty years in tech journalism behind me (The Times, The Independent, StrategicRISK Europe), now I help B2B technology companies turn customer success into stories that prospects recognise themselves in. If your customers have a story worth telling, either get in touch or find out how I can help you.