//pragmatic leaders

Practice Identifying and Defining Problems

Reading time
5 min
Section
Identifying and Defining Problems
5 min left0%
practice identifying and defining problems0%
5 min left
Identifying and defining problems is a crucial step in the critical thinking process. If you can't clearly articulate the problem, you won't solve it.
Talvinder Singh, from a Pragmatic Leaders session on critical thinking

Identifying and defining problems is the foundation of critical thinking for product managers. If you cannot answer what the problem actually is, you are not ready to find a solution. This step demands deliberate effort — it is not about jumping to fixes, but about deep understanding.

You will face complex challenges where symptoms obscure root causes, and your assumptions cloud your judgment. This lesson guides you through practical techniques to cut through noise and define problems clearly, so your solutions hit the mark.

The importance of problem definition

Before you solve a problem, you must first know what the problem is. Many PMs rush into brainstorming solutions without a solid problem statement. The trap is obvious: you end up solving the wrong problem or patching symptoms.

Take the time to articulate the problem. Ask yourself: What is the issue or challenge that needs to be addressed? What are the causes or contributing factors? How is this impacting users, the business, or the product?

This clarity is your compass. It aligns your team and stakeholders around a shared understanding and sets the direction for effective solutions.

Breaking problems into manageable parts

Complex problems can overwhelm. Your actual job is to break them down into smaller, more manageable pieces. This makes the root causes visible and reveals where your intervention will have impact.

Use techniques like:

  • The Five Whys: Keep asking “Why?” to peel back layers until you reach the root cause.
  • Fishbone Diagram: Visually map out potential causes grouped by categories (People, Process, Technology, etc.).
  • Pareto Analysis: Identify the 20% of causes creating 80% of the problem’s impact.

For example, if your product’s user retention is dropping, don’t stop at “Users are leaving.” Ask why: Is it a UX issue? Performance? Pricing? Customer support? Breaking the problem down helps prioritize where to focus.

// thread: #product-management — Breaking down a retention problem
Neha (PM)Retention dropped 15% last quarter. First step: let’s list all possible reasons.
Rahul (Data)Data shows session length decreased — maybe onboarding is confusing.
Meera (Support)We got 30% more support tickets related to payment failures.
Neha (PM)Payment failures could be a root cause. Let's dig deeper with the five whys.
Why are payments failing? Because of gateway timeouts. Why timeouts? Because of increased traffic load.

Recognizing and challenging biases

Your assumptions and biases shape how you see the problem. They can cloud your judgment and make you miss the real issue. Be intentional about identifying and questioning them.

Common biases include:

  • Confirmation bias: Looking only for evidence that supports your existing beliefs.
  • Anchoring: Relying too heavily on the first piece of information you receive.
  • Availability bias: Overemphasizing information that is most recent or vivid.

Example: If you believe users churn because of price, you might ignore data showing that feature gaps are the bigger driver.

Ask yourself:

  • What assumptions am I making about this problem?
  • Have I checked these assumptions against data or user feedback?
  • Could there be alternative explanations?
// scene:

Product strategy meeting at a Series A fintech in Mumbai

You (PM): “We assume users drop off due to pricing. But have we validated that with data?”

Ravi (Growth Lead): “Our surveys show feature requests are the top complaint.”

You (PM): “Then our problem statement must shift from pricing to feature completeness.”

This moment of challenging assumptions realigned the team's focus.

// tension:

Assumptions about pricing risked misdirecting product development.

Gathering data and multiple perspectives

Problem definition is not a solo activity. You must gather data and listen to different stakeholders to get a full picture.

  • Talk to users and frontline teams (support, sales).
  • Analyze quantitative data (usage metrics, drop-off points).
  • Review competitor offerings and market trends.
  • Consult internal teams (engineering, marketing, leadership).

Triangulation reduces blind spots and uncovers hidden causes. It also builds consensus around the problem statement.

Crafting a concise problem statement

Once you have the inputs, define the problem in a clear, concise statement. This becomes your north star for solution design.

A good problem statement is:

  • Specific and focused
  • User-centered
  • Actionable

Example: Instead of "Users are unhappy," say "New users drop off during onboarding due to confusing navigation on the payment screen, causing a 20% decrease in conversion."

Refine your statement as you gather more data and insights. Problem definition is iterative.

Field exercise: The Daily Annoyance Diary

// exercise: · 15 min
Daily Annoyance Diary
  1. Spend a day noting down small frustrations or inefficiencies you or your team encounter in daily work or product use.
  2. For each annoyance, write down:
    • What happened?
    • Why it was frustrating or problematic?
  3. Use the Five Whys technique to identify root causes.
  4. Craft a one-sentence problem statement for the top 2 annoyances.

This exercise builds your problem identification muscle by turning everyday issues into clear problem definitions.

From the field: Why problem definition matters more than solutions

Common pitfalls in problem identification

PitfallDescriptionIndian Context Example
Jumping to solutionsSkipping problem analysis and pushing ideasA fintech builds a new KYC flow without understanding user drop-off reasons
Defining symptoms as problemsTreating surface issues as root causesCustomer complaints about slow app blamed on UI, ignoring backend latency
Ignoring biasesLetting assumptions drive problem framingAssuming rural users prefer feature X without user research
Limited perspectivesRelying on a single data source or stakeholderProduct team ignoring sales feedback on competitor moves

Avoid these traps by following structured problem definition steps.

Judgment exercise: Defining the real problem

// learn the judgment

You are PM at a Mumbai-based Series B SaaS startup. Customer support tickets have doubled in the last month, mostly complaining about product crashes. Engineering says it’s a backend scalability issue. Marketing says it’s a perception problem due to recent negative reviews. Leadership wants a quick fix.

The call: How do you identify and define the real problem before proposing solutions?

Your reasoning:

// practice

You are PM at a Mumbai-based Series B SaaS startup. Customer support tickets have doubled in the last month, mostly complaining about product crashes. Engineering says it’s a backend scalability issue. Marketing says it’s a perception problem due to recent negative reviews. Leadership wants a quick fix.

Your task: How do you identify and define the real problem before proposing solutions?

your reasoning:

0 chars (min 80)

Meeting scene: Aligning on problem definition

// scene:

Weekly product sync at a mid-stage EdTech startup in Bangalore

You (PM): “Support tickets have increased 40% in the last two weeks. Engineering, what does the data show?”

Anjali (Eng Lead): “Most errors are timeout exceptions during video playback.”

Karthik (Customer Success): “Customers complain about freezing, especially on low bandwidth.”

You (PM): “So the problem is video playback instability on low bandwidth connections causing user frustration and support load.”

Anjali (Eng Lead): “Yes, and we need to optimize streaming for these conditions.”

You (PM): “Let's define success metrics: reduce playback errors by 50% in 4 weeks and drop related tickets by 30%.”

Clear problem definition aligned the team and set measurable goals.

// tension:

Without alignment, teams risk working on different assumptions and wasting effort.

Where to go next