Don’t confuse Customer Requirements with Product Requirements

Lots of people still confuse Customer Requirements with Product Requirements. This misunderstanding generates a “listen to your customers” vs. “don’t listen to your customers” paradox. A paradox, that simply does not exist, if you distinguish these 2 definitions.

This article is about to help you to separate these 2 things and resolve that fictional paradox forever.

Customer Requirements

Customers always ask you about something. But when you listen to them and just do what they asked you to do, then you _do_ confuse Customer Requirements with Product Requirements.

If you directly (stupidly) translate Customer Requirements to Product Requirements as feature requests, then you’ll end up with something like this “beautiful” product:

You will inevitably make a “features hell” product, because “customers want everything under the Sun” and you tried hard to please them all…ending up pleasing no one!

Product Requirements

The best products created when the customers tell about their problems. Problems to be solved. But even if they ask you for features, it’s your job to listen to them more emphatically (clever) and ask them about underlying problems, about the jobs they are trying to accomplish using those features. Ask them about their problems. Not about solutions (features), but about problems.

Customer asks you about features because it is easy for a customer to talk to you in terms of features. Features are obvious for a customer: “just add ‘Save’ button here”. But don’t stop here, don’t dully translate this Customer Requirement to a Product Requirement. Do your job and ask your customer for a job to be done using “that button here”. Go deeper, find the root cause and you’ll get a real Product Requirement. For example: “don’t implement ‘Save’ button, implement ‘autosaving’ mechanism”.

Conclusion

It’s not your customers job to tell you both WHAT to implement and HOW. It’s not their job simply because they are not good at it due to a number of reasons. Instead, it’s your job to decide WHAT to implement and HOW.

To completely reveal the “listen to your customers” vs “don’t listen to your customers” paradox, let’s rephrase it to:

Listen to your customers problems. Listen even if they talk to you in terms of solutions — just in order to better understand their problems. But since you’ve got their problem, stop listen to them. Stop listen about what the solution should be and how to implement it. Because you know this stuff better.

I hope that since now that “listen to your customers” vs. “don’t listen to your customers ” paradox is resolved and just does not exist for you anymore!

P.S.: If you liked this article, please don’t hesitate and tell me about it in comments and share it with others by giving it some claps!

Thank you!