When visiting the software forums where all the developers and mISVs hang out, you'll often read about how to write and about "features vs. benefits".
The thing is, visitors want to know, "What is this going to do for me?" Or, "What's in it for me?" This question is answered by telling them about the benefits of your product. It is not answered by writing a list of features.
So how do you get out of the "features writing rut", and get into the "benefits writing clear"?
Remember that a benefit is something that solves a pain point. A pain point is a common source of frustration for people. It is why you originally created your product. You saw pain that people were going through, and you came up with a solution to that pain. Below, I talk about benefits, but you can substitute in "a solution to a pain point" anytime you read "a benefit". i.e. A benefit is the opposite of a pain point.
Well, there are 3 basic approaches that you can take:
- Start from nothing to write about the benefits.
- Start from features to write about the benefits.
- Start from pain points to write about the solutions (benefits).
The last one there, starting from pain points, is basically the reverse process of the first. In it, you brainstorm about pain, then brainstorm about "what if I could...", then relate that to your product. It's taking your start from a negative instead of starting from a positive. This can work better for some people, depending on how you approach things.
Chances are that if you're a developer, you're going to want to start from the features to write. That's the wrong thing to do most likely. You'll probably fare better if you start from nothing. So, let's start there. From nothing.
From Nothing
In the "from nothing" approach, the first thing you need to do is to step back and start asking questions about your product.
Step 1: What is it?
Your first question should be "What is it?" If you take more than 1 sentence to answer that, you've failed. Start over. Don't worry about short sentences at this stage. That's next. You can rephrase this question to be, "What will it let me do?" or "What will it help me with?" or anything similar. The point is to get to the core of the product. Think of this as just a brainstorming mess that you will clean up later in stage 2.
Here are a few examples describing GDT:
- It is a program to help musicians learn new songs by practising slower.
- It is a program to help musicians learn new music easier.
- It is a program to help musicians learn music in a different key.
- It is a program to help musicians learn new instruments.
From a different approach, we could get:
- It's a music slow-downer.
- It's a karaoke practise program.
- It's a music practise tool.
There are multiple approaches to take, but don't limit yourself to one. Write them all down (preferably on paper), then sort things out later. This is just for brainstorming right now.
Hopefully you get the idea though. Write something that describes the essence of your product.
Step 2: Can step 1 be shorter?
Your second question should be, "How can I answer the first question, but shorter?" This is a rinse and repeat phase where you constantly cut things out until you have the bare bones.
A helpful tactic here is to temporarily give your product a meaningful name that describes it. Instead of "X-Flame-O 510-K", which would be a great name for a flame thrower or perhaps a napalm bomb, something like, "ACME Rocket Skates" is more descriptive. Do not try to give your product a temporary name like major manufacturers do. Jaguar, Chanel, Gucci, Hugo Boss, Ford, Mercedes, Kellogs, The Coca-Cola Company, and other big manufacturers have massive branding campaigns and huge product launches. You can't do that, and coming up with cool names isn't the point of the exercise here. The point is to be decriptive.
Once you've got your descriptive name, or short descriptive sentence that tells what the product *IS*, then you're ready to begin listing benefits.
From the GDT examples above, these are shorter:
- It helps musicans learn new songs.
- It helps musicians learn instruments.
Those are pretty close to the above examples, but significantly shorter. The major thing there is using the active voice and focusing on cutting things out. But we can cut that down even further:
- Learn new songs and instruments easier.
The trick there is to turn the description into an order. TELL people what to do with your product. Pretend that you're the boss, and that your potential customers are your employees, and tell them what they're going to do next. Remember that you can only write 1 command.
Step 3: What'll it do for me?
So stage 3 in the "from nothing" approach is to begin telling people about, "what (short product name from above) is going to do for them." This is NOT, "what (short product name) does." Those two questions are worlds apart. If you tell people what it does, you fail. Start step 3 over again. Focus on the "FOR ME" part. Remember, people are selfish. Tell them what your product will do for them, and not how it does it. At this stage, you want to find multiple benefits. Your top #1 benefit you got from stage 1 and stage 2. Stage 3 is where you come up with more benefits.
Above we had a command, and looked at writing commands. In this stage, you expand on things from above. This is where you list multiple things that people are going to do. But, each of them must be directly related to your description from step 1 and 2.
So write down 20 orders or more. Make sure that they are not features of your software, but what those features do. Don't be afraid to write lots though. You can always sort through them and cut that list down by consolidating multiple commands into single commands.
At this stage, you will likely find that you are struggling to not write feature lists. To get around this, go back to your description, and think of different ways that the description is realized for people.
So, imagine from step 1 and 2 that you know that your product lets people do 'X'. There must be a few ways that it helps people do X. There must be a few broad techniques. That's what you are looking for. Write those down.
Remember to take out the feature and rephrase it as what people can do with it. Here is an example that I'll refine down to something better:
- Learn new music by slowing down and pitch shifting music.
"Slow down music" and "pitch shift music" are things that people can do, but how does that affect them? What do they mean? What's the practical upshot for them?
- Learn new music easier by practising at an easier speed.
That tells people how slowing down music will make their life easier.
- Learn new music easier by tuning music to your instrument instead of tuning your instrument for the music.
That describes one practical benefit of pitch shifting music. i.e. You don't need to tune your instrument for different songs. You can tune the song to your instrument.
Now, both of those were quite a bit longer than the original, "Learn new music by slowing down and pitch shifting music." That's OK. Remember, we're looking multiple benefits at this stage.
When you have your list of benefits, it's time to begin making them shorter.
Step 4: Write benefits in 7 words or less.
At this stage, you are now beginning to write benefit headings for your product. What you produce here will be used in your marketing materials as section headers or titles. Try to stick to 7 words or under. You should aim for 5 or less. Let those other 2 words be your "buffer" in case you need to express a difficult concept. If it takes more, then go back to stage 3 and break it down into a quicker, easier, more understandable benefit.
Gerunds, or "ing" forms, are OK sometimes, and very common for headings and titles, but they aren't very exciting, and the extra couple letters makes things longer, so stick to imperatives (commands, orders). Imperatives generate more excitement and are more likely to attract people's attention. Gerunds are passive and boring.
Going back to the "pitch shifting" example, I can write it out fairly long to start:
- Tune songs to your instrument instead of tuning your instrument to songs.
It's quite long, and there's still a gerund in there. You can get around a gerund in a longer sentence like that by cutting it in two.
- Tune songs to your instrument. Don't tune your instrument to songs.
That is a bit better, but it can still be shorter by combining the two sentences.
- Tune songs, not instruments.
So far I've managed to get that down to 4 words, which isn't too bad. It's short enough to be a heading.
Step 5: Rewrite your headings.
By this point, you've successfully filtered out the features, and come up with nice, short benefits, but you're not done. Now it's time to rewrite them entirely. At least 2 or 3x. No less. Try for 5 or more rewrites.
The reason you need to rewrite things is because it's quite likely that you didn't quite get things right by the end of stage 4. You forgot something. You chose the wrong words. You left out an important concept. Whatever it was, you about to do some "cleaning" now.
Taking my 4 word example from step 4, I can come up with a few new ways to express that idea.
- Transpose songs to play along.
- Never tune instruments to songs.
- Retune MP3s, not guitars.
- Tune songs, not guitars.
- Transpose songs, not guitars.
- Transpose songs, not your guitar.
- Don't down-tune guitars, up-tune music!
- Play in-key for any song.
- Play songs in-key.
There are so many ways to rewrite things that you should have no problems. Remember to pull out your thesaurus if you need a new word to work with.
Stick to a maximum of 7 words. More than that is too much. The fewer words, the better.
Step 6: Tell people how your heading applies to them.
So you've got some great headings that outline the benefits of your product. Fantastic! Now it's time to relate that to people in a concrete way.
One approach is to begin with a very short reiteration of the heading followed by "why" it is good for people.
Another approach is to begin with a pain point as a question and answer it with the heading.
Once you've got that sentence under your belt, you are free to being explaining a bit more about "how", which is the geeky feature-side that you're likely jonesing for. 
At this point, it's OK though. You've already explained to people about how their pain will go away with your solution/benefit.
Taking the pitch shifting example:
- Transpose your music, not your guitar (6 word heading)
- Hate down-tuning your guitar? Then don't. Up-tune your music instead! By pitch shifting MP3s, you can play Eb recordings in E, the same as your guitar! Never waste time again fiddling with tuners when you can learn new music by practising instead. Or if you like the heavy crunch of a down-tuned guitar, down-tune your music instead of up-tuning your guitar. Transposing music is 1-click easy with GDT. Click here to find out more.
The entire paragraph there focuses on the reader. "You" is either implicit or explicit 10x in there. It's all about "YOU"! And that's what people care about. They care about themselves, so make sure to address their needs and concerns. If you need to start writing a lot more, then most likely you need a page dedicated to the feature. There's nothing wrong with that, and I'd highly recommend it for SEO purposes. But it's that page where you can get into the nitty-gritty details and start blathering on about things. Don't try to do that where space is limited, like on your main product page.
So anyways, that's 1 of 3 different approaches to take. I hope that was useful for some people. I'm obviously writing with a heavy software-bent on things, and the examples are all for my own products, but it should be good enough to help you get a general idea about one way that you can stop writing about features, and start addressing people's pain points with the real benefits of your products.
Cheers,
Ryan