Knowing your customer

October 24, 2013

Why is it that so many products show a lack of understanding of the intended customer? There is plenty of advice saying, “Know your customer”, yet it does not seem to be followed.  Knowing your customer takes a lot of time, more time than most companies seem to be willing to spend.   The driving force in most organizations is to avoid “analysis paralysis” but to go off and build things.  The Agile methodology encourages this by fostering an incremental and iterative learning of what product will succeed in the marketplace. Learning through iterative building can be expensive if it is not focused.  Having a good idea of what your customer is like before you iterate saves time and money while increasing the probability of success.


For many, “knowing your customer” is equivalent to having a feature list.  These lists can come from a variety of sources (e.g. customers, sales, analysts, and engineers) and can lull a Product Manager into thinking that they understand what the customer will buy and prosper with.  To create good products you have to understand the problems the customer has that are being solved by the features. To know your customer you also have to understand the customer’s eco system.   


Really understanding your customer takes time, hard work, and requires insight.  It means spending enough time with your customer to allow you to understand that customer’s needs better than they understand them. It means digging into their psyche, as well as their job descriptions and corporate politics. It is much more than writing down the things they ask for. It means knowing the customer so well that you know what they should be asking for.  It means knowing when they are asking for things they shouldn’t and being able to engage them in that conversation.  It means knowing why they are asking for certain things. It means developing instinct about their world as a person using your product.


Getting to that level of understanding requires time and effort.  It means spending time with customers in their job situation so that the realities of their job are observable and understandable.  The realities they deal with that influence your product solution become apparent. A product builder will see the customers’ reality differently than the customer will see it.  And this is the important difference because as a product solution problem solver, when you understand the problems, you will be able to come up with a great solution.  The Product Manager is a solution provider, not an order taker.


Really understanding a customer knowing the answers to the questions below:

  1. How smart is our customer?

  2. How much training will they be willing to exert to learn your product?

  3. How much time will they devote to your product?

  4. How quickly will they need to succeed with your product before they (or the company) run out of patience?

  5. How does your customer get a raise, bonus, and promotion?

  6. Where does your customer spend their time?

  7. Why would they want to use your product?

  8. What benefit will they reap?

  9. What costs (financial, personal, and political) will they incur in adopting your product and why will they incur that cost?

  10. Where are they failing?

  11. Where do they need to succeed and why?

  12. How will their lives change if they use your product?

    • Day to day

    • Politically

    • In accomplishing their job

    • In getting a raise or promotion

  13. Who is your customer trying to influence by using your product?

  14. What do they personally gain from using your product?

  15. Who else in the company will use this solution (they are a customer too)?

  16. What does the company or department gain from using your product?

  17. What political pressure will be created and/or lessened by your product?

  18. Who is the real buyer of your product?

  19. Is this problem something that “must” be solved?


The goal here is to get past the high-level feature discussions that are such a big part of most Product conversations.  By themselves, feature lists are meaningless. They do not define the problem the customer has.  Features are a customer’s solution to, often unstated, problems. Customers will often be nice to a Product Manager and say yes to things they may not really need or buy. It is one thing to ask for a capability or agree that it is a good feature.  Actually writing the check is a whole different process that bears little relationship to the earlier stated opinion. Understanding the customers’ reality will inform the Product Manager about the likelihood of a purchase actually taking place when the solution is delivered.


Spending the time to really understand the customer can be a challenge to most Product Managers because they just do not have the time.  Being a Product Manager (or an analyst) is a high-pressure situation with many demands and very little flexibility.  Going into the field and actually following a customer around for a few days or weeks is outside the scope of most job descriptions.  Doing this multiple times with various customers is just beyond the scope of what most Product Managers do.


It is the lack of time that drives Product Managers to seek proxies for knowing the customer well.  Analysts, surveys, questionnaires, and sales meetings are all important activities for a Product Manager.  They provide good information that will help in many ways.  But they will not get a Product Manger to know his customer better than his customer knows himself.  They lead to guesswork.


Take the time to know your customer!


© 2011-18 Westerly Consulting LLC, all rights reserved

Share on Facebook
Share on Twitter
Please reload

Featured Posts

I'm busy working on my blog posts. Watch this space!

Please reload

Recent Posts

November 23, 2015

September 11, 2014

Please reload

Please reload

Search By Tags
Follow Us
  • Facebook Basic Square
  • Twitter Basic Square
  • Google+ Basic Square

© 2017-18 by Westerly Consulting, LLC

Westerly Consulting, LLC

All photographs by Fred Engel