Today's "Ask 37Signals: How do you say 'No'?" post is one of those times. One of the post comments linked to their book "Getting Real"--which I've skimmed on the insistence of my boss, but wasn't all that impressed with--and the fact that they throw away customer feature requests after reading them. The text in question, for context:
Forget Feature Requests
Let your customers remind you what's important
Customers want everything under the sun. They'll avalanche you with feature requests. Just check out our product forums; The feature request category always trumps the others by a wide margin.
We'll hear about "this little extra feature" or "this can't be hard" or "wouldn't it be easy to add this" or "it should take just a few seconds to put it in" or "if you added this I'd pay twice as much" and so on.
Of course we don't fault people for making requests. We encourage it and we want to hear what they have to say. Most everything we add to our products starts out as a customer request. But, as we mentioned before, your first response should be a no. So what do you do with all these requests that pour in? Where do you store them? How do you manage them? You don't. Just read them and then throw them away.
Yup, read them, throw them away, and forget them. It sounds blasphemous but the ones that are important will keep bubbling up anyway. Those are the only ones you need to remember. Those are the truly essential ones. Don't worry about tracking and saving each request that comes in. Let your customers be your memory. If it's really worth remembering, they'll remind you until you can't forget.
How did we come to this conclusion? When we first launched Basecamp we tracked every major feature request on a Basecamp to-do list. When a request was repeated by someone else we'd update the list with an extra hash mark (II or III or IIII, etc). We figured that one day we'd review this list and start working from the most requested features on down.
But the truth is we never looked at it again. We already knew what needed to be done next because our customers constantly reminded us by making the same requests over and over again. There was no need for a list or lots of analysis because it was all happening in real time. You can't forget what's important when you are reminded of it every day.
And one more thing: Just because x number of people request something, doesn't mean you have to include it. Sometimes it's better to just say no and maintain your vision for the product.
Don't misunderstand me here: Saying "No" properly is an important skill--one that too few develop. The Roman historian Tacitus contrasted brother-Caesars Titus and Domitian by relating that the former could make a friend with the way he said "No" whereas the latter could make an enemy by the way he said "Yes." Perhaps author of the essay above doesn't have a taste for Roman history or assumes that it's not applicable because it's soooo 2000 years ago an' all. But I don't consider it a wise attitude. Because 37Signals has basically told the people who have paid or would pay their bills that their feedback will be ignored unless the request (or the reader's perception of it--a distinction not to be taken lightly) is validated by some unquantified amount of apparently similar feedback. And to think that these people put down their stakes in the Midwest. That certainly wasn't the politeness ethic that I was raised with...
Apart from the flagrant violation of regional etiquette, I consider this a short-sighted and downright wasteful attitude for a few of logical reasons.
Reason #1: You're treating a customer interaction as if it's disposable. Someone took time from their day to inquire about your product. The employee who reads that feedback will likely be busy, and more likely to pigeonhole the request for an add-on to Bell #21 or Whistle #369. It may be a later customer interaction that could call that "pigeonholing" into question. But by that time, the original email is black-holed, and there's no way to double check. Unless you can guarantee that the same person (with an eidetic memory) reads every feature request throughout the entire life-cycle of your product, this seems like it's just asking for trouble.
Reason #2: It's not All About your bells and whistles, stupid. Obviously, it's 37Signals' business to run. My approach, on the other hand, would be to make view each request not through the lens of "To what feature does this request belong?" but "What does the customer (or potential customer) intend to do with that enhancement? A simple, courteous follow-up email to the customer asking how s/he would use the add-on accomplishes three things:
- It shows that you actually (gasp!) read the email.
- It engages the serious customers, b/c the time-wasters probably won't put themselves through the agony of translating self-reflection into words.
- It could be a shortcut to the front of the Next Big Thing's curve.
Now, I won't pretend to consider myself an "inventor," not by any stretch. But the hallmark of the inventor is the openness of her/his perception to what isn't being done, or at least not done very efficiently. And 37Signals' approach strikes me as high-handed, and their success as an increasing liability. That goes double if they choose to remain a relatively small ISV. Because sooner or later your own itches will run out. The line between "Don't need to do" and "Don't feel like doing" blurs. At that point, it's far, far too easy to filter all input through the sieve of a "vision" which becomes more hide-bound and self-serving by the day.
Me, I prefer to leave the "visions" to the blessed lunatics of this world. That the world is generally a harsh place for such blessedness is not a recommendation to emulate them. As I mentioned, I have no real need of what 37Signals is peddling. But I do have some discretionary spending power at work as well as at home, and my itches are peripatetic. Their attitude has made it less likely that I will throw money--mine or, better yet, someone else's--at them.
