Your statement that "The details of the communication are unimportant
here," is not accurate. The details are everything in a situation like
this. The big question is "What *specifically* made Customer feel this
Before you can strategize on how to mitigate the situation, you need
to find out what the situation actually is. If all you have to go on
is that a client said "I feel like I haven't been listened to," then
you really have nothing to go on.
Hopefully, your PM sat down and talked to the client and found out
what they meant by that statement. If nobody has done that part yet,
it is certainly the first step that needs to be taken.
Here are some possible interpretations for the situation:
1. The client is actually not being listened to.
If this is the case, you need to find out why not. Are the client's
requests unreasonable? Impossible? Perfectly reasonable, but the
programmers aren't listening? Find out the reason, and decide on an
appropriate course of action. This can include educating the customer,
assigning someone with good customer relations skills to liason
between customer and developers, and/or giving the developers a good
talking to about ignoring reasonable customer requirements. Make sure
that Customer knows that you intend to take action and make sure that
you follow up.
2. "I'm not being listened to" is actually Customer-speak for "I'm
really frightened of this whole website thing."
If this is the case, find out what is frightening them. If it is
technology-fear, then perhaps taking the time to demystify things
would reassure Customer. If it is political fear, as in, Customer
frightened that they will be blamed by superiors if the project does
not meet expectations, then reassure them that you stand behind your
work and will take responsibility.
3. Customer is being very much listened to, but some pet feature got
rejected or overlooked.
If this is the case, either implement the pet feature, or try to
substitute a feature you can implement (or already have implemented)
in Customer's affections in place of the pet feature that they are
4. Customer is a petulant, whiny, unreasonable person who would be
saying this regardless of how closely you followed their instructions.
Be careful of this one. It's very easy to decide this about a client.
It's rarely the actual case. Give Customer the benefit of the doubt,
unless he has such an obvious history of this behavior that you can't
As you can see, there are many interpretations for "I'm not being
1. First and foremost, you *must* find out what Customer really means.
2. Once you find out what the issues are, address them in an
3. Once you decide how to address them, communicate with Customer what
you believe the issue to be and how you plan to solve it.
4. If Customer agrees with your assessment, implement the solution.
5. Follow up with Customer to let them know how the solution is going.
6. Find out how Customer thinks the solution is going.
7. Repeat if necessary.
Good luck with your customer situation!
Request for Answer Clarification by
31 Jan 2003 12:12 PST
Thank you for the speedy response. I think you are really honing in on
the situation, despite my vague (albeit all-too-familiar) scenario.
I will clarify my statement that "the details are unimportant here" --
I wrote that so that a broader range of actions could be evaluated
before diving immediately into the specific causes of the
I think a combination of 1, 2, and 3 of your recommendations makes
sense in my case. I will be prepared to pay a tip with your follow-up
of this question:
How could documentation (email, internal notes, phone conversations,
etc.) be presented tactfully and professionally to the client to try
to reconcile in this situation? Please bear with me, this is the first
time the client has exhibited the idea of "not being listened to"
during our relationship, so I want to make sure they are entirely
satisfied with how we are handling their concern.
Also, we do not feel the client is being whiny or petulant, at all. I
suspect some amount of "fear of the unknown" as we move from a
research and planning phase into a more visual phase (where there will
be artifacts to react to).
Clarification of Answer by
31 Jan 2003 12:41 PST
First of all, this must in no way be made into a contest. When you
present evidence like communications, do not present it as triumphant
proof that you are right and Customer is wrong. The point is either to
start listening to your Customer, or, if you have been listening, to
reassure Customer of this, NOT to make Customer feel stupid. If there
is a fear issue, making Customer feel wrong and/or stupid will only
make him more frightened.
As illustration of how to do this professionally, I'll present an
example conversation between developer and Customer.
Customer: I feel like you're not listening to me. The site doesn't
look at all like what I expected!
Developer: That is certainly of concern to us. We want you to be
satisfied with the final product. Where do you feel like we've failed
to meet your requirements?
(Note: Requirements, NOT expectations.)
Customer: You don't email the orders to me, like I asked. I don't want
to have to log into an order page all the time. I wanted them just
emailed to me.
Developer: Hmmm...according to our conversation on such-and-such a
date, your main priority on this was that you be able to take credit
cards. We can't email you credit card numbers without breaking
security. Since security was very important to you, we took this route
instead. I'm sorry that we didn't clearly communicate that there was a
conflict in the requirements. If having the orders emailed to you has
become more important that being a secure site, we can certainly make
that adjustment for you. Is that what you want us to do?
* Use the documentation to show Customer how well you *have* been
listening to him.
* Show how what you have done is designed to meet his requirements as
provided to you during the design phases.
* Tell him that you understand that expectations evolve and
* Show him how his current requests differ from the original
requirements (if they do).
* Express willingness to adjust requirements to meet his current
*** Make absolutely sure he understands how his requested changes will
affect his original requirements. This is crucial. It not only shows
that you truly do listen to him, but also that you understand his
business needs. Say things like, "I can make that change, but do you
understand that it will prevent you from running the monthly summaries
that were very important to you earlier in the project?" This forces
Customer to think things through, and also shows him that you *have*
thought things through.
If you handle this well, your client will trust you more than he did
before he decided that you weren't listening to him.
All of this assumes, of course, that you are indeed listening to him.
If you aren't, then the solution to the problem should be fairly