How do you find new product ideas? I love this question. I’ve been asked it many times and every time I still love it, because much like Jobs-To-Be-Done, my answer to the question improves over time, but the job itself stays the same. The more product work I do and the more I read, the more tools I have in my arsenal to answer.

Last time I was asked this, I went over my entire product process, starting with the high level view I shared in my last post.

Then I broke it down deeper into the individual steps between Discovery -> Validation -> Vision/Strategy -> Execution. I was met with a baffled look and a response of “Uh… yeah… we do some of that but we’re missing a lot of the Discovery piece.” So I shared a little more about my Discovery process (see the image below).

Product Management Process - Discovery Tasks (in no particular order)
Product Management Process – Discovery Tasks (in no particular order)

Now, let’s dive into the the first piece, finding a problem to solve. 

Find the Right Problem To Solve

It sounds easier than it is. People will share their problems openly, but they might not always be the right problems to solve. This is why we focus on finding the right problem before we form the trio; as product managers we want to weed out the bad problems and focus on the problems that are good for both the business and the customer to solve. 

For example, a customer came to me asking me to build them a product for a specific dataset, because the current data visualization tool just wasn’t good enough. I started to do a lot of digging and asking why their current tools didn’t function properly. The root problem ended up being that the existing tool couldn’t hold all the data without being clunky and slow. I then started to poll other users of this tool and validate that this was an actual issue. The answer was overwhelming. Yes, the tool couldn’t hold all their data either. So, the problem was much bigger than just one dataset. 

The tools I used here were pretty simple:

  1. The Five Why’s
  2. Polling/surveying other customers
  3. Repeating the main problem back to the customer

1. The Five Why’s

This method is pretty straight forward. We ask the question “why” five times to get to the root problem. 


Customer: I need a full stack web application for this dataset from your team.

Product Manager: Why?

Customer: Because the current dashboarding/data viz tool doesn’t work well enough.

Product Manager: Why? 

Customer: Idk, it keeps lagging and is sooo slow.

Product Manager: Why?

Customer: Because the dataset is too big and it’s stalling the system…

You probably get the idea. If you use the Five Why’s you’re sure to get to a root problem. I will say, I do change up how I ask my why’s so I don’t come across like an annoying five year old. 

Here are some variations on how to ask “why”:

  • Hmm, why do you think that is…?
  • Oh interesting, why is that?
  • Tell me more, why is that?

2. Polling/Surveying Other Customers

After you touch on a general problem and begin to get a good understanding of that problem that’s when you poll other potential customers. Using the same example from above, I surveyed the old fashioned way and sent an individual message to about 30 users of this data visualization tool. There are many methods of surveying or polling users, you can use SurveyMonkey, LinkedIn, Google Forms, etc. Don’t be afraid to get scrappy like I did though, remember, not everything needs to be automated!

3. Repeating the Main Problem Back to the Customer

Once you have a good understanding of the problem, repeat it back to the customer to verify you’ve heard it correctly. If you’re able to provide more data back to them on how you dug into the problem for other customers/users be sure to share your findings. When I went back to the customer above and said, “Hey I just asked 30 other people here and they all have the same problem,” they were actually elated. They knew this meant there was a very real possibility of my team solving this for them. 

My next question back to them was “Do you mind if I bring my engineer and designer in the room and interview you in more detail about this? I really want them to hear first hand what you’re struggling with.” They said they would love to be interviewed and off we went.

Other ways to find problems (Use the folks around you!)

As product managers we are like the hub in a wheel. We connect all the spokes together and form the solid base needed to keep everyone centered around. By this I mean we connect all of the stakeholders like sales, legal, HR, marketing, engineering, design, governance, customer success, support and others to the product we’re building. All of these stakeholders, especially the customer facing ones will have perspectives on problems we can solve through our product. Now, these do need validation with actual customer feedback and they need to fit into the vision and our strategy, but more on this later.

If your company records sales, support, and customers success calls, listening to these is a great way to find problems to further discover. I try to get on as many sales, customer success and support calls  as possible. This allows me to actually dig a little deeper into problems that come up, wants that arise while also being able to support the sales, support and customer success teams. Listening to the calls though provides a lot of insight into what the customer is saying. I recommend if you’re a new product manager at a company or in general, listen to at least 3 of these calls a week and write down any quotes or nuggets of information you’d like to bring back to the product team or clarify with the customer when you get them on the phone.


Finding a problem to solve isn’t really the hard part, finding the right problem to solve though is a skill in itself. Use these steps to find that right problem. In the next article I’m going to cover the product trio, what it is, and why it’s to break into the trio after you’ve discovered some problems you want the rest of the team to hear. After that, I’ll go into the customer interview once you’ve formed your trio.