How seriously do you take customer feedback?

Hi Simon,
Thanks for the insightful comments.

While I agree with the gist of your comment, there is a subtle difference in one aspect of customer feedback that I have tried to highlight in this article. While it is important to hear the customer's feedback and understand the problem statement, the problem starts when we start to take the customers solutions on the face value and start to build it into the product. This happens more often than not and is one of the main reasons why the final product deviates significantly from the original and soon becomes unmanageable. This also leads to the what I call as "God Customers" where the loudest and the most critical customer starts to dominate the shaping of the product.

As long as we as project managers understand this aspect, I think we can handle customer feedback better.

Cheers!
Ram

Hi Tom,
Thanks for the insightful comments.

Completely agree with your thoughts. That is exactly how the customer feedback needs to be processed.

The problem is that in today's world of aggressive deadlines and ever shortening development lifecycles, many product teams just take the shortcut of doing what the most vocal customer says and move on!! This leads to significant challenges downstream.

Cheers!
Ram

Hi Tom,

A important clarification - customer can have different meanings and end user and sponsor do suit Ram's initial post.

The context of the project would define when the terms are suited, and my answer is based on my experience in project management where the project has a defined customer (or sponsor, as you would say) who defines the problems and requirements, and understands the result that needs to be acheived.

The role of the project is to
(a) capture all requirements,
(b) define the mandatory and 'nice to have' requirements, and the selection criteria for solutions,
(c) evaluate solutions that can satisfy requirements (could be a Request for quote or Request for proposal),
(d) propose a solution which meets all defined selection criteria, and (e) contract, design, build, test and implement the selected solution.

During the testing phase of the project, some subset of end users would be selected to evaluate the solution based on the requirements and the selection criteria defined by the sponsor at the start of the project. In this context, my "customer" includes both sponsor and end user.

I've had situations where a customer (my definition) has agreed on something as a high level solution, but when the project deliverable is presented (as final product or as a prototype) the customer has complained that it does not align to the expected "look and feel" and the project has been forced to reevaluate. I have had more than my fair share of God customers (have we worked in the same company Ram???), and my best response to date is a tight definition phase with clear acceptance criteria signed off, and then iterative prototype demonstrations so the customer always know progress and can suggest minor adjustments.

The approach that Ram defined seemed to be more 'product management' than project management.

However, the tension that you refer to - which occurs in many contexts - needs to mitigate the risk that customers are not always the best reference points when it comes to functionality and features, because as you say, their perspective is limited by their current experience. This can be restrictive.

Great conversation Tom and Ram, thanks for engaging with me on this!

Simon

Sorry but now we are "mixing" things in my understanding. The first thing to do is to work on "the problem". The problem will trigger the need. But here is the first key: problem is defined as the gap between the perceived reality and the desire reality. So, we need (the business analyst) must work on the perception or on the desire or on the gap. Most of the time, there is no problem to solve (when you work on the perception). In the case of Apple, 3M, Toyota (where I was the pleasure to work) they go further: they do not have client or customer to work with. That is because Job usually said: clients do not know what they want until you show it to them. I mean, most of the times, when the organization takes a proactive strategy, it has to take into account that there is not a stakeholder to interact with to define the product/service/result. But again, clients or customers always know what they want/desire/wishes and people who have to translate it into requirements must understand that. What you describe is explained by the Lehman Laws of change. Time ago I wrote an article that was published by the PMI. And sorry but the situation demmands a review on the process to get needs (elicitation) and manage stakeholders. We are facing this type of situations into each initiative.

Sergio,
Again I partially agree with you. Kindly note that a product has many customers and not just one or two. While each customer has a general idea what he or she wants, the ideas could be very contradicting while fitting together in a product. So yes the roles like business analyst have been created for exactly avoiding this situation. But what this article deals about is how the business analyst or a Product Analyst has to approach the customer feedback. The intent of the article is not to say that we do not need to listen to customer feedback, but rather to sensitize on how to interpret the feedback. Whether to take it literally or to dig deeper and understand what the underlying problem is. I will give a recent example where one of our customers was very particular about one workflow and he kept repeating that he wanted to do it a different way else he cannot use the product effectively. And based on this customers feedback a couple of times the company altered the product, but the customer never seemed pleased with it even though the implementation was exactly what he had asked for. Then we setup a detailed session with him where a couple of us just decided to monitor him as he undergoes his routine and then we figured out that his actual problem lay in the way the hospital network and other equipment was configured to work with our system. And believe me, once that problem got fixed, he was more than happy to go back to the old way in which the software was originally designed as that was the better way to do his work. It is instances such as this which highlight the need to listen to the customer, but more importantly understand what he needs rather than what he wants.

Probably we are mixing things. Anyhow, I do understand and appreciate your point of view. Thanks for making the discussion interesting.