However, there are other, more subtle ways it can be too technical. Here are my top five to check.

1. It explains how before it explains why.

You might have seen this: a report that dives straight into frameworks, integrations, or architecture diagrams before explaining what matters to the reader.

It might seem helpful because it provides a wealth of information on the topic. However, if readers have to wade through half a page before discovering why it matters to them, then they might miss it.

Show the business context. What does it mean for the company? Why is it important? Which area of their business is it most relevant to? What do they need to do?

2. It assumes shared knowledge.

Internal teams read content and nod: “Of course, they’ll know what XDR or ELT means.” But does your business audience know what they mean?

This is the ‘Curse of Knowledge’, meaning that you know a topic so well that it’s difficult to explain it to others, who don’t know as much as you do. There’s nothing wrong with this; you’ve built up that knowledge over a long period of time.

One way around this is to add a sentence that turns technical shorthand into a straightforward explanation: “XDR brings together data from across systems, so threats are spotted faster.”

Your reader now knows what XDR means and what it does.

3. It treats every detail as equally important.

When everything is important, nothing stands out.

What are the most important details your reader needs to help them make a decision? Put these first, then use the rest to add more depth.

4. It reads like documentation, even when it’s not.

This can creep into business case studies and reports more often than you’d think. Phrases like ‘the solution leverages advanced capabilities to…’ sound professional but say nothing.

The fix here is to replace abstract words like ‘capabilities’ with what they do. Instead of ‘leverages automation,’ try ‘automates routine tasks so teams can focus on high-value work.’

5. It forgets the reader’s role.

You can get so caught up in making the case that you forget your audience. And it’s easier to do this than you might think.

You get on a roll with what you’re writing about, and you get so into the topic that the readers get left behind somewhere along the way.

One way to spot if this has happened is to read your report back. If it only describes what the system does, rather than what matters to the reader, it’ll need some work.

You don’t need to do a complete rewrite; you can change certain wording. If you say that your “platform provides”, try changing it to: “teams gain.” Now you’re talking to the reader again.

Final idea

Technical content isn’t “wrong”; it’s just written for a different audience with different needs. If you’re worried about losing technical depth, it can still be there. It just needs to be reshaped to work for your reader.

That’s when technical content becomes business clarity, and your case study or report works for the most important person, your reader.

I’m Sara Edlington, a marketing communications writer specialising in cybersecurity and AI.

The post Five signs your case study or report is too technical for business readers (even if it doesn’t look like it) appeared first on S and S Edlington Ltd .

It can seem like a daunting process; not to worry, you probably already have several potential sources, and for others, you may need to take a different approach to find them.

Here are a few ideas to help you.

Who has experienced a change worth talking about? You’re looking for a customer or company who has mentioned a change you helped bring about.

They’ll be able to explain:

• How they dealt with the issue
• What was difficult or frustrating about sorting it out
• What changed afterwards
• What they can do now which they couldn’t do before

These sources have an emotional connection to the problem you solved. I don’t mean this in a soap-opera-type way, more that they needed to find a solution to the issue, and that’s something your reader will understand and relate to.

Where can you find the right sources?

Good places to start are:

• Your own customers who have mentioned something to you or your team
• Your internal experts
• Specialist consultants
• Trade associations
• Conference speakers
• Experts quoted in other reports

If they can’t help with your report, they may well know someone who can help you, or they may be able to point you towards another source.

Another way to find sources is to ask yourself, who would benefit from the visibility?

You might have a customer who values being seen as an innovator or leader in their field. Or an author on your topic has recently published a book and would welcome being included in your report. Especially if you also mention their book.

A consultant may have written a well-received article in a professional publication and is looking for more opportunities to be recognised as an expert in their field. There are all sorts of possibilities, and these people can be keen to take part in a report because it gives them something they can use for their work or business.

Sources sorted

You now have several ways to find potential sources for your report. With any luck, this has inspired more ideas, making the tricky task of finding the right one a little bit easier.

Stakeholders and others often prefer to use well-known sources for reports; however, this can lead to other, equally good or even better sources being overlooked because they don’t fit someone else’s view of what’s ‘right’.

The next question is, how do you persuade them to take part? That’s a challenge worth its own post.

I’m Sara Edlington, a marketing communications writer specialising in cybersecurity and AI.

The post How to find the right source for your case study or report appeared first on S and S Edlington Ltd .

