May 7, 2008

The Short List

One of the challenges with any product is how to handle “bad” feature requests. Not every user idea is a diamond in the rough. Sometimes it’s as simple as being very specific to that company/department/users use of the product. Sometimes what they want is counter to what the product is really designed to do. It may just be really, really hard. Or it just may be, in your opinion, a wrong-headed idea. In any of these cases, what do you do with that idea and how do you convey that back to the user? The typical approach is to respond with something along the lines of “Your input really matters. Thanks for the idea. We’ll definitely consider it.” And that makes everyone feel good, but it’s not entirely truthful to anyone. In the book Nuts!, by Kevin and Jackie Freiberg, about the success of the Southwest airline, the authors tell the story of a frequent complainer. At some point one of the person's letters found its way onto Herb Kelleher’s desk, who was CEO at the time. He wrote a letter in reply of: “Dear Mrs. Crabapple, We will miss you. Love, Herb.” That works somewhat best when you are the president of the company, but none the less I think letting people know that their suggestion is not likely to be incorporated is a reasonable way to treat people. The real downside is it invites a debate. User “You're missing the point, this feature would rock.” Developer “I’m not sure you appreciate the level of effort and small return on investment in supporting the TRS-80 with a Surround Client.” User “Oh, I see. You're just lazy.” Another common response is, “Well then, just make it user configurable”. The issue with that is, it takes even more work. You have to code the feature, the interface to turn it on and off, test everything under both scenarios, and then document all of it. In the end, I think it depends. Sometimes the right thing to do is say you'll consider it. Sometimes you should say no, and explain why. The important thing is to have a clear vision for the product and make sure your're tracking user requests (in TestTrack, of course) so that you can make sure the product is moving forward in a reasonable way. Feel free to comment, because you're input really matters. Thanks for the idea. I’ll definitely consider it.