4 ms·

#3 is bad advice. It's a good observation, but really you should try to identify your audience and be prepared to go in either direction. Some people will be

by Goladus 18y ago

#3 is bad advice. It's a good observation, but really you should try to identify your audience and be prepared to go in either direction. Some people will be turned off immediately if you presume to know how something will benefit them.

tptacek 18y ago
Selling features instead of benefits is one of the all-time classic marketing mistakes. He didn't just make that up. If you don't know how to describe the benefit of a feature in a way that is convincing to a technical audience, you either don't understand the feature well enough, or you shouldn't have the feature.
- Goladus 18y ago
  Which is the classic mistake, "Selling features instead of benefits" or "Selling features when you should be selling benefits?" Honestly, trying to sum it up with only the two words "feature" and "benefit" is an enormous mistake as well. Feature: My software uses closures. (Who cares?) Benefit: My software will save you tons of money. (Bullshit, show me how.)
  - wensing 18y ago
    In "The Art of Project Management" (http://books.google.com/books?id=q1dJZv4Ycr8C&dq=the+art+of+project+managemente&pg=PP1&ots=_KlIPLlTqm&sig=b487NMWqqBfeCq_4-DWTROkJQrY&hl=en&sa=X&oi=book_result&resnum=1&ct=result http://books.google.com/books?id=q1dJZv4Ycr8C&dq=the+art...), Scott Berkun insists that a good PM write feature statements as they directly face the customer. "My software will save you tons of money" is a fine benefit statement, but the feature statement shouldn't be "My software uses closures" but rather "The order entry system will consist of a single screen." Perhaps this is because of some technical feat that only you can appreciate, but the feature statement wouldn't ever mention closures.
BrandonM 18y ago
If you don't know how the product will benefit the user, then what is the point of the product to begin with? For me, if I'm writing a program for myself, it's to solve a particular problem. If I think others might find it useful, I would mention what problem it solved for me. If the program has a particularly clever (efficient) algorithm, that would not be part of the sales pitch. Instead, I would note the effects of that algorithm, not the algorithm itself. It's the difference between, "This music player efficiently handles large music collections", and, "Only 10 songs are kept in memory at once, and indexing is done so that searches over the entire collection can be performed in constant time." The former tells the user all that is needed, while the latter is simply confusing and/or meaningless for a non-tech person. This is what I think #3 meant, and I thought it was great advice.
- Goladus 18y ago
  If you don't know how the product will benefit the user, then what is the point of the product to begin with? If you don't know how the product will benefit the user, it means either the product is worthless and you shouldn't be selling it, or it means that you don't know everything the product could be used for. It's the difference between, "This music player efficiently handles large music collections", and, "Only 10 songs are kept in memory at once, and indexing is done so that searches over the entire collection can be performed in constant time." My point is you need to identify your audience and know which to use. Even for your seemingly obvious example, it's possible there might be a user that actually does care about only 10 songs being in memory at once (and the impact that would cause to his particular needs), and may be suspicious if you try to say "oh yeah it efficiently handles large music collections." The result is that sometimes people have evolved bullshit detectors and when you try to sell things in terms that aren't precise enough they may assume you are a waste of time.
  - BrandonM 18y ago
    You make some good points, but I think they are a good argument for having a "technical description" (or something like that) page for those who might be interested. I still think that the description everyone sees should focus on the benefits to the user, because that's what the average user cares about. ...or it means that you don't know everything the product could be used for. Even for such an open-ended product, I would still say, "We developed this to solve X, but it offers other possibilities as well (link to feedback from users who have found other uses). Thanks to its extensibility, new functionality is being added all the time (link to top plugins)." All I'm really saying is that I agree with the author that it's worthwhile to re-frame the product description in terms that will immediately tell the average user that your product is worth their time or money.

by Goladus 18y ago

tptacek 18y ago

Selling features instead of benefits is one of the all-time classic marketing mistakes. He didn't just make that up. If you don't know how to describe the benefit of a feature in a way that is convincing to a technical audience, you either don't understand the feature well enough, or you shouldn't have the feature.

Goladus 18y ago
Which is the classic mistake, "Selling features instead of benefits" or "Selling features when you should be selling benefits?" Honestly, trying to sum it up with only the two words "feature" and "benefit" is an enormous mistake as well. Feature: My software uses closures. (Who cares?) Benefit: My software will save you tons of money. (Bullshit, show me how.)
- wensing 18y ago
  In "The Art of Project Management" (http://books.google.com/books?id=q1dJZv4Ycr8C&dq=the+art+of+project+managemente&pg=PP1&ots=_KlIPLlTqm&sig=b487NMWqqBfeCq_4-DWTROkJQrY&hl=en&sa=X&oi=book_result&resnum=1&ct=result http://books.google.com/books?id=q1dJZv4Ycr8C&dq=the+art...), Scott Berkun insists that a good PM write feature statements as they directly face the customer. "My software will save you tons of money" is a fine benefit statement, but the feature statement shouldn't be "My software uses closures" but rather "The order entry system will consist of a single screen." Perhaps this is because of some technical feat that only you can appreciate, but the feature statement wouldn't ever mention closures.

BrandonM 18y ago

If you don't know how the product will benefit the user, then what is the point of the product to begin with? For me, if I'm writing a program for myself, it's to solve a particular problem. If I think others might find it useful, I would mention what problem it solved for me. If the program has a particularly clever (efficient) algorithm, that would not be part of the sales pitch. Instead, I would note the effects of that algorithm, not the algorithm itself. It's the difference between, "This music player efficiently handles large music collections", and, "Only 10 songs are kept in memory at once, and indexing is done so that searches over the entire collection can be performed in constant time." The former tells the user all that is needed, while the latter is simply confusing and/or meaningless for a non-tech person. This is what I think #3 meant, and I thought it was great advice.

Goladus 18y ago
If you don't know how the product will benefit the user, then what is the point of the product to begin with? If you don't know how the product will benefit the user, it means either the product is worthless and you shouldn't be selling it, or it means that you don't know everything the product could be used for. It's the difference between, "This music player efficiently handles large music collections", and, "Only 10 songs are kept in memory at once, and indexing is done so that searches over the entire collection can be performed in constant time." My point is you need to identify your audience and know which to use. Even for your seemingly obvious example, it's possible there might be a user that actually does care about only 10 songs being in memory at once (and the impact that would cause to his particular needs), and may be suspicious if you try to say "oh yeah it efficiently handles large music collections." The result is that sometimes people have evolved bullshit detectors and when you try to sell things in terms that aren't precise enough they may assume you are a waste of time.
- BrandonM 18y ago
  You make some good points, but I think they are a good argument for having a "technical description" (or something like that) page for those who might be interested. I still think that the description everyone sees should focus on the benefits to the user, because that's what the average user cares about. ...or it means that you don't know everything the product could be used for. Even for such an open-ended product, I would still say, "We developed this to solve X, but it offers other possibilities as well (link to feedback from users who have found other uses). Thanks to its extensibility, new functionality is being added all the time (link to top plugins)." All I'm really saying is that I agree with the author that it's worthwhile to re-frame the product description in terms that will immediately tell the average user that your product is worth their time or money.