Product Mastery Now for Product Managers, Leaders, and Innovators

Product Mastery Now for Product Managers, Leaders, and Innovators


394: How product managers master the art of questions - Tony Poon

July 24, 2022
Ask the right questions to uncover your customers’ problems

Product Manager Interview - Tony PoonToday we are talking about one important skill that separates great product managers and innovators from the rest. It is the same skill that separates great leaders from the rest. It is also seen in great friends. What is that skill? I’m going to leave you in suspense for a moment and first introduce our guest.


Tony Poon is the Chief Product Officer for R-Zero, a biosafety technology company creating products for disinfecting shared spaces. He has a long history in technology products that includes Texas instruments, Logitech, AMD (where his customer was Apple), and many others.


Tony is going to help us get better at this important skill for product managers, which is asking the right questions.


Summary of some concepts discussed for product managers
[2:42] You’ve said, “To find the right answers, you must first ask the right questions.” When did you start realizing the power of questions?

I come from a computer engineering and hardware background, where the stakes are high because mistakes take a long time to fix. When I was an architect designing systems and working with product managers, I would ask for a list of features and come up with the best architecture I could, but there was a chance I was solving the incorrect use case. I realized we can unintentionally end up solutioning things we like based on assumptions of what the problems are rather than based on the actual customer pain points. Failures led me to understand that if I don’t really understand what the problems are, it’s really hard to come up with the right solutions. The best way to uncover the right answers is to ask the right questions.


[4:36] What are the characteristics of the right questions?

It’s about asking the right questions and asking them in the right sequence. Ask questions focused on the context of the problem rather than the symptoms. Often we’re presented with a list of attributes of a problem or the solutions someone is describing, and we have an urge to go into the solution right away because we assume we understand the problem. The person presenting the problem or you yourself may be so excited about trying to resolve the problem that you don’t get enough coverage on the different facets of the root causes of the problem. You’ll end up solving only a portion of the problem or missing the mark completely.


Acknowledging the symptoms is really important, but redirect your team to focus their firepower on the root problem that’s causing the symptoms. Asking three why questions is a good place to start.


[8:06] How do you think about framing a problem?

First understand whom you’re solving the problem for.  Often, especially in enterprise, the person who’s describing a problem to you may not be the person experiencing it. I’ve often realized too late that I’m talking to a third person who may not truly understand the motivations and drivers of the person experiencing the problem. Don’t start until you have framed the person whom the problem impacts.


Second, understand what outcome the customer is trying to achieve. Solving for people’s preferences often doesn’t yield the ultimate outcome. Explicitly uncover the outcome of the stakeholders and the success criteria to be able to say whether you can solve the problems efficiently.


[11:51] What other insights do you have about the right questions?

I sometimes catch myself asking leading questions with a solution in mind. There’s a time and place for that, but getting into the solution space too soon often leaves a lot on the table so you can’t fully uncover what the problems are. Resist the urge to jump to questioning around solutioning.


Be cognizant of whether you’re asking questions based on facts or assumptions. Are you asking a question as a reaction to something a customer said, or because you have an assumption? Knowing the source of the question helps you uncover how much weight to put on the answers you get. Use your customer’s name more and use “I” less. This helps you fact-check whether the customer said something or you assumed they said it.


Tools like journey mapping are helpful for writing down what’s being done and your goals. This helps you fact-check when you come up with a solution to see if there’s going to be an impact on the actual problem rather than on what you think customers need.


[17:14] What are some wrong or less powerful questions?

“What if” questions are potent but dangerous. Customers may react positively, but they may be reacting to your great idea rather than the fact that it connected to their outcomes. If I ask my son, “Would you like candy?” I know what the answer will be. It’s very different if I ask him, “What snack do you want?” You get extremely different perspectives.


Product people sometimes tell the customer they’re using the product wrong. Far too often they apply logic to customer behavior. The customers know their problems best, and they will always use the most optimal way of solving it. Our job is to solve problems rather than telling customers the right way to use our tool. Customers have reasons for using products a certain way, and it’s not all driven by the most optimal logic.


[21:02] What’s an example of asking the right questions?

When I was at an industrial drone company, one of our customers was a mining company. Mining safety engineers have to walk around the mine and make sure things are compliant. A customer told us their compliance checks were manual and time consuming, and they wanted us to make them more efficient. Our engineers jumped into action to build a drone that could fly autonomously and use machine learning so they wouldn’t need human beings. However, we realized we had no idea what was driving their workflow and making it inefficient. The root problem ended up being that regulations required people to physically walk the site in order for a certified professional to sign off. Without knowing that, we would have a build a solution they could not use. By taking a pause and asking questions, we were led down a different path to build a mobile app that provides high-precision GPS documentation offline.


[24:36] What’s your perspective on the Steve Jobs quote, “Don’t listen to your customers. They don’t know what they want”?

I don’t think that’s actually what he meant. What he was trying to say is listen to what the problems are regardless of who’s telling you what the symptoms are.


Action Guide: Put the information Tony shared into action now. Click here to download the Action Guide.

Useful link:

Innovation Quote

“A problem well-stated is a problem half-solved .” – John Dewey


Thanks!

Thank you for taking the journey to product mastery and learning with me from the successes and failures of product innovators, managers, and developers. If you enjoyed the discussion, help out a fellow product manager by sharing it using the social media buttons you see below.