Product Teams must stop these 3 things to define problems

ProdMan101 — How to define the right problem

Defining the Problem looks so easy, isn’t it!

Well, you have identified a problem. Now all you need to do is determine all the different dependencies and make sure you detail it out in a way that the other team members can understand clearly. Simple, isn’t it?

Well, if you are someone defining your problem in a similar way, you should definitely start looking at the three mistakes Product Teams do when defining the problem.

Defining the right problem is also the second step of Design Thinking. Without the right approach used, the process itself might get crippled.

Do a Problem Discovery. Don’t take your users’ wish list

This is the first and critical step in the Problem Definition phase — Problem Discovery

Problem Discovery is the process through which teams discover the existing problems faced by people or organization, what’s the importance of the problem, and how the problems are being solved at present.

If you are doing this incorrectly, chances are high that the entire process would be heavily flawed (unless you can detect your error in the later steps).

Even though, when asked most of the respondents agreed that this is the most critical step, here are the 3 mistakes teams often do when defining the problem

Users define what problems they are facing

Don’t get me wrong here.

It is quite important to understand, observe, and interview the users to go to the depth of the problem.

However, if your users define the problems, mostly they are providing you their wish list.

That would be a lazy way to define your problems.

The Gold Mine Illusion

Another scenario where Defining the Right Problem is thrown into the bin. Instead, the benefits of getting a share of the pie take more importance.

Problem definition is not a force-fitting game. You should not determine the benefits of doing something and then backtrack to define the problem.

Many startups and teams do this mistake today. As a result, you would see so many “Me Too” products out there, often facing the challenge of user adoption.

Problem is not refined

Let’s say you have identified a problem and have analyzed and research to determine it’s the right problem to solve.

Does that mean your Problem Definition is completed?

Not at all. On the contrary, you have just completed the first step.

If you don’t refine your problem statement, you would have no clue what to do with the problem. It’s like giving a smartphone to a monkey.

Take time to get to the depth of the causes. The more clarity you can get in this step, the fewer surprises you would face later.

The 5 Why Technique

Remember, each cause might have another cause. Many teams use the “5 Why” technique to better analyze the problem.


ProdMan101–5 Why technique to analyze the problem

As you can see, the starting problem statement might not be the best one to use.

How to identify the problem from 5 Why?

It is not necessary to always consider the last problem (or Why) emerging out of the 5 Why technique.

For each “Why” (or Problem), determine the following


Ask yourself — If I solve this problem, would my target users want the solution?

Remember, desirability is not always a question of how good you can make the user experience (that comes later). First, you need to understand if your users would want this solution.


Would I be able to solve this problem?

Even though oftentimes, the answer would be “Yes”, you must take into consideration the factors — Resource and Time.

Sometimes, startups may not have the right resources — Tech Capability, Team, etc. due to which even though the solution is theoretically feasible, given the constraints, it would be marked as Infeasible.


As a Product Manager, you are not responsible to solve all your user’s problems. You should only solve those problems that solve your business priorities.

Imagine if the banks had loaned out money to their customers at zero interest. Would the bank make money? No right.

So, even though the customers are benefitted, for the bank that is not a viable solution.

The same goes for Problem Discovery. You should consider that problem that is viable (or will be viable in the near term).

You can do this step as a group activity and mark each factor on a scale of 1–10. The final sum of the three scores would tell you which problem to go after.

No KPIs Defined

The last and the most important step of Defining the Problem.

This is also the step that is often ignored by many teams.

When you are working in an Agile Product Team, you would typically be doing the following:

ProdMan101 — Product Team Experimentation

To be able to determine whether the experimentation is successful, setting the KPIs at the initial stage is of paramount importance.

Without the right KPIs, your experiments will run without any control, and you will be shooting in the dark.

Are you doing anything different to define the problem in your organization? Let me know and I would love to understand further.

For more Product Management posts, visit



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store



Product Manager | Product Enthusiast | Nature Lover