Getting from problem → solution
In October of 2021, a working group of some of the largest names in product released the product manifesto - 10 Principles That Underpin Product Management Today [1]. Within the list (and arguably within the first five principles), the group shares insight on how to solve problems and how to ensure that they are problems worth solving.
The first 5 principles
- Ask “why” before “what,” use data and research to reveal the opportunity.
- Derive goals from user problems and the broader team mission.
- Frame the story starting with the problem, quantify it to show the opportunity, then arrive at the solution.
- Set team goals and principles, then bring everyone together with written artifacts, frequent feedback, and communication.
- Work backward from goals, align on prioritization frameworks to support decision making, and set clear boundaries based on resourcing realities.
#2 What are we solving for? What is Success?
You may read the second principle, Derive goals from user problems and the broader team mission, and find it a bit obvious. So... why is this difficult to get right?
A few thoughts:
- We are often exclusively heads down on work, only coming up for air to focus on strategy & discovery when we've missed the mark or are at a complete loss with what to do next.
- We don't understand our users' or customers' problems well enough.
- Goals are not clearly defined and/or work is not clearly connected to a specific goal.
Let's focus on that first thought.
When we are heads down and preparing to take on the next task, it can often look like this.
often interpreted like this...
The missing information here is our assumption or hypothesis around how this 'next great thing' will solve a specific problem, or how it will help achieve a goal.
How do I fix that?
Take the time to expose hidden or implied assumptions by mapping them. Before articulating or ideating on solutions, revisit specific goals or user problems you hope to achieve or solve and share those along with the solution.
This leads nicely into the third principle, Frame the story starting with the problem, quantify it to show the opportunity, then arrive at the solution.
#3 Start with a problem
Starting with a problem can be difficult since problem solvers want to solve problems. We all want to be the heroes that take something painful and fix it. Why would we not want to jump right to the solution and save the day?
When we jump to solutions, though, it becomes easier to solve problems that are not really problems. Perhaps they are problems but just not that painful. Maybe they are problems that have other solutions that work well enough.
I've been thinking about something a lot lately after having a number of conversations with teams on the topic of defining problems. When we say "Start with a problem," what is the first thing that comes to your mind as it relates to your work?
Try this
Take a moment and think about a problem before reading on. I'd like to test a hypothesis.
...
...
...
...
... Have a problem yet?
...
...
...
...
Now let's take that problem and classify it. Look at the following diagram and see which circle your problem fits into best.
The blue circle on the left is a business problem and is probably more fixed, one of your company's 'North Stars.' The green circle on the right is more of a tactical problem, something more like an opportunity to improve your offering or service.
Which circle does your problem fit best into?
Note: I'd love to collect more information on this. If you saw this on social, please leave a comment or shoot me an email at matt@vistaly.com with "blue" or "green."
What I've noticed is that most of the time, we think in terms of "green" — the more tactical problems. There is nothing wrong with that, but it does ask the question - how do we know if this problem fits into some bigger picture? In other words, is this a problem worth solving, or worth solving now?
Here's how I like to break it down.
By creating this mapping, you are able to better understand which opportunities are connected to the big picture problems, and you can ask yourself, "Is this worth solving right now?" Let's not forget the second product principle.
Derive goals from user problems and the broader team mission.
Adding your goals into the mix is important, after landing on a solution and implementing it, how do you know if the team actually moved the needle in the right direction?
#4 & 5
After diving into 2 & 3 and working through the above thought exercises, living up to 4 & 5 should be a lot simpler.
4 - Set team goals and principles, then bring everyone together with written artifacts, frequent feedback, and communication.
5- Work backward from goals, align on prioritization frameworks to support decision making, and set clear boundaries based on resourcing realities.
There is quite a bit to unpack in #4, but one thing should be clear: visual maps are a great artifact for generating feedback, informing conversations, and building buy-in and consensus around goals.
#5 is also easier to achieve with a visual map. As for prioritization, feel free to check out this other post on "Strategic" Prioritization.
You skipped #1
This is my favorite so I left it for last.
#1 - Ask “why” before “what,” use data and research to reveal the opportunity.
- 'Why' is the best way to ensure problems are truly the 'root cause.'
- There are canvas out there that help with this. Jeff Gothelf has a great one you can learn more about here: https://jeffgothelf.com/blog/leanuxcanvas-v2/
- See https://en.wikipedia.org/wiki/Root_cause_analysis for more information on RCA.
- 'Why' allows us to test our own assumptions and curb our desire to jump straight to a solution.
- 'Why' breaks large problems down into smaller more actionable opportunities, which can then be broken down into even smaller ones.
- See ProductTalk.org/opportunity-solution-tree for more information on OSTs.
- 'Why' does a lot for us.
But we'll go slower!
It's better to go slowly in the right direction than go speeding off in the wrong direction.
~ Simon Sinek
