The problem-solver’s playbook: 17 questions to sharpen your thinking
tl;dr Stop falling in love with your problem, and definitely don’t fall in love with your solution.
If somebody had asked me years ago to distil product management in two words, I’d have answered: solving problems. Isn’t that our main job? Find out what the customer’s problems are and solve them. Bam, job done, give me the applause I deserve!
Now, the problem with being passionate about problem-solving was that when I saw a problem, my instinctive reaction was “How can I solve it?” I was a problem slut: I was attracted too easily to too many problems. That means:
- I usually ended up burning out quickly trying to solve all the problems myself.
- I also often felt frustrated when I couldn’t get enough buy-ins and resources to solve the problems.
- And, worst of all, I got bored easily when executing the solution, as I have already fallen in love with another problem.
After many episodes of burnout and frustration, I learned my lesson. If you ask me now what my job is, I’ll answer: multiplying value. That means that I only work on problems worth solving, in a way that delivers the optimal value for the customers.
By focusing on multiplying value rather than solving problems, one actually becomes a better problem solver.
Here are 17 explorative questions to help you sharpening your thinking, divided into 3 sections.
Section 1: Assessing if your problem is worth solving
This section is useful if you already have a problem in mind. You might come across it from reading customer feedback, talking to the support team, or watching a customer recording. Using the dating analogy, this is the part where you make sure your crush is worth falling in love with.
#1: Is this problem merely a symptom of a bigger problem?
It’s always worth taking the time to ask the 5-Whys and make sure that you get to the addressable root cause and not just solve the most visible symptom.
One simple example: If a sign up to a certain feature is low and you see that there are some usability issues in the form, it’s easy to jump straight and fix those form issues. (Or worse, you see the usability issues first, and then you dig the sign up number to confirm that this is a problem. That’s a confirmation bias right there!)
Meanwhile, the sign up might be low because the feature isn’t bringing adequate value (quality issue), or it doesn’t bring the value customers need (product-market fit issue). This is why it’s important to dig qualitative and quantitative insights to get the full picture.
#2: How impactful is this problem for the customers?
The answer to this question isn’t as simple as ‘nice to have’ or ‘must have’. There are three dimensions you need to consider in assessing the impact of a problem:
- Reach: the number of customers this problem is impacting. This is a real, objective number.
- Intensity: how deep the pain caused by this problem is. This one is a slightly arbitrary scale of low-medium-high, or you can use a scale of 1–10, up to you. As far as possible, the assignment of the score should be based on user research.
- User segment: who are the customers impacted by this problem. Some of your customers are more valuable to the business than others. You can use a multiplier here, e.g. segment A and B are 1x in value, but segment C has 2x value.
Impact = reach * intensity * user segment
Thinking about these three dimensions separately allows you to assess the importance of a problem more comprehensively.
#3: How will solving this problem benefit the company?
Guess what, what the customers need and what the company wants aren’t always aligned. I was that bright-eyed, idealistic young woman trying to solve customers’ problems when the company couldn’t care less because it wasn’t profitable for them to do so. After all, companies are created to make a profit by serving customers’ needs.
I have one trick to tip this one in your favor: think about how this problem can harm the company in the long term. Maybe there’s no clear short-term incentive to solve this issue for the business, but over time, it can erode the trust in your company and hurt long-term profitability.
#4: Does it align with the company/product’s long-term vision and strategy?
Even when a problem is impactful for the customers and profitable to solve for the company, it might not align with its vision. A simple example is if the problem is on the web, while the company wants to focus on the app.
Saying ‘no’ to an important problem when it doesn’t align with the company/product’s vision is paramount to maintaining focus. To quote Michael Porter, ‘The essence of strategy is choosing what not to do.’
#5: What do you need to deprioritize to work on this?
You only have a finite resource and when you work on a certain problem, it means you’re not working on other problems. That’s your opportunity cost: the potential loss from a missed opportunity.
Think about the next thing(s) you’re going to work on if you’re not working on this problem, and make sure that you can afford that cost.
#6: What happens if you do nothing?
Thinking about the cost of delay, or the cost of doing nothing, is a powerful exercise to do. You also get to see that some problems are like a fire — you either have to solve them now or rebuild later. Other problems are like a leaking roof — it gets worse and worse slowly until the whole roof falls down. Some other problems are like a puddle of water — it’s annoying but it doesn’t harm anyone as long as everyone knows to walk around it.
Section 2: Finding a problem that matters
Going back to the dating analogy — you know what wise men say, ‘Being single is great because you get to think about what you really want in your partner!’ Similarly, when you’re not thinking about a particular problem, you have more space to think above and beyond.
This is also what usually differentiates a more junior and senior product managers. Senior PMs would identify and scope opportunities to make the product 10x, instead of just 10%, better.
#7: What is the customer’s job-to-be-done?
Jobs-to-be-done (JTBD) framework prompts you to think wider than your product usability problems. When a user flies from London to Dublin, their goal is not to ride a plane, it’s to meet their colleagues. If you’re an airline company, your threat of substitution isn’t just fellow airlines, it’s also Zoom and Google Meet.
Understanding the reason your customers ‘hire’ your product gives you a clear direction to improve your product. Airbnb users are looking to have a nice holiday, not just a place to stay — hence Airbnb Experience was born.
#8: How can I build a deeper moat for my product?
A moat is a deep pool of water surrounding a castle — it serves as a way to defend the castle against an attack. Building a moat in business or product means making it hard for new entrants or competitors to steal your customers.
One of the most popular way to build a moat is creating network effects: where increased numbers of people using your product increase the value of your product for each individual.
Network effects are obvious in products like social media(which is useless if you have no friends, or nobody to follow) or marketplace (which again is useless if the customers can’t find the product/service they need, or the sellers don’t find any buyers). But you can also implement network effects in other products by making an activity that’s typically done on your own (e.g. exercising or investing) and adding a social element to it.
Network effect is just one way to build a moat. You can also deter customers from switching by creating emotional attachment to your product, patenting your technology, etc. Recommended reading: building growth moats without network effect.
#9: If a new hotshot founder creates a pitch deck to disrupt my industry, what will they say about my company/product?
Your company/product might have been created a few years ago with the same ambition: to disrupt a broken industry. You named 50-year-old companies as the enemy and pitched your solution as the revolutionary savior.
The irony is that you can easily slide into being that old enemy in just a few years time if you stop innovating.
The society is evolving faster than ever and the bar is raised constantly. If you don’t disrupt your own product, somebody else will.
#10: What future situation can make my product irrelevant?
The pandemic came as a blow to many companies. Products relying on people traveling or gathering suddenly became paralyzed, and they had to pivot quickly to online events or other means to make money.
Pandemic at the scale of Covid-19 is probably a once-every-century occurrence, but it doesn’t mean there won’t be other situations that make your product irrelevant. Regulatory change is one possible scenario.
It also doesn’t have to be an overnight revolutionary change. A slow evolution such as the rise of renewable energy, electric vehicles, plant-based meat alternatives, job sharing, etc can impact your product. Keep a lookout because the future is already there, it’s just not evenly distributed.
Section 3: Discovering the best solution
When people talk about product discovery, often the focus is on problem discovery. The old adage of ‘PM owns the problem, engineers own the solution’ could also make PMs reluctant to go into the solution space.
I totally agree that a PM shouldn’t decide on, or, God forbid, specify the solution in a silo. But a PM should still be driving the solution discovery process, by amassing the expertise of engineers, designers, data scientists, and the stakeholders.
#11: How much is our appetite to solve this problem?
To put simply, how much resources do you want to allocate? How long do you want the designers and engineers to spend on this? A task can expand to fill the time and space it’s been given, as the Parkinson’s law suggested.
It’s important to clarify the boundaries early and communicate them to the team.
#12: What is feasible to build?
A good solution is desirable by the users, viable for the business, and feasible to build with the resources and constraints you have.
Assuming that you’ve done your homework from question 1–11, I assumed that your solution is likely desirable and viable. The feasibility aspect is the one you need to figure out now, by leveraging the expertise of your engineers (and other technical function such as data scientists).
The importance of this discovery can’t be overstated. There’s a world of difference between an array of solutions. For example, my team at Bulb was exploring giving energy savings advice on the app. The solution can be an array of:
- Creating a banner linking to a blog post containing generic advice
- Breaking down the advice and making it look ‘native’ to the app
- Personalizing the advice by only showing the ones applicable to the users (e.g. don’t say ‘improve your house’s insulation’ if the house is a new-built)
- Personalizing the advice by showing the saving amount (e.g. by doing this, you could save £20 / year)
The third and fourth solution requires user data that we might not have, so it might not be feasible for now. Equipped with this knowledge, you can make a decision e.g. build the second solution now, while doing some research on the value of #3 and #4 to see if it’s worth building. Which brings me to the next point: diminishing return.
#13: Where is the point of diminishing return?
The most complex solution is almost certainly the most expensive one to build. The good news is, your customers might not need it! A solution that takes half the time to build might perform 80% of the job — diminishing return principle might apply here.
You can test this by building an MVP version of the solution, ship it to a small % of users, and measure the impact. Improve the solution via small iterations rather than spending months and months building the perfect solution.
#14: What would the Red Team say about this solution?
The ‘Red Team’ is an exercise to look at your solution as if you’re the enemy, biggest critic or competitor. The job of the Red Team is to poke holes in the solution and challenge you with everything that could go wrong. It’s a useful exercise because your actual competitor might do the same thing later.
You can also imagine the most cynical press review you might possibly get. Especially if your company is under quite a lot of spotlight, this might be a completely feasible scenario. (I still remember the time the press wrote the headline ‘Facebook asks users for nude photos’…)
#15: What is the riskiest assumption we have here? How can we de-risk it?
Solutions are based on assumptions — that customers want to do certain actions, that engineers can build something in a certain way, etc. Your team might have different confidence level in those assumptions. And each assumption also has different level of importance in making your solution works.
Try to map out those assumptions in a 2x2 scale of confidence and importance so you can identify which assumptions you need to de-risk.
#16: What is the smallest chunk of value we can deliver?
As much as possible, I avoid building for months and releasing a fully-fledged feature in a big bang. No matter how much research and testing you’ve done, the true test of a feature success is when it’s launched to the wild. Time lag between research and launching increases the chance of changes in requirements, trends, and appetite.
For that reason, I always advocate for phasing your build plan. Focus on releasing small chunks of value and iterate.
This is also important when your feature is solving an apparent pain point. Your customers will appreciate a solution that alleviates 60% of their problem now, rather than something that alleviates 100% of the problem but in a year’s time.
#17: Am I the best person to solve this?
You might be thinking — What? After going through 16 questions to refine this problem and define the solution, you wanted me to give this to someone else?
Yes, particularly if your company is scaling up quickly and you’re becoming a more senior member of the team. Don’t be afraid to give away your Legos — that’s how you actually grow. By empowering a more junior team member to work on this problem, you get to a) learn new skills (e.g. delegating, mentoring) and b) free up your time to do more impactful work.
👋 Hi, I’m Debbie. I’ve been building products and solving customer problems in tech companies for over a decade. I write about how a PM can bring 10x value to their company, not just 10% improvement. Stay ahead of the game and get insights delivered straight to your inbox — subscribe to my newsletter today!
