{"id":798,"date":"2014-06-13T16:41:16","date_gmt":"2014-06-13T16:41:16","guid":{"rendered":"https:\/\/thatwhitepaperguy.com\/?p=798"},"modified":"2021-01-26T12:54:16","modified_gmt":"2021-01-26T17:54:16","slug":"how-to-write-a-case-study-for-beta-software","status":"publish","type":"post","link":"https:\/\/thatwhitepaperguy.com\/how-to-write-a-case-study-for-beta-software\/","title":{"rendered":"How to write a case study for beta software"},"content":{"rendered":"
I was a little stumped… since that product could take 12 months to generate a ROI.<\/strong><\/p>\n But as one crusty old newspaper editor used to say to any reporter chasing a\u00a0story: “The paper can’t print excuses!”<\/p>\n I didn’t want to make excuses. So I put out the question on LinkedIn.\u00a0In a couple days, I got 10 thoughtful replies from some fellow tech copywriters.<\/p>\n Their answers stack up like this:<\/p>\n Here’s some more details on each approach.<\/p>\n Tactic #1: Write about the projected benefits<\/strong><\/p>\n These could be “soft” benefits as well: better employee morale, improved on-site safety, or whatever.<\/p>\n Here’s a step-by-step plan from one writer:<\/p>\n A. Identify the\u00a0functional benefits<\/strong>\u00a0of the product vs the status quo: Why it’s better, faster or easier than the way things are done now.<\/p>\n B. Identify the key\u00a0financial benefits<\/strong>\u00a0of the product: How much savings, new revenue or whatever it’s expected to generate.<\/p>\n C.\u00a0Set goals for the beta<\/strong>\u00a0and communicate these to testers.<\/p>\n D.\u00a0Write the story for what it is<\/strong>: You’re doing a beta test to help measure these benefits for customers.<\/p>\n “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.<\/p>\n “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.”<\/p>\n Tactic #2: Write about the client’s current pain<\/strong><\/p>\n “The best approach is to interview customers about what problems they think the software will solve,” suggested one writer.<\/p>\n “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.”<\/p>\n “Focus on the problem your software will solve, the pain that will vanish when people use your software,” agreed another.<\/p>\n Tactic #3: Say the product is still in beta<\/strong><\/p>\n “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.<\/p>\n “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.<\/p>\n She lists her favorite questions to ask in this situation:<\/p>\n The purpose of beta testing is not just to work the bugs out, but to see what innovative customers do with a product.<\/p>\n Publishing these stories can help a client attract more early adopters and start to make the larger market aware of the software.<\/p>\n Tactic #4: Postpone the story<\/strong><\/p>\n In the end, my client decided to give it some more time. In this case, that was probably the best decision.<\/p>\n LinkedIn: an under-used resource<\/strong><\/p>\n I certainly learned something from the wisdom of my peers. A related lesson is not to overlook LinkedIn as a source of professional expertise.<\/p>\n\n
\n