Problem Definition: From Exploration to Choosing the Right Problem
In the Discover stage, we explored the problem from different perspectives, collected evidence, and identified several potential problems. However, we cannot solve all of these problems at the same time. Therefore, in the second stage, Define, we need to move from exploration toward focus and select a specific problem that is worth solving.
At this stage, we synthesize and prioritize our findings so that we can define a problem that deserves our attention and effort.
What Makes a Good Problem Definition?
Consider the following problem statement:
“Users who frequently transfer money to previous recipients spend significant time and effort finding and re-entering the recipient's information. This friction increases the likelihood of errors and process abandonment.”
This definition contains several important elements:
User: Identifies who is experiencing the problem—in this case, users who repeatedly transfer money to previous recipients.
Context: Explains when the problem occurs—during a recurring money transfer.
Pain Point: Describes the actual difficulty the user experiences, such as finding and re-entering recipient information.
Impact: Explains the consequences of the problem, such as increased errors and process abandonment.
A good Problem Definition should describe the problem, not the solution.
The problem statement should be independent of the solution.
If we focus on a specific solution from the beginning, we may eventually find ourselves defending the solution rather than understanding and addressing the actual problem.
From “What Should We Build?” to “What Problem Are We Solving?”
In a traditional, feature-driven approach, the business team typically requests a specific feature while the engineering team focuses on how to implement it:
Business: I want this feature.
Engineering: How should we build it?
In product thinking, the questions are different:
Business: We want this feature.
Product: What problem are we trying to solve with it?
Product: What evidence do we have that this problem actually exists?
Product: Which users experience this problem, and in what context?
To answer these questions, we can use different sources such as support tickets, logs, product data, user interviews, and behavioral observation.
When we understand the problem correctly, we are much more likely to discover a better solution.
The Opportunity AI Creates for Engineering Teams
Traditionally, software teams often assumed that requirements had already been fully analyzed and were ready for implementation. Today, with the help of AI, if a requirement is truly clear and complete, a significant part of its implementation can be completed much faster.
This creates an important opportunity for engineering teams:
Instead of simply building features faster, teams can expand their role and become more actively involved in discovering and understanding problems.
The ultimate goal should not be simply increasing development speed. It should be using this new capability to build better products and solve real user problems.