How to Write Benefits
There is a great post from a while back on Roger Cauvin’s blog about benefits and communicating them effectively.
I’m currently going through a very similar process to what is mentioned here. I’m writing feature sets that will be incorporated into our product data sheets by our Technical Writer, Monica.
Now, I’m at a point where I’m getting into the nitty gritty details of these products I’m working with. Yes, I’m seven months in, and no, I’m not moving slow by any means — this stuff takes solid time. But, I digress.
In order to make sure that the product is being communicated effectively, a couple of key things have to be recognized:
1. You need standards
I don’t care who you are. It’s a lesson I learned early on, and one that will stick with me for the rest of my career. When you are managing product(s), you NEED to work to standards. Out-of-the-box, what’s in the package, post-shrinkwrap, whatever you want to call it. This becomes painfully clear when you have product literature and MarCom not speaking the same language.
Get on the bandwagon and make sure you are working towards standard messaging, a standard release checklist, etc… It builds expectation in the company that yes, training will happen, yes, these types of documents will be available, etc…
2. Writing feature sets is tricky
Make sure that you have a clear picture of what your lead-off feature will be. I like to group features, myself. I find it much more effective to have 4-5 features under a single heading, than creating a list of 27 features that all seem wayward. It’s hard on the eyes, and doesn’t get the value proposition of the product across to anyone reading the thing clearly enough.
3. Creating diagrams is tricky
If you manage software products, inevitably, you are going to come across a little tool called Visio. Make sure that you are rolling out standardized product architecture / flowchart diagrams to all product collateral. The last thing you want is a business stakeholder using different terms when talking to his tech folks about your stuff. Bad news bears. Try to make it as clear and concise as possible, while at the same time, sticking to the key features / value prop of the product itself.
4. Writing benefits is odd
Yes, odd. This brings my to my original linking to Roger’s post on writing benefits. The slide shown there communicates it perfectly. Practice, and make sure you have it right. Chances are, Sales will use the benefits as good talking points / lead-ins during their cycle to get buy-in. Features are important too, but some stakeholders may just pass them over as bullshit & fluff.
At the end of the day, the message has to come from everyone’s mouth in similar terminology and language. Product assets all have to communicate that, which means it needs to be deeply routed in your original product foundations.
October 30th, 2006 at 3:35 pm
There’s a really easy way to write benefits - ask a customer “what would happen for you / your business / your career if you had access to this capability / product / solution?”
I rank benefits based on how transformational they are to my market - are customers in pain, are there enough of them, and are they willing to spend money to make the pain go away? If the capability / product / solution does that, then it delivers a benefit that can be called out.
Ultimately, if we define our capabilities by the markets we serve, then everything we do should be of benefit. If we have to figure out if it is a benefit, then there’s some work that needs to be done. Fast.
October 30th, 2006 at 10:07 pm
Bob — this is awesome!
I openly admit my mistake and omission here. I hadn’t yet thought to link the benefits back to my identified market segments & their goals.
Wow; that’s for sure my biggest forehead slapping moment of the day, and hopefully the week. Makes so much sense…duh!
Thanks for the outstanding advice!