How to write a case study for beta software
A client once asked for a customer story on some software just going into beta.
I was a little stumped… since that product could take 12 months to generate a ROI.
But as one crusty old newspaper editor used to say to any reporter chasing a story: “The paper can’t print excuses!”
I didn’t want to make excuses. So I put out the question on LinkedIn. In a couple days, I got 10 thoughtful replies from some fellow tech copywriters.
Their answers stack up like this:
- Six said write about the projected benefits
- Four said write about the client’s current pain
- A couple said admit the product is still in beta
Here’s some more details on each approach.
Tactic #1: Write about the projected benefits
These could be “soft” benefits as well: better employee morale, improved on-site safety, or whatever.
Here’s a step-by-step plan from one writer:
A. Identify the functional benefits of the product vs the status quo: Why it’s better, faster or easier than the way things are done now.
B. Identify the key financial benefits of the product: How much savings, new revenue or whatever it’s expected to generate.
C. Set goals for the beta and communicate these to testers.
D. Write the story for what it is: You’re doing a beta test to help measure these benefits for customers.
“ROI is only part of the story. I think of it as the final score,” said another writer. “The rest of the story is about how the software promises to change the game.
“Think of the story as the piece that runs on the sports page the day before the big game: It can set the stakes, profile the players, and get the fans engaged.”
Tactic #2: Write about the client’s current pain
“The best approach is to interview customers about what problems they think the software will solve,” suggested one writer.
“You’ll be able to use the customer’s pain points for drama, then explain how the software will solve them or what it does differently from competitors.”
“Focus on the problem your software will solve, the pain that will vanish when people use your software,” agreed another.
Tactic #3: Say the product is still in beta
“Beta just means you have some kinks to work out to make the product even better. If your beta software solves a problem, your product will be a success!” said another reply.
“I’m in your shoes frequently when the customer I’m interviewing is in early rollout and can’t yet articulate any benefits,” confided another writer.
She lists her favorite questions to ask in this situation:
- With everything else going on in your world, what made you consider joining a beta?
- What were your alternatives to doing the beta?
- What do you anticipate getting from this experiment?
The purpose of beta testing is not just to work the bugs out, but to see what innovative customers do with a product.
Publishing these stories can help a client attract more early adopters and start to make the larger market aware of the software.
Tactic #4: Postpone the story
In the end, my client decided to give it some more time. In this case, that was probably the best decision.
LinkedIn: an under-used resource
I certainly learned something from the wisdom of my peers. A related lesson is not to overlook LinkedIn as a source of professional expertise.
Many people are caught up with Twitter and Facebook, which are undeniably fun.
But I believe LinkedIn is a more helpful, and under-used, resource for professional writers.
Note that I didn’t quote anyone by name in this article, since this is an amalgam of comments from 10 different sources.
But I did create a summary of everyone’s answers and sent it back to everyone who replied.
You know who you are. Thank you!
Want to hear whenever there’s a fresh article on this site? Subscribe here to stay in the know on long-form content. From time to time, we’ll also send you word about some great new resource or training. And you can unsubscribe any time.