How do you identify a problem?
Product Managers (PM) are intuitive and full of creative ideas. At the same time, they are analytical enough to process enormous amount of information to find the answer. They are capable of balancing their right and left brain with slight bias towards one side depending on the problem and situation. But even more challenging task they undertake is identifying a problem. A problem could come from any aspect, any source and at any time. Good PMs are always on their toes to recognize and diagnose a problem as soon as they see one. But, a great PM can feel the problem even before it occurs. A great PM is proactive, able to identify the subtle indications, predict the problem and make a choice. Depending on the nature of the problem, the PM could either work on the solution or delegate it to the appropriate team to come up with a solution. You always have to know when to take things in your hands, when to reach out the appropriate person and when to call in your boss. Part of the reason is because you should be able to assess your time, effort and limitations to avoid feeling overwhelmed. And a bigger reason is to move fast. There are various techniques to identify a problem. Let us look at a few common ones.
Goals and Barriers Method (GBM)
This method is the most generic way of identifying a problem. Every situation has a goal. The barriers that stop us from achieving that goal are the problems. There could be one or many barriers. Write down your goal, and try to identify as many barriers as you can. If your goal is too broad, break it down to sub goals and then try to find out what is stopping you from achieving them. This process may be applied to just an idea you have or a fully developed product.
Contextual Inquiry
This method is mostly employed during the human centered design process. The main difference from the GBM is that you observe someone else, usually a focus group or a user, perform to reach the goal you want and identify common patterns, behavior or any other factors that are barriers. This is not applicable to all scenarios like the GBM, but is a very effective tool to identify problems or improvements that could be made on your products. The process involves providing a task to the user and observing them perform the task. It may be in an informal setting where you just observe people using your product. In a more formal setting, the user or focus groups are given a set of fairly complex tasks to perform. You then make a video/audio recording while they perform the task. You may also keep asking questions to the user while they perform the task. A more comprehensive process involves a group of people observing the user’s expressions and marking down a set of emotions. Barriers need not be just physical, they could be emotional as well.
What-if Scenarios
Another broad method which fits to most of the situations is the What-if Scenarios analysis. You start with creating as many what-if scenarios as possible and test your idea or product with various facts. If the scenario fails, you take it up and identify why it failed. This is by far the most easy method and is usually fast and effective when you sit with your team to brainstorm on different factors on your idea. The advantage of involving a group of people than performing it alone is the identification of edge cases. People usually come up with crazy what-if scenarios when allowed to build on top of others’ ideas.
Having looked at certain problem identification techniques, I urge you to think of a problem you had worked on and try to figure out a structure behind the whole experience. How did you identify the problem? The point is that in the real world, you usually have a problem coming in from various sources such as customers, support, sales and engineers. The above methods can help you not only identify, but also determine if something really is a problem.
Having said all that, you as a PM, also have to translate the problem into an opportunity. An opportunity to build a new feature, enhance user experience, increase business value or improve customer delight. After you identify the problem, instead of rushing to solve it, lay down the different interacting elements of the problem. Break it down, understand the nature and structure. Try to answer the following questions
- Is this is a symptom or the real problem?
- How many sub-problems do we have after breaking it down?
- Is there any cause-effect relationship?
- Are the problems sequential?
The way of getting into the nature of the problem is by using the “Five Whys” technique from Taiichi Ohno of Toyota Production Systems. When you see a problem ask why does this problem exist. After you find the reason, ask why again. Go five levels down. You will not only uncover the root cause of the problem, but also have the bigger picture. Only after we have identified the problem or opportunity, can we move further into the solution design process.
—
Afroz Mohammad is a Product Manager at a startup that brings AI to business applications. In his free time, he works out, reads and writes. He is always up for some interesting discussions and coffee.
^\_(``/)_/^
