Category Archives: OLD-ALIGN (How To)

Stop Asking Customers What They Want

Aligning entails kindly listening to what customers say they want from you, and then not building the product they ask for.  You read that right.  Customers have all sorts of ideas of what they want you to create for them.  They may feel very strongly that they need a speedy widget with hovering capabilities.   Or, they may tell you they require an FPGA that closes timing at 1GHz on a 1024 bit data path with hundreds of 50Gbps transceivers and an enormous amount of random access memory.  Oh, and that FPGA must meet a power budget of under 10Watts.

>> Don’t ask customers for product specifications.  (These are not customer areas of expertise)

So, why don’t you go and build what the customer says they want?  Well, for one thing, it may be impossible to build.  More likely, it will be extremely expensive to implement.  Down this fool’s path, you may commit a tremendous amount of time, resources and materials only to deliver a product that the customer cannot afford.  Most of all, you kindly listen and then shelve customer product implementation recommendations because product definition is YOUR area of expertise, NOT the customer’s.

>> Do discover customer goals and challenges.  (These are customer areas of expertise).

Why even consult with customers? Because your expertise ends where theirs begins.  You may know how to specify or build a widget, but customers are the ultimate experts in what they want to do with such a widget.  They are intimately aware of their current experience with the widgets available today.  They can painstakingly describe the flurry of challenges they are trying to overcome.  Most importantly, they can tell you, better than any ‘expert’, just what it is they are trying to achieve in the future.  When aligning, uncover the topics in which customers are the experts: their goals and challenges.  You can  fill in the rest.

Heed the lesson of Homer.

Sometimes I hear a colleague ask a customer something like, “So, what do you want us to build for you?”  Immediately, my mind conjures up an image of ‘The Homer‘.

In Oh Brother, Where Art Thou? (episode 15,season 2 of the Simpsons), Homer J. Simpson discovers he has a half-brother named Herb, who owns a Detroit car company.  Herb decides that Homer perfectly encapsulates his target customer: the everyday-man.

Herb is sick and tired of turning out tired derivatives of the same car over and over.  He introduces Homer to his design team and tells them to come up with a car for the everyday-man.

Upon meeting, the design lead asks Homer, “So, uh, what kind of car would you like, Mr. Simpson?”  Homer knows nothing of on-board computers or what Homer calls rack and peanut steering.  Realizing Homer’s ineptness, the design team bulldozes ahead, totally ignoring Homer’s input. Exasperated, Herb puts Homer in charge, telling the designers to build exactly what Homer asks for.  (Doh!)

The car they produce is, of course, a hideous mess.  With a bubble cabin hood and enormous tail fins, the sticker price of $138,000 (in 2013 dollars), ‘The Homer’ is far too expensive for the everyday-man target customer.

What went wrong?   First of all, the design team missed a valuable opportunity to ask Homer about what he knows best: what he wants to do with the car (aka his goals and challenges) such as where he drives, what image he wants to project and whether he eats or drinks while driving.   Unfortunately, their hubris led them to turn a deaf ear. They presumed to know what Homer wanted and failed to ask any open-ended and Homer-focused questions.  The team failed to recognize where their expertise left off and where Homer’s began. They failed to discover goals and challenges from Homer, the customer, the expert. 

Next, when Homer was put in charge, the team blindly designed exactly what he specified, even though he clearly had no idea what he was asking for.  Homer had no expertise in car design nor in manufacturing, and yet, they implemented product designs from this non-expert.   The design team should have probed further.  By taking Homer so literally, the team failed to uncover why he wanted each item.  For example, when Homer said he wanted a bubble hood, perhaps what he was really asking for was better visibility in all directions.  When he said he wanted giant tail-fins, perhaps he was yearning for classic but edgy styling.   (Actually, this being Homer Simpson, I think he did literally want a bubble hood and tail fins, but you get the point).

If you are a product planner or design engineer, heed the Homer cautionary tale.  By the end of the story, Herb finds himself bankrupt and homeless.  Homer is disowned by the only half-brother he never knew.   Don’t let this happen to you!

For any topic, always remember who the expert is.   Don’t ask to hear what you know, or fish for confirmation of what you suspect.  Instead, put aside what you know and ask questions that probe the customer for what they are experts in: their roadmap, their goals and their challenges.   Only after gaining a very solid understanding of what the customer is trying to achieve should you ask specific questions about the bits and bytes of what they want.  Begin with uncovering goals & challenges and you’ll both be likely to stick to your areas of expertise and share reliable and useful information.

RECOMMENDATION: stay tuned for more posts on how to skillfully align with customers and,  check out ‘The Homer‘.

Aligning With Customers: 3 Pitfalls to Avoid

Why visit customers?  For product planners, a common reason is to gather product requirements.   Yet, in customer meetings, I’ve witnessed colleagues fail to learn what customers need or want. Indeed, I’ve seen co-workers write down ‘requirements’ that were dead wrong.  Why?  Because they fell victim to three common uncovering mistakes.

  • Getting stuck in today
  • Asking yes/no questions
  • Failing to discover ‘why?’