Here’s a quick example of what I mean. I interviewed a subject matter expert about a new type of enterprise software platform. One aspect of this that they talked about was an automation feature:

“This feature is designed to automate the process of extracting data from two legacy systems and integrating it into the platform, removing the need for manual data handling while ensuring the information is available within the system.”

There’s a lot of business value in this paragraph:

‘…extracting data from two legacy systems and integrating it into the platform.’ Extends the use and value of older systems as they don’t need to be replaced straight away, and reduces disruption.

‘…removing the need for manual data handling.’ Fewer errors, reduced manual work, so staff time is freed up for other things.

‘…ensuring the information is available within the system.’ Helps teams respond faster and provides better data visibility.

Lost in (technical) translation

The problem is that all this is lost if it stays in technical language or explanations. If you repeat it as it’s said to you, you could lose your reader, because they want to see how, in this case, a software platform will help their business.

When you do, as in the examples above, you’re showing the reader how they’ll have higher-quality data and information to work with; their staff will have more time for higher-value tasks; they’ll get the information they need quickly; and they won’t have to worry about their older systems.

We’re all techies in our own way.

You might be wondering whether this means technical experts don’t understand the business value of the technology they’re so familiar with.

They do; they word it in the language they use every day just as anyone does when they’re talking about a subject they know a lot about.

We know we’re talking about business value; it just doesn’t always come across that way to the reader or listener, who’s looking at this from a different perspective.

How to ‘decode’ technical speak for business readers

I’ve been asked a few times to teach technical experts how to ‘talk’ in business language, but I think that misses an important point. By asking the right questions of experts and specialists and listening carefully, you’ll ‘decode’ the business value you might otherwise have missed.

Another example to show what I mean, this time a cybersecurity expert talking about their company’s product:

“The platform continuously monitors authentication activity across the environment. It analyses login patterns, device information, user behaviour, and access requests in real time. If it detects something unusual, it can automatically apply additional verification steps or restrict access until the activity is validated.”

The less obvious business benefits:

‘…continuously monitors authentication activity across the environment.’ The value here is that the system is under constant guard.

There’s also another benefit for audits and compliance. The company has evidence of who accessed what, when, and can show how security controls are working.

‘…analyses login patterns, device information, user behaviour…’ It helps protect sensitive systems and information by adding an extra layer of security.

A stolen password alone won’t get an attacker in because the system checks that the behaviour matches the person.

‘…automatically apply additional verification steps.’ This has a business value for a team; they can spend less time on routine alerts. Another one is that staff and customers can access the system quickly and easily.

A second look can help you find even more value for your business reader

It’s always worth looking at something a few times, because there are often other aspects you might miss if you focus on the first one, understandably. And the more you find, the more choices you have, and that helps you create a strong case study or report.

We’ve covered a lot in these examples, and I realise it can look overwhelming, so you might worry you’ll miss something important. I worry about the same thing. To help, I use a three-step formula.

• The expert gives me the technical information.
• I listen to that and ask myself: ‘What changed?’
• Then ask: ‘What is the human/business or both consequence of this?’

Here’s an example to help explain how this works in practice.

The expert says: “It simplifies managing security policies across thousands of users.”

What changes? Team managers don’t need lots of specialist knowledge. They make fewer mistakes, and it’s quicker and easier to change policies as needed.

What’s the consequence for the people involved, the business, or both? It’s easier and less stressful for staff and team managers. And it helps keep the company secure.

What about AI?

I was once asked if you could create an AI that could do this; maybe you could. However, humans notice things that only another human would notice.

AI can be a big help, but the things you hear and see are what give your case study or report its edge – one human to another.

I’m Sara Edlington, a marketing communications writer specialising in cybersecurity and AI.

The post Lost in translation: turning tech-speak into business value for your case studies and reports appeared first on S and S Edlington Ltd .

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?

Follow the threads

When you read or listen back to your interview, what catches your attention?

Let’s say your case study or report is about using security platforms. Your expert mentions that during one implementation, an unexpected new risk emerged.

That’s something your reader will also be interested in, as they won’t have expected it either.

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.”

The theme here is trust. If trust was important to the business they’re talking about, 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 your report is on passwordless authentication services.

Your expert says that many companies find that staff are constantly changing passwords because they keep forgetting them, creating a security risk.

