This is probably the most valuable question you can ask when working on anything.
A very common failure mode for founders, PMs, software teams, and people in general is to try and solve poorly articulated and unsubstantiated problems. So they end up solving non-existent problems or solving them poorly.
I think this fatal error can be easily avoided with a simple framework - "Problem Stories" organized in an "Opportunity tree".
What is a Problem Story?
User stories are a popular and useful tool to describe building blocks of a solution.
As a User X, I'd like Y, so that I can do Z
They offer more clarity and context than just saying "build Y", and that reminds, empowers and motivates the team to build the right thing.
Problem story is exactly that, but for the problem.
As a [Person/User] A, I have [slight/significant] problem with B, because of C. Supporting by data X and/or anecdotes Y.
For example:
- As a a person trying to lose weight, I have a significant problem staying motivated in any program, because it's too difficult to follow and I don't see results.
- As a high school student preparing for a test, I have a significant problem with studying all the material, because I only start the day before and there's a lot to cover.
- As a part-time rideshare driver, I have a slight problem managing my cashflow, because I only get paid one week later and have expenses every day.
As you can see, this format helps articulate the problem in a way that helps prioritize the problems and also gives enough context to solve the problem. As with a user story, making A, B, and C more grounded, granular, and specific leads to better understanding, team alignment, and solutions.
What is an Opportunity Tree?
Smaller problems are easier to solve than larger problems. So problems can be broken down into sub-problems, which have sub-problems, and so on. A tree is an expressive and engaging format to capture that. So I'm a big fan of using a living problem or opportunity tree, popularized by Teresa Torres, to organize and visualize problems.
All problems aren't equal, so you can also use colors or other visual indicators to denote the significance of the nodes and problems. This creates a roadmap of problems hypotheses for your team and stakeholders to understand, prioritize and solve.
A problem well understood is half the solution.