When I’m talking software innovation with people, few things — OK, no other things — drive me more crazy when I hear the phrase “we do what the customers ask for.” Sure, I’ve read and believe in The Inmates are Running the Asylum (thanks, Brandon!), but, to continue with today’s metaphor, I’ve worked in the sausage factory for many, many years.
The problem with doing what the customer wants is that in software, the customer rarely knows what they want. They may know it when they see it, and there’s certainly areas like compliance where they know the effect of what they want (obeying the law), but except for “dead” segments, I’d wager that customers rarely know what they want beyond “things to be better than they are today.”
Back-bone for The Straw-Man
I always get my leg stuck up the knee when I make broad statements like that, so allow me to pause to say: of course that’s not across the board. In fact, I’d say the “do what customers want”/”do what you think they need” split isn’t even 80/20, it’s probably more 50/50.
My problem is that most vendor-folks I talk with go whole-hog (in words at least) with the “do only what the customer wants.” Sure, you could say I’m straw manning here: “Silly, Coté, they’re saying ‘we do software that solves problems our customer has.'” But I would say, “hrm, not so much. And even then, are there new problems you solve for the customer that will make things better for them?” Wade through yesterday’s post along these lines for more background.
Ultimately, my rebuttal is even more crass: what customers want is the stuff they already bought to “work.” Rails on ABAP anyone?
To their credit, as I’ve been reading through the SAP’s Enterprise SOA, they’re telling that story well…if you upgrade your ecosystem to NetWeaver. And don’t read into that statement that I’m vetting the technology behind the story, I’m just saying the text reads good ;>
“That’s why they sent me. I am expert.”
Tim Lister’s talk from Agile 2006 touches on this point, among many others. He has two anecdotes (granted, from corporate development, not so much packaged/ISV type models) along those lines (crudely summarized here, not exact quotes):
I was working in a hospital, and there were the nurses — great people who were no-nonsense — and then the “CMO,” the Chief Medical Officer. The CMO sent out a two line email that launched a 15 month project. In one meeting, we asked him for details on this or that aspect, and his response was quick, “I’m an executive! I don’t answer questions.”
Another time, I was working for a female boss, and I was asking her for guidance with a technical project. She shot back, “I’m not your mom! You’re the tech people, figure it out!”
Now, I’m hijacking that first anecdote for my own purposes — clearly, the CMO was being a bad — but the point is this: there’s only so much pestering your customers will put up with. They hire you to come up with the software and, I’d argue, in many cases to figure out what software will make their businesses and lives better.
Tags: innovation, productmarketing, rails, sap, software
In my experience, the customer will only know what they DON'T want after they've seen something to help them crystallise their thinking – which is where Agile methodologies are valuable in getting something in front of the client and eliciting rapid feedback.
It reminds me of the Henry Ford quote I use all the time. "If I'd asked my customers what they wanted, they'd have said a faster horse."
Ric: yes, that's an excellent correction on the point. Yuh!
Robert: Is there anything Ford didn't say?
I believe there's a big difference in what the customer wants and what the customer needs, and there lies the problem.
Hi, just stumbled upon your blog. Enjoying it so far and just thought I'd throw a comment at this.
My experience is that you cannot simply make decisions for the customer. You have to a very good job of explaining the situation for them and have them realise themselves the better solution. Also I have on numerous accounts hit a wall of company policy issues which makes me, as a consultant, incapable of persuading a customer to go down a different path.
But then again, I've just recently seen an IT consultant sell a customer a system architecture which they basically didn't need. The result was a price tag much over the budget and a very ill functioning system. So your making the decisions on behalf of the customer also means that you have to be completely into the customers demands. This might be a bit basic, but I have encountered some situations where the customer does not only know exactly was he or she wants (usually the case) but also is withholding some information (not on purpose) that might be very relevant.