Do what I want, not what I ask

As I was surfing my comments, I found an interesting comment from a reader of Craig Stuntz's blog regarding my recent series on VC++ strategy:

"I always like how companies dismiss what customers are asking for by claiming it isn't what customers are asking for."

I certainly hope my comments do not come off that way.  Obviously, I wouldn't ask for feedback if I weren't interested in hearing it.  However, my blog is a place were frank conversations between Microsoft and customers will occur.  If I disagree with a comment, I might actually say that.  I might even offer unsolicited personal opinions on things.  This is not a corporate policy forum; it's a blog.  If you would rather hear: "Thank you for your input. Your feedback is important to us. We will consider your suggestion for a future version. Blah blah blah. " Then you're in the wrong place.

But I did have a point here.  If you work in software and work with customers, then you probably know that customers don't always ask for what they really need.  Customers tend to ask for improvements in terms of features rather than in terms of the problems they're trying to solve.  It takes a bit more effort to take the conversation from features to scenarios or solutions.  For example, few customers asked Anders and the C# team for LINQ as a set of features.  However, the C# team was in tune with the customer problems caused by having to use 2 languages and do coding in two places in order to manage data from a C# program.  Nobody asked for an IDE way back when, but Borland understood the customer problems of having to manage separate editors, debuggers, and compilers.  Nobody asked for a car, but some people understood that horses were slow, jarring, and had to make extended stops to eat and rest.  It's the truly successful product that can understand the broad scope of problems their customers need to solve and bake those things into their long-term roadmap, resisting the temptation to simply throw in a new bag o' features with every release.

There are, of course, some cases where -- even if you ask for something perfectly in the form of a scenario -- we still won't do it.  The people that manage a product should not only be good at listening to customers but they should also have vision about what they want their product to be.  Sometimes this vision will clash with that of some segment of customers (it's impossible to please all the customers all the time).  When that happens, those customers will sometimes be unhappy about it.  Sometimes those managers will be wrong, but hopefully they're right more often than not.

Tying this back to VC++ strategy, what I really am hoping to do is better understand the kinds of problems you want to solve and the scenarios you need to enable.  Your detailed feature feedback is interesting and informative but much less actionable for me.