PM 101: Define the Problem Before the Solution
12 May 2019 ‧ 3 min read
In the “PM 101” series I am sharing some PM basics that I wish I had known when I first started as a product manager. In this article, I will explain why it is crucial to separate the problem definition from the solution design.
A common behavior of new product managers is to start with a feature idea (that they came up with, got given by a manager, or heard from some stakeholder), riff on it by creating some flow ideas or wireframes, and then take it to a designer to flesh out the UX and the UI. Unfortunately, this approach is completely wrong and leads to alignment problems and building the “wrong” features.
The alignment problems stem from the fact that with this approach, alignment has to happen on the level of “what are we trying to build”. While that's a good question to have alignment on, a better question is “why are we trying to build this / what problem are we trying to solve”. When the entire team from PM through designers and engineers to other stakeholders fully understands the problem a feature is trying to solve, everyone can make informed decisions that will further this purpose. This clarity is important for the PM too: often a feature idea sounds good on the surface, but making tradeoff decisions can be tricky unless you have a deep understanding of the problem.
Starting with the feature idea before clearly defining the problem also means possibly solving the wrong problem (a problem that doesn't exist, or a less important one, or one that's based on slightly incorrect assumptions). One important concept in design is the double diamond process in which you first define the problem by diverging (exploring potential problems to solve) and then converging (identifying and defining defining the most important problem), and then design the solution by again diverging (developing potential solutions) and converging (selecting and detailing the best solution):
Starting with a feature idea means skipping the first diamond. You are therefore solving some problem, but not necessarily the “right” or correctly defined one.
How should a PM go about defining the problem first then? A few tips: often, the problem is best defined in collaboration at least between the PM and the designer who will be working on the solution, but potentially also together with analysts, user researchers, engineers, or other cross-functional stakeholders. They bring valuable insights to the table, and collaborating on the problem definition builds up a real shared understanding. This is especially important for the designer, who will spend a lot of time designing the solution. If the designer hasn't fully understood and bought into the problem to be solved, it's unlikely that they will design a good solution for the problem.
It also makes sense to separate the documentation of the problem and the solution. When the problem has been defined, it should be written it down in a problem statement document or project mission or design brief. That document should cover at least the following aspects:
- What is the problem?
- Who are we solving it for?
- Why is it important to solve now?
- How is it linked to our strategic goals?
- How might we validate that we've actually solved the problem?
Keeping the problem document separate from the solution makes sure you don't retrofit the problem to fit the solution. It also leaves the door open to trying multiple solution ideas to the same problem—after all, if the first solution idea fails that doesn't mean that the problem doesn't exist anymore.
Clearly defining the problem before starting the solution design also means that the problem can be prioritized and compared with other problems that might be worth working on: based on the users that are affected and how much of a pain point the problem is, is this the most important problem to be solving now?
In summary, clearly defining the problem first, writing it down, and getting buy-in from the team and management that this is the right problem to work on is crucial for effectively working as a team and for delivering a product that solves the most pressing user problems. Skipping this step is very often the reason for failure in the first projects of new PMs.
I hope this article was helpful. If it was, feel free to follow me on Twitter where I share thoughts and articles on product management daily.