PMs, Problem Discovery is where you are losing out

Product Management gets a lot of flak for not gathering the requirements correctly. The prime reason is that problem discovery is Hard, and PMs take it lightly.

This is what makes it hard: 
1. Customers are confused about what they need versus what they want versus what they are asking for
2. Customers aren't able to articulate clearly - often not their core skill 
3. Most customers describe solutions they want you to build instead of the problem they want you to solve
4. Product guys are biased by their limited product and domain knowledge. They look at new things with the old lens. 

Understand the problem-solution continuum 

If your vision and roadmap are not clear for the product. All your work, including client communication, requirement gathering, and problem discovery, will be very sacrificial. You need to have a very clear understanding of: 

• What are the general problems in the domain
• What are the general problems of your customers and of your users? 
• What specific problems is your product solving 
• What specific adjacent problems is your product not solving
• What are the alternatives being used today (direct competition (Coke v/s Pepsi) and indirect competition (SaaS v/s Excel), and alternatives (Netflix v/s Uber v/s Wakefit))

When you understand the problems and solutions in the domain, you’d be able to understand whether to push back on a request or add it to the roadmap? It will help you know if you should dive deeper in to it and start requirement gathering or request the clients to gather their thoughts and schedule a meeting when they are more mature.

Get answers to “Why” without asking Why. 

• 5 Why’s are super helpful in lab conditions. However, like our brain, in our conversations as well, we need to prioritise emotion before logic. Asking Why and getting a useful answer is super hard. Asking “why" forces people to think things they haven’t thought through earlier. Thinking creates friction. It may also make them feel stupid, or they may feel challenged. It causes cognitive dissonance as their initial reasons may not justify the original ask. Some clients feel you should not even ask “Why", it is your duty to do it, since they asked for it. This is mainly because that’s what they may be doing in their role. They may not have a clear answer to your “Why”.

• 
  

Alternatives to asking a direct WHY question

• How would this help you? 
• What will you achieve with this?
• What is the problem you are trying to solve with this?
• What kind of decisions would you take if this was available?  
• Let’s assume we have this today. How will you use it, and what will you do next?

Listen to understand, not to respond. 

• Clients may have very wrong assumptions about your product. It’s ok. Listen completely and take notes.
• They might ask for a feature that you already have, but they have never used. It’s ok. Blame the discoverability of your feature.
• When they complain (or rant), try to understand why YOU are not able to feel the same pain. 
• Error Messages: When they don’t read the message and take corrective action, think about how you can make the error more understandable, instead of just more readable. Can you suggest an alternative action?

Solve Problems.

 Your product is an enabler, not a constraint. Clients look up to you as a problem solver. 

• Don’t explain your limitations and constraints. They may be important, but they don’t sound interesting and do not encourage the client to convey more.
• Ignore your mental screams that “this is not possible”, “this is not what you created the product for”, “you never asked for it earlier”. All of it may be true, but it hardly matters.
• If you cannot immediately think of a solution on how you can enable them to solve this, just listen and take notes. Tell them you’d work on it and come back to them later. Helps you give a better response and avoid conflict.