A simple framework for Problem Solving
Nov 2, 2022 . 5 min read . 75 views
Introduction
The first thing you should do while trying to solve a problem is to forget about the solution and return to the problem.
Defining and documenting a clear problem statement helps provide much-needed clarity and alignment that you will require in the next stage when actually designing solutions for the problem. This helps you avoid solving the wrong problem.
Once you have a well-written problem statement, the next step is to agree on it with all the stakeholders. This step is very important to avoid wasting a lot of time in back and forths.
Writing A Killer Problem Statement
A good problem statement should be short and ideally cover the what and the why. e.g: Lyft drivers are cancelling rides too often because the passengers are too far away. vs User, growth is slowing.
In general as a PM you will encounter 2 types of problems:
- User Problems (These are the problems users face while interacting with your product or in general) e.g: Travelers want to find high quality non-touristy things to do
- Business Problems (These are the problems business is facing w.r.t product) e.g: Users are dropping off at too high a rate at the final step of the signup flow
User Problems
To understand broader user level problems deeper analysis of user behavior and needs is required.
Dave Bailey’s needs narrative template is a great resource here to think about user needs and problem in depth. It covers the different aspects that need to be defined to get a complete understanding of the problem.
For ___[target audience], it’s a constant challenge to ___[general problem]. Every ___[time period], these people ___[perform a key activity] in order to ___[achieve a primary goal]. This is especially true if you’re a [niche].
The main problem they face is ___[primary functional problem relating to activity] which leads to ___[bad/worst case outcomes]. Today, their best option is ___[substitutes], but of course, they ___[the most common complaints of each substitute]. With ___[key trend], the problem will only get worse over time.
If only there was an easier/better/cheaper way to ___[perform a key activity], then customers could ___[quantifiable impact on their primary goal] which would lead to ___[positive outcomes/emotions]. With ___[number of potential customers], there is a clear opportunity to meaningfully impact a huge number of people.
Business Problems
To understand business problems a deeper understanding of how the user is currently interacting with your product is required.
Building a User Research Plan can also be very helpful while solving the business problems.
The following template from Lenny is great to think about business problems.
Additional Notes
-
Focus on the problem and not on the solution e.g: Users are dropping off at too high a rate at the final step of the signup flow. vs Build a loyalty program
-
Play the devil’s advocate when answering why Try to come up with all the reasons for why this is not a real problem. This helps in getting an additional 360-degree perspective.
-
Collect both Qualitative and Quantitative data points Try to find as many data points as possible that suggest the problem is real. However, focus on Quality over quantity. (Look for leading indicators instead of lagging ones.)
-
Identify an overall goal to measure success Pick a quantifiable goal to measure success. A good goal has a tangible target and is time-boxed. e.g: 10% more signups within 2 months.
Align On The Problem Statement
Once you have defined the problem statement the next step is to align with the team.
It is extremely important for everyone to have a clear understanding of the problem before entering the solution phase.
Here is a simple timeline to follow:
- Take a first stab at the problem doc individually
- Share with the team for comments
- Have a meeting to discuss concerns and get the first alignment
- [Optional] Share with external stakeholders to get comments and alignment
- Review the problem statement one last time with the team [Ideally have a 1-week gap here from the last meeting. This gives everyone enough time to have thought deeply about the problem]
- Kick off the solutioning phase with the design and engineering teams.
Whenever In Doubt Come Back To The Problem
Often, once we start building the solution we lose sight of the problem. This causes us to get distracted and waste time on features and ideas that do not solve the problem that we set out to solve.
Hence, even in the solutioning phase, it is important to frequently review and update [if needed] the problem statement.
Here are a few things to ensure the team is always aligned on the problem statement:
- Start all design/engineering review meetings by reviewing the problem statement
- Start all sprints by reviewing the problem statement
- Start all stakeholder update meetings by reviewing the problem statement
- If needed in case of long projects you can also set up bi-weekly meetings just to review the problem statement with the entire team.