Product Teams must stop these 3 things to define problems
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.
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.
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.
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:
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 http://prodman101.org