Further on, they mention that, in some cases, a new security risk emerged because staff didn’t like MFA (multi-factor authentication) and kept trying to find workarounds.

These two points give you two strong aspects of this topic to include in your report. Your reader will want to know about them 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 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 it adds depth to your case study or report.

Other places to look in the interview

Another way to find what you need is to review your interview timestamps and note which topics led to shorter or longer responses.

You might find that the interviewee spent 5 minutes on sector and market trends, 16 minutes on issues they’ve encountered, 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 specific themes, you have an idea of the issues that will also be important to your reader.

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 another real issue about your topic that other businesses have faced.

Bringing all this together: method one.

One way is to use how journalists structure their work:

Who. Who is affected or involved?

What. What happened? What was the issue?

Why. Why do companies choose these solutions?

Or Why. Why did they decide they needed this type of solution?

Taking the example of passwordless authentication.

Who? Medium-sized companies, with small IT teams

What? The different security methods they’d tried, the increased security risks, and their unhappy staff.

Why? They 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 method is to write a paragraph explaining the report 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 what needs to be said is something else.

For example, you might write:

“Medium-sized companies and zero-trust security solutions. They want to know how effective these are, what’s at stake if they don’t go the zero-trust route, the different needs of different groups (regulators, suppliers, investors, stakeholders) and how to address them, and what they need to do.

Then, when you read it back, you notice a theme about the impact of zero trust on the company, its stakeholders, and so on.

Is there something more there? You go back through your notes and find that your expert has said that implementing zero trust can be beneficial for customer and investor relations because, if a company uses zero trust, it improves its security posture.

Now you can see that focusing the report on these aspects of zero-trust is what your readers will be most interested in.

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 an interview, you can still use it, as you’ll have a ‘back pocket’ set of tips and ideas to draw on.

I’m Sara Edlington, a marketing communications writer specialising in cybersecurity and AI.

The post What to do when an interview falls short appeared first on S and S Edlington Ltd .

Either way, readers like them and they help ‘build the case’ you’re making in your report to them.

You’ve probably read a few tech case studies and found that they can read like press releases with quotes inserted.

As a former B2B tech reporter, I read hundreds of case studies. Most were so-so, but occasionally, one would stand out because it:

Showed what really happened during implementation (including the problems, yes, really).

Included real insights.

Told a story about a problem a business had, what they did to solve it and what it meant for the company.

Gave behind-the-scenes details that readers want to know, like the unexpected benefit or how you helped keep staff on board with big changes.

These were the case studies I’d use. I’d get in touch to ask if I could interview the customer and the company for my article, or keep them for future round-ups.

On a side note, if you’re sending your reports to the media, case studies are always popular, as magazine readers like to find out what happened in real life.

A quick example of what I mean about including real insights. Let’s say this was the original:

“When we saw our old system working with the new software, we knew it was going to make a difference to our customer service.”

And then someone wanted it changed to something more ‘fitting’:

“We were highly impressed by the interface that connected these applications.”

The first one sounds like you having a chat with the business; the second sounds like you’re reading a particularly poor prompted AI version of the quote.

The most valuable part of a case study isn’t always the outcome

Your readers are trying to picture how the implications of your report could play out in their business.

It’s like asking a friend how they solved a problem. You’d listen to their experiences, why they did what they did, and ask how it’s working for them now.

Which is why all of the above matters, because it helps answer those sorts of questions.

A case study that only talks about “seamless implementation” and “easier regulatory compliance” doesn’t help your reader. They know implementations aren’t seamless and they also know that compliance is rarely easy.

Once you’ve found a source for your case study (I wrote a post on how to find the right sources), here are a few questions you can ask to gather the information you need.

• Why did they choose this approach?
• What nearly stopped them?
• What did they underestimate?
• What surprised them?
• What would they do differently?

These questions are also the sort of questions your readers will be asking themselves.

The case studies that work.

The most effective case studies I’ve seen don’t hide the rough edges. They acknowledge challenges, issues and problems and show how they were solved.

They also fit into the narrative of your report by adding to it, bringing a new perspective and real-world experience which readers will find useful and valuable. It’s a way for you to ‘walk the talk’ of how the issues in your report could affect their business.

How can you make your case study more credible? Give your readers the customer’s real story.

I’m Sara Edlington, a marketing communications writer specialising in cybersecurity and AI.

The post How to create case studies for your reports appeared first on S and S Edlington Ltd .