Years ago, my colleagues and I nearly walked away from a customer alignment meeting thinking the customer required a costly feature, when in reality he did not.  We had asked one seemingly simple question… and that question suffered from all three pitfalls.  Here is the story.

Note: details have been changed to avoid disclosing proprietary information,  names have been changed to protect the guilty, and the technology called ‘Ubit’ is totally fictional.

Bob, a system architect from a mid-size company, had just presented his roadmap. My co-worker began sharing ours.  Our intention was to validate plans for the next products and to gather further inputs to inform outstanding decisions, including whether to remove a legacy technology called ‘Ubit’.

Bob hadn’t expressed a need for Ubit in his roadmap. Rather than assuming Ubit to be a ‘don’t care’, someone from my team rightly asked Bob about it.  They just asked it in the wrong way: “Do you need Ubit?”  Bob sat up straight and replied, “definitely!”  Bob’s response surprised us. My colleagues took a defensive posture.  They immediately began exploring whether other solutions would be acceptable.  By brainstorming alternatives, they indicated a reluctance to support Ubit. Bob grew angry. The meeting took a bad turn.

What happened?  We had asked, “Do you need Ubit?”  A deceptively simple sentence, this question exemplifies what not to ask.  Three specific things are wrong with these four little words.

Pitfall #1. Stuck in today.  When a customer hears, “Do you need Ubit?”, he implicitly thinks in terms of today and answers in consideration of his current product.  The questioning team, however, is thinking about the future.  Each person is in a different time-frame.  My colleagues are trying to understand what Bob needs in the future just as Bob describes what he needs now.  The uncovering team believed Bob had a strong requirement for Ubit in the future, but his requirement was for now.

  • Remedy: Ask about the future. Simply be clear about the time-frame.  A better question would have been, “Will you need Ubit in two to three years?”  This is better, in that it clearly asks Bob to think about his system out in time.  However, it is still sub-optimal, because it suffers from the second pitfall.

Pitfall #2. Asking yes/no questions. Bob answered the Ubit question in one word.  He didn’t explain why he needed Ubit or in what configuration. Why should he have explained further?  He was asked a ‘yes/no’ question after all.   The problems with yes/no questions are many.  For one they presume there are only two possible answers,  Secondly, they fail to encourage an explanation. Third, yes/no questions fail to get at ‘why’.

  • Remedy: Ask open-ended questions. If your question starts with ‘Do’ or ‘Will’, you are probably starting a yes-/no question.  Instead, start your questions with ‘What’, ‘Which’ and ‘Why’.

Pitfall #3. Failing to ask ‘why’.  Yes/no questions are unskillful, but can be resolved by simply asking ‘why’.  However, in our example, the team didn’t try to understand why Bob needed Ubit.  Instead, they jumped into brainstorming alternative solutions, for example whether external Ubit devices would be acceptable.  They tried to come up with solutions rather than doubling down on discovering why Bob needed Ubit.

  • Remedy: Ask what the customer is trying to achieve and what their goals are. Ask future-focused open-ended questions.

After realizing what had gone wrong, I interrupted the bickering and asked, “Bob, what capabilities will you gain in your next generation product with Ubit?”  Bob quickly replied, “Oh it just allows us to connect to a legacy processor.  We use that processor for board management and system control.”

I then asked, “What design goals are driving use of that particular processor on your next project?”  Bob thought for a moment.  “Actually, we have to drop that processor.  We just received an end-of-life notice from the manufacturer and now we need to start looking at alternatives.”   He then volunteered, “You know, for our next project, I don’t think we need Ubit at all.”


We recorded Bob’s comments and moved on.  At the end of the meeting, we brainstormed ways Bob could replace that legacy processor with one of our products at low cost and low effort.

By talking in different time-frames, asking yes/ no questions and failing to uncover the ‘why’, our uncovering team nearly walked away from an alignment meeting with the wrong view of Bob’s requirements.   Luckily, we were able to ask two open-ended, future-focused and customer-centered questions that got us to the right answer, and to closer alignment with Bob.

Pitfall antidotes:

  • Explicitly ask about the future.
  • Ask open ended questions.
  • Ask follow up questions that help you genuinely understand what the customer is trying to achieve.


  • “What capabilities will you gain in your next generation product by implementing Ubit?” (open ended, future focused)
  • “What design goals are driving use of that particular processor on your next project?” (asking for why)

It all seems so simple, right?  Yet, when we are absorbed in a conversation with a customer, it is easy to slip into bad habits.  Pro-tip: Spend a few minutes before the meeting and write down five open-ended, future-focused questions that get at what the customer is trying to achieve.  Formulate the questions before the meeting, and you’ll increase the likelihood of aligning skillfully.