Continues communication with your customers is an essential part of creating an enterprise product. Whether it is about validating new content; helping in closing a deal or providing technical support – the insights you get are invaluable. In this post, I want to focus on a special kind of customer engagements – product enhancements.

True. Customers are THE source of understanding what your product needs. Yet there is a subtle difference between satisfying a customer and satisfying market needs. Consider a real life example – you are sitting at a customer’s office. “Listen Joe” he says. “We are working together for a couple of years now and generally things are going well. This year we have the opportunity to triple our licenses” (this is when the sales manager, sitting next to you, drops his smartphone and starts listening very carefully) “Joe”, he continues… “I have to say, we really don’t know what to do here. You see – this and that are missing and <fill the name of your competitors> has it. So tell me, what do you think we can do about it? Can we add it to the product?”

Say “Yes” and you got a happy customer. You also got a happy sales rep as a new deal is closer to closure. But what if it is going to be a bad idea for the product and a risk to your development plans?

Say “No” (or “Later”) and the development plans remain on track but you got an angry customer. So what would it be? How would you tell the “Yes” from the “No”?

I get into these dilemmas quite a lot so I created a 2-easy-steps plan that work extremely well under these circumstances:

• First – run through a list of 5 questions.

• Next – keep in mind that “Yes” and “No” are not the only options. Asking these questions will help you identify these other possibilities.

 Here are the 5 questions:

• Ask “Why?”

  For some reason, we just love to jump to problem solving and forget to ask our customers for the reason behind the request. Always ask why. If you don’t get a good answer, ask again and again until you get to the bottom of it.

  The fact your customer wants a specific feature does not mean this is the right solution for him. First try to understand what he REALLY wants to achieve.

• Find out “Who?”

  Some changes may be beneficial to everyone; others are relevant only for a few. There is only one thing worse than a feature that nobody uses – that would be a feature used by a single customer. What you don’t want is a product with a long tail of “one-off features”. Ensure the request is something your customers really need.

• Ask “Does it fit our strategy?”

  An enhancement request implies that something is missing. On the other hand, I am pretty sure there is a very long list of stuff you want to add. So what makes this one different? Product wise, it should be treated differently only if it serves your roadmap.

  Of course, to answer this question, a product needs a roadmap…

• Find out “How much does it cost?”

  This one is a bit tricky as you should ask it only after you concluded the enhancement request is a good idea. A low price tag shouldn’t be the reason to implement something. It is the other way around. A high price tag should be the reason NOT to implement it. Also, from my own personal experience, even if your engineers tell you it is a day’s work, there are always hidden costs. You can’t see them (that’s why they are called “hidden costs”) but they quickly pile up and turn a day’s work into a week.

 […Hey, you said there are going to be 5 questions. Where is the last one?… you are right. One question is missing. Which one is it?]

Now, if you keep in mind that “Yes” and “No” are not the only answers, you are set for the next step.

Getting back to the “Why” – ask “Why” and be prepared for surprises. Now you know what your customer really needs. What is the problem he is trying to solve and what is his real pain.

It is time for a short brainstorming. Get the PM, get the functional architect, get the engineers and QA and think together what would be the right solution. In most cases, it turns out that you can make the customer happy only by instructing him on how to use or how to configure the product to suit his needs.

When it works – everyone is happy. The client got what they wanted, the account manager is pleased, and the development and the product are on track.

When I get a request for which “Yes” is not the right answer – 4 times out of 5, the above works. For instance, in a particular product, we were asked to uniquely change the way we run the login. It was a deal breaker for an important account. When asking “why”, we understood the real problem was a difference between the corporate login and the product login so instead of adding yet another private patch to our code, we suggested to deploy a simple filter to the system’s web server. It did the trick.

Bottom line – You don’t have to say “Yes”, you don’t have to say “No” yet you can deliver your customer what he needs.

Oh, another small thing – the secret ingredient which makes it work is letting the customer know you really care about him. That you genuinely want to understand his needs and provide the best solution. Great technology fireworks is not enough. If you don’t do it the right way, you may find out your customer feels as if you are trying to shake him off your back.

Good luck!

Ilan