IRL Product
Published in

IRL Product

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.

  • 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.
A picture of a man holding hand with a woman, walking past another woman. The man turned back at the other woman, admiring her beauty while the woman he’s with looked annoyed.
This was me

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.

#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:

  • 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.

Quantifying impact: Reach — number of people impacted (a picture of a group of people). Intensity — the intensity of their pain (a picture of a woman with a headache). User segment — the value of the segment to the company (a picture of a crown).

#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.

#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.

#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.

#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.

Not all problems are created equal. A picture of a woman with a fire. Fire: fix it now or rebuild later. A picture of a man under a leaking pipe. Leaking roof: Slowly getting worse. A picture of a woman near a puddle. Puddle: annoying but not harmful.

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.

#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.

#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.

#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.

#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.

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.

#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.

#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.

Title: Criteria of a good solution, followed by a picture of a Venn diagram containing 3 circles. The first circle is Desirable, with user research and design input. The second circle is Viable with business input. The third circle is Feasible with engineering input.
Original source: Interaction Design Foundation
  • 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)

#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.

#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.

#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.

A chart showing 4 quadrants divided based on confidence level and importance level. The chart is pink but the quadrant of high importance and low confidence is deep red, with a caption “How can we de-risk this?”
The 2x2 Assumptions Map

#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.

#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?

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store