Sometimes a customer requests a functionality. As an example, because she runs into a problem while interacting with the product. This is more serious when it happens often, when it prevents to accomplish critical or important tasks or when it forces time-consuming and error-prone workarounds.
In this case we are talking about a CRM-Like software, that is a software that every sales people and customer support org uses every day. It could be any enterprise software.
The customer says:
¨I want to sort alerts by sender. I need to sort by attributes. Sender must be the first column. How is it possible you cannot sort alerts?
We understand what she says because we know well our product. What we don’t understand however, is WHY that is such a big deal for her. WHAT is the problem she wants to solve in its essence.
Then we interview the customer and we get a totally different perspective
¨Tina gets many alerts but she only needs to know about the ones requiring action on her part so that she does not miss important ones by browsing among hundreds of them, every time”
Can you see the difference?
So, what does this example tell us?
- Customer was telling us the solution – We are the experts of the solution, not them.
- There could be many possible solutions , some much better than others for both us and the customer.
- Customer is the expert of what’s the problem he needs to solve. We need to capture that.
- Customer often has a narrow perspective, focused on his problem in a specific day on a specific scenario. It’s normal. We should *never* expect they write requirements for us. They are simply not good at that.
- We need to elicit the root cause of the problem. This may require meaningful interviewing skills/methods.
If we don’t do so, let’s not be surprised if we hear things like “The customer said that the feature does not resolve his problem. But we did what he asked for!”
