Break Points
Comment
robert.berger
phoenixdave
In addition, trying to engineer a product that fits every customer's requirement ...
Listening to Your Customers
Jack Ganssle
7/13/2010 2:42 AM EDT
The agile notion of constantly soliciting customer feedback and incorporating that input into a product is a brilliant way to produce prototypes. Prototypes, of course, are poorly-implemented skeletons that mirror a real product.
Their function is to quickly minimize risk, which arises from vague requirements, unknown science issues, or from other uncertainties. Prototypes are invaluable when needed but are not required for every product. Maybe not for most.
Engineering teams need to be sheltered from customers when developing the real product.
The customer might be an end-user, who, halfway through the engineering effort inexplicably asks for an MP3 add-on to the bottle opener. Or he could be a member of the sales team. My career has been haunted by these guys who invariably say “I can’t sell that piece of crap unless you add this feature.”
That statement is often correct, though it really illustrates the salesman’s own incompetence and is not a commentary about the viability of the product. Sales always asks for more and more. By tomorrow. So do customers.
Iterative elicitation of requirements, while sometimes necessary, is often a substitute for poor requirements analysis. Change does happen, of course, even on the most well-understood products, which is why companies have change control procedures.
Sam Walton was right when he said “There is only one boss. The customer. And he can fire everybody in the company from the chairman on down, simply by spending his money somewhere else.”
When a customer asks for a change, the only proper response is: “Mr. Customer, we love you. We’ll do anything you want. But there will be a cost, perhaps in schedule or dollars. Let me get back to you.”
Any other response will yield poor customer service as he’ll be disappointed by the suddenly-late product. Or angry when he discovers that the added MP3 player now means the bottle opener has to be charged every night.
Open communication is key, and that interaction is best if each party has time to think through the implications and the honesty to be clear about what the effect of the change will be on the product.
Change control adds friction to the process, a needed friction. Wild responsiveness is sometimes indistinguishable from chaos.
I once delivered a sailboat owned by a younger fellow who had grown up surrounded by electronics. He steered by the course painted on the GPS screen, and just could not understand when I complained that the GPS only knows where we were pointed, not where we want to go.
We zigged and zagged all the way down the Chesapeake Bay, getting to Norfolk eventually but much less efficiently than if steered by a steady hand reading the compass.
Set a course, follow it, and change it with forethought only if necessary.
Jack G. Ganssle is a lecturer and consultant on embedded development issues. He conducts seminars on embedded systems and helps companies with their embedded challenges. Contact him at jack@ganssle.com. His website is www.ganssle.com.
|
|
|
|
|
Yeef
7/14/2010 8:10 AM EDT
Bang-on blog. One other thing to consider that does make the situation chaotic is very often, the customer does not know what it wants.
Sign in to Reply
Duane Benson
7/14/2010 7:48 PM EDT
While, "the customer is always right" is an extremely important philosophy in business, it really is frequently next to useless without a good translation. Customers do tend to know what they want, but all too frequently don't have the proper vocabulary to articulate it in proper terms. Customer thoughts are further often tainted by a lack of knowledge of the cost benefit relationship for a specific product or feature. This is where a good product manager can save the day for everyone. That product manager can translate what the customer says into a language that an engineer can act on, and the good product manager will counter those customer needs with design and finance realities.
Sign in to Reply
D J Liu
7/15/2010 12:40 AM EDT
Remember what Henry Ford said about customers had wanted faster horses?
Sign in to Reply
WouterSimons_0710
7/15/2010 3:34 AM EDT
They did say that, but this proves he listened. He just listened really well and found a better solution that won't shit in your garage :P
Sign in to Reply
WouterSimons_0710
7/15/2010 3:33 AM EDT
I have tried writing a long comment explaining my reasoning three times now. This time I will try it short.
I do not agree with this blog. The new Agile methods work better than the traditional waterfall approach. The problem is not listening to your customer/sales person. It is interpreting what they say. Listen to the need underlying the question and use your expertise to conjure up the best possible answer to that need.
Sorry Jack, I love your site and read much of your work, but in this case I just do not agree with you at all.
Sign in to Reply
dagans
7/15/2010 9:55 AM EDT
A wise old entrepeneur once told me there were three things -- What the customer says he wants, What the customer really wants, and What the customer really needs. He says he wants a blue belt thingy, he really wants a faster conveyor belt, he really needs a way to move stuff faster, and maybe a cannon is the best way.
As the earlier reply noted, just cause they say they want faster horses doesn't mean that's what they really need.
Sign in to Reply
kdboyce
7/15/2010 5:43 PM EDT
.
Sign in to Reply
mary.sanders
7/15/2010 7:13 PM EDT
I couldn't agree more. You have to really read between the lines.
Sign in to Reply
DrOctavius
7/15/2010 11:07 PM EDT
Jack, I agree with you on this article, and Yeef is right that often the customer doesn't know what they really want.
On the other side is true that Agile or iterative development process are good to solve this issue.
Sign in to Reply
tfc
7/18/2010 12:55 AM EDT
The customer is always right reminds me of the adage, Never say never and always say sometimes. The real problem is not being able to say “No” to requests from your “superiors”. The salesman cannot say no to the customer, the engineer cannot say no to the salesman, and technology cannot say no to the engineer. But wait, technology can only do what is technically possible and not what we want and the engineer has to beat technology into submission and get as close to the requirements as possible to keep his job. So technology gives neither a yes or no. This leaves the engineer in the sweet spot of being the bottle neck in the great chain of being. It would be nice if the engineer could turn to the computer and say get it done or you’re fired and the computer would sweat over the problem. No, the buck stops at the engineer and technology can metaphorically thumb its nose at us as everyone else above wants results. This is where having a customer, manager, or salesman that knows the trade can make life a lot easier for everyone. But the reality is the engineer is mainly the one who understands the magnitude of the requirements and ends up being the wet towel. The more options customers or hiring managers have, the less they will tolerate anything but a yes answer to their requests. The more options an engineer has the more likely the engineer will succeed or be able to say no. The question is where do engineers sit on the x-axis of yes/no explains quite a lot.
Sign in to Reply
phoenixdave
7/18/2010 4:08 PM EDT
Not listening to your customers means you are ignoring one of the best usability and R&D resources you have. But trying to implement all of the changes and desires expressed by every customer creates a traffic jam of information to where the development process cannot proceed. The customers feedback should always be considered, but implementation should be limited to those ideas that best fit with the financial limitations, product goals, and market conditions at the time. If nothing else, customer feedback will provide new ideas and a starting point for building the next product.
Sign in to Reply
phoenixdave
7/18/2010 4:12 PM EDT
In addition, trying to engineer a product that fits every customer's requirement and desire may create a product that is unnecessarily complex, and may become less desirable to all potential customers.
Sign in to Reply
robert.berger
7/22/2010 1:39 AM EDT
Hi Jack,
What strikes me is your story with the compass and the GPS.
Without going much into detail Franklin Covey (http://www.franklincovey.com/) time management works similar to a compass and not so much like a GPS.
effectiveness vs. efficiency?
I you want to know more about it you might want to read http://www.amazon.com/Habits-Highly-Effective-People/dp/0671708635
Regards,
Robert
--
Robert Berger
Embedded Software Specialist
Reliable Embedded Systems
Consulting Training Engineering
Tel.: (+30) 697 593 3428
Fax.:(+30) 210 684 7881
URL: http://www.reliableembeddedsystems.com
Sign in to Reply