10 things to think about to improve software product descriptions

Print Friendly, PDF & Email
Rate this post

I’ve been back in a software product area since the beginning of June, and I’ve been spending a lot of time looking at product descriptions and literature. Not just IBM’s, mind you, but those of our competitors as well. This includes traditional, commercial “proprietary” software and commercial open source software.

Some of the descriptions of products in the industry are quite good, but many are pretty bad. They seem to range from “this is so high level that you have no idea what the product does” to “this has a long list of technical details that we hope impresses you even though you might not know how they could possibly help your business.”

I know, I know, different descriptions for different audiences. What you say to someone in development or the CTO should probably be different from what you say to the CIO and almost certainly different from what you say to the CFO. However, when there is only one, everyone suffers.

You need to know who your audience is (“segmentation”) and then shape what you say. Explicitly address your different audiences. It’s ok to say right at the beginning of each paragraph to whom you are speaking.

Here are a few suggestions, written from the perspective of a customer.

  1. First and foremost, the goal in acquiring software is to accomplish something. Tell me if your product will help me do that. This might be a simple yes or no.
  2. If I am a developer, tell me how easily your product will let me do what I wish and how it will make my life simpler and more productive. This new ease is in comparison to the previous version of your product as well as offerings from your competitors. Don’t overdo it on cute statements like “we make developers happy.”
  3. Match new or improved technical features to business value. “By doubling the amount of memory your application can use, you can now serve 25% more customers in the same amount of time and increase your revenue.”
  4. Regarding business value, stating how your software can help increase revenue (as above), improve security, increase availability, improve customer loyalty, decrease maintenance costs, and simplify integration with other parts of the business are all good things. If your software will help do none of these, why would I possibly install it?
  5. Don’t be overly simplistic about TCO (total cost of ownership) and TCA (total cost of acquisition). I can add up transactional, service, and support costs over 5 years as well as you can.
  6. Do, however, give me a way to compute the real return on investment from your software. Even if your TCA is $0, I may need to pay my people, your people, or a services integrator money to make it work for me. Give me examples based on real customers if possible.
  7. If I read your website and after 5 minutes I still don’t have the vaguest idea what your product does or why I might want to install it, you’ve failed. Start over.
  8. Separate promises of future functionality and value from what you can do right now. I’m interested in your roadmap, but I have problems to solve right now. Do not imply you can do more today than you can.
  9. Use graphics well to convey what your software does and the value it gives me. Don’t think that adding more tiny boxes with tinier print in them improves things. You are educating me about your offerings so I can make an intelligent and well informed decision. You are helping me make the case for acquiring your software within my organization.
  10. For emphasis: tell me how your software will make my organization better, more efficient, and more profitable, and how I can serve my customers better. If it will lead to great personal success for me, so much the better!