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.

Comments

• Anonymous
  October 16, 2006
  To be clear, I didn't write that comment; a commenter on my blog did. My point of view is much closer to Steve's than to the commenter's.

• Anonymous
  October 16, 2006
  Sorry for the confusion, Craig.  I'll reword to clarify.

• Anonymous
  October 19, 2006
  Sorry, but no serious DB developer has problem to use SQL and another language. LINQ could be a solution for programmers who don't understand DBs, and for managers hoping to cut on training expenses. The last thing I want is some piece of code trying to write my queries without no knowledge of the data but a a bunch of metadata and maybe statistics. AI is not up to this point, sorry, nor databases can be manipulated easily but with their own language, often inside the database itself, not in the middle tier or application tier.

• Anonymous
  October 19, 2006
  Data: I know what you say is true for a subset of database developers, but - on the other hand - the success of tools like Ruby on Rails provides pretty firm evidence that a market does existing for language integration of relational data.