As always, it's about asking the right questions. Asking a customer what they want, and you'll come to the conclusion that they don't know what they want.
Customers know what they want to do. In your Henry Ford example, they know that they want to get from point A to point B faster.
Customers don't know the right way of implementing it. That's why they hired you to implement it for them. They don't know that there are better alternatives to "a faster horse" out there, or better alternatives to an access-based exchange-and-IIS-powered monster out there.
In the end, you have to find the right questions to ask to find out what the customer wants -- this takes skill, and it takes digging, and extracting the essence of their responses. It's part of your job to find out when a customer is telling you what they want, and when they tell you what they think they want, but are really describing the way they think something should be implemented.
Yep, good way of describing the difference.
Sometimes it's tough to tell the difference too - but once you have, you can move forward and get on with bringin the customer a solution that'll make you both happy :)
I think this article is somewhat misleading, because "make something people want" is said in the context of a product business, not a service business.
Of course your freelance business customers know what they want - otherwise they wouldn't pay you to build it. But product customers are an entirely different breed. They do have some idea what they want, so it's certainly still correct to go back to your customers to get feedback about your product, but it's misleading to equate these to service customers. With product customers, they won't tell you what they want until you spend much energy eliciting that feedback. It's not "simply a matter of translating business needs into technical jargon".
That's very true. My article was written with the service-industry in mind. That being said, the person I was talking to was also talking with the service industry in mind ;)
Still - you're quite correct that perhaps when creating "things" you may need a different appraoch - as I've never really worked in the "things" industry I can't comment. Anyone have any experience that would care to share their viewpoint?
5 comments
[ 2.5 ms ] story [ 21.8 ms ] threadI'm always reminded of that old Henry Ford quote whenever this topic comes up:
If I had asked my customers what they wanted, they’d have said a faster horse.
The beauty of this quote is not that customers don't know what they want, it's that they're saying what they want exactly by saying "faster horse".
Customers know what they want to do. In your Henry Ford example, they know that they want to get from point A to point B faster.
Customers don't know the right way of implementing it. That's why they hired you to implement it for them. They don't know that there are better alternatives to "a faster horse" out there, or better alternatives to an access-based exchange-and-IIS-powered monster out there.
In the end, you have to find the right questions to ask to find out what the customer wants -- this takes skill, and it takes digging, and extracting the essence of their responses. It's part of your job to find out when a customer is telling you what they want, and when they tell you what they think they want, but are really describing the way they think something should be implemented.
Figuring out the difference is the hard part.
Of course your freelance business customers know what they want - otherwise they wouldn't pay you to build it. But product customers are an entirely different breed. They do have some idea what they want, so it's certainly still correct to go back to your customers to get feedback about your product, but it's misleading to equate these to service customers. With product customers, they won't tell you what they want until you spend much energy eliciting that feedback. It's not "simply a matter of translating business needs into technical jargon".
Still - you're quite correct that perhaps when creating "things" you may need a different appraoch - as I've never really worked in the "things" industry I can't comment. Anyone have any experience that would care to share their viewpoint?