Principles of Product Management: Problem Space vs Solution Space (Fall in Love with the Problem, Not the Solution)

Problem Space vs Solution Space (Fall in Love with the Problem, Not the Solution)

Problem Space vs Solution Space: Fall in Love with the Problem, Not the Solution

What This Is

The Problem Space is where you deeply understand user needs, pain points, and jobs-to-be-done (JTBD) before jumping to solutions. The Solution Space is where you design, build, and iterate on features. Falling in love with the problem (not your first solution) prevents wasted effort on shiny but misaligned features.
Example: Slack didn’t start as a chat app—it began by solving the problem of fragmented team communication (email, IRC, Skype) for game developers. Only after validating the pain did they build the solution (a unified messaging platform).

Key Terms & Frameworks

• Problem Space: The domain of user needs, pains, and desired outcomes. Ask: “What problem are we solving, and for whom?”
• Solution Space: The domain of features, designs, and implementations. Ask: “How might we solve this problem?”
• Jobs-to-be-Done (JTBD): A framework to uncover the “job” users “hire” a product to do. Formula: “When [situation], I want to [motivation] so I can [outcome].”
• Problem Statement Template: “[User segment] struggles to [pain point] because [root cause], leading to [negative outcome].” (e.g., “Freelancers struggle to track invoices because tools are fragmented, leading to late payments.”)
• Opportunity Solution Tree (OST): A visual framework (from Continuous Discovery Habits) to map problems → outcomes → solutions. Steps: 1) Define desired outcome, 2) Identify opportunities (problems), 3) Brainstorm solutions, 4) Prioritise.
• ICE Score: Impact × Confidence × Ease – used to prioritise problems (not solutions). Impact = How much it moves the needle; Confidence = Evidence strength; Ease = Effort to validate.
• Double Diamond (Design Council): A process model: Discover (problem space) → Define (problem) → Develop (solution space) → Deliver (solution).
• Solution Blindness: Cognitive bias where teams fixate on a solution before validating the problem. Correction: Force yourself to articulate the problem in writing first.
• Problem-Solution Fit: Evidence that a problem exists and users care enough to pay for a solution. Test with: Surveys, interviews, or fake-door tests.
• Solution-Market Fit: Evidence that your solution effectively solves the problem and users adopt it. Test with: MVP, usability tests, or A/B tests.
• Fake-Door Test: A low-effort way to validate demand by offering a “solution” (e.g., a button or landing page) before building it. Metric: Click-through rate (CTR).
• North Star Metric (NSM): The single metric that best captures the core value your product delivers. Example: Airbnb’s NSM = “Nights booked” (not “users” or “revenue”).

Step-by-Step / Process Flow

1. Define the Problem Space
2. Action: Start with a hypothesis (e.g., “Small business owners waste 10+ hours/month on manual expense tracking”).
3. How: Use JTBD interviews (ask “Tell me about the last time you [did X]”) or surveys (e.g., “On a scale of 1–5, how painful is [problem]?”).

4. Output: A problem statement and user segment (e.g., “Freelancers with 5+ clients struggle to track invoices because tools are fragmented, leading to 20% late payments.”).

5. Validate the Problem

6. Action: Test if the problem is real, frequent, and painful enough to warrant a solution.
7. How:
   • Quantitative: Survey 50+ users (e.g., “How often do you experience [problem]?”).
   • Qualitative: Conduct 5–10 problem interviews (ask “Walk me through the last time this happened”).
   • Behavioral: Analyze support tickets, search queries, or churn reasons (e.g., “30% of churned users cite ‘difficulty tracking expenses’”).

8. Output: ICE score for the problem (e.g., Impact = 8, Confidence = 7, Ease = 5 → ICE = 28).

9. Map Opportunities (Not Solutions)

10. Action: Use an Opportunity Solution Tree (OST) to break the problem into sub-problems.
11. How:
    • Start with the desired outcome (e.g., “Reduce time spent on expense tracking by 50%”).
    • List opportunities (e.g., “No single source of truth for expenses,” “Manual data entry is error-prone”).
    • Avoid: Jumping to solutions (e.g., “Build an AI receipt scanner”).

12. Output: A prioritised list of opportunities (e.g., “Top opportunity: ‘No single source of truth’”).

13. Explore Solutions (Solution Space)

14. Action: Brainstorm multiple solutions for the top opportunity.
15. How:
    • Crazy 8s: Sketch 8 solutions in 8 minutes (time-box to avoid over-engineering).
    • Assumption Mapping: List assumptions (e.g., “Users will link their bank accounts”) and test them (e.g., fake-door test).
    • Prototype: Build a low-fidelity mockup (e.g., Figma) or Wizard of Oz (manual behind-the-scenes work).

16. Output: 2–3 validated solution hypotheses (e.g., “A mobile app that auto-categorizes expenses”).

17. Test Solutions (Before Building)

18. Action: Validate solutions with low-effort experiments.
19. How:
    • Fake-Door Test: Add a button (“Auto-categorize expenses”) and measure CTR.
    • Usability Test: Watch 5 users try a paper prototype (e.g., “How would you use this to track an expense?”).
    • Concierge MVP: Manually solve the problem for 10 users (e.g., “We’ll categorize your expenses for you this week”).

20. Output: Solution-Market Fit signal (e.g., “60% of users clicked the fake-door button”).

21. Prioritise and Build

22. Action: Use RICE or ICE to prioritise solutions.
23. How:
    • Score each solution on Reach, Impact, Confidence, Effort (RICE).
    • Example: “Auto-categorize expenses” (RICE = 40) vs. “Manual entry” (RICE = 20).
24. Output: Roadmap with 1–2 solutions to build first (e.g., “MVP: Auto-categorize + manual override”).

Common Mistakes

1. Mistake: Jumping to solutions before validating the problem.

2. Correction: Force yourself to write a problem statement before brainstorming solutions. Why: 80% of product failures stem from solving the wrong problem (SVPG).

3. Mistake: Assuming your problem is the user’s problem.

4. Correction: Conduct problem interviews (not solution interviews). Why: Users often describe symptoms, not root causes (e.g., “I hate this app” → “I can’t find my invoices”).

5. Mistake: Prioritising solutions (not problems) with frameworks like RICE.

6. Correction: Use ICE to prioritise problems, then RICE to prioritise solutions. Why: RICE’s “Reach” is meaningless if the problem isn’t validated.

7. Mistake: Building an MVP before testing the solution.

8. Correction: Run a fake-door test or concierge MVP first. Why: An MVP is expensive; validate demand before building.

9. Mistake: Confusing “user feedback” with “problem validation.”

10. Correction: Ask “Why?” 5 times to uncover root causes. Why: Users often request features (e.g., “Add a dark mode”) that don’t solve their real problem (e.g., “I can’t find my data at night”).

PM Interview / Practical Insights

1. Interview Question: “How would you decide whether to build Feature X or Feature Y?”
2. Trap: Answering with “I’d ask users” or “I’d use RICE.”

3. Better Answer: “First, I’d validate which problem is more painful for our target segment. For example, if Feature X solves ‘users can’t find their invoices’ (ICE = 30) and Feature Y solves ‘users want a dark mode’ (ICE = 10), I’d prioritise X. Then, I’d test solutions with fake-door tests before building.”

4. Stakeholder Pushback: “We need to build [solution]—it’s obvious!”

5. Trap: Agreeing without evidence.

6. Better Answer: “Let’s test that assumption. I’ll run a fake-door test this week to see if users actually want this. If the CTR is >20%, we’ll prioritise it.”

7. Tricky Distinction: Problem Space vs. Solution Space in Roadmaps

8. Trap: Roadmaps listing features (solution space) instead of outcomes (problem space).

9. Correction: Write roadmap items as problems to solve (e.g., “Reduce time spent on expense tracking”) not features (e.g., “Build an AI scanner”).

10. Leading vs. Lagging Indicators

11. Trap: Measuring success with lagging indicators (e.g., “Revenue”) instead of leading indicators (e.g., “% of users who auto-categorize expenses”).
12. Correction: Tie North Star Metric to leading indicators (e.g., “Nights booked” → “% of users who book a second stay”).

Quick Check Questions

1. Scenario: Your team wants to add a “social feed” to your productivity app to increase engagement. NPS drops in usability tests because users find it distracting. How do you decide?

2. Answer: Validate the problem first. Run a survey to ask users, “How often do you feel distracted while using our app?” If the problem isn’t painful, deprioritise the feature. Why: Engagement ≠ value; don’t solve a problem that doesn’t exist.

3. Scenario: A stakeholder insists on building a “chatbot for customer support” because “everyone’s doing it.” What’s your next step?

4. Answer: Map the problem space. Ask, “What’s the top support issue users face? How much time do they spend resolving it?” Then, test demand with a fake-door test (e.g., “Click here to chat with our AI assistant”). Why: Avoid solution blindness—don’t build a chatbot if users prefer self-service FAQs.

5. Scenario: Your MVP for a “smart expense tracker” has low adoption. Users say, “It’s too complicated.” What do you do?

6. Answer: Return to the problem space. Conduct JTBD interviews to uncover why users track expenses (e.g., “To avoid late fees” vs. “To file taxes”). Then, simplify the solution to match their real job. Why: Low adoption = misaligned problem-solution fit.

Last-Minute Cram Sheet

1. Problem Space = Needs, pains, JTBD. Solution Space = Features, designs, implementations.
2. JTBD Formula: “When [situation], I want to [motivation] so I can [outcome].”
3. Problem Statement Template: “[User] struggles to [pain] because [root cause], leading to [outcome].”
4. Opportunity Solution Tree (OST): Outcome → Opportunities → Solutions → Prioritise.
5. ICE Score = Impact × Confidence × Ease (for problems). RICE Score = Reach × Impact × Confidence / Effort (for solutions).
6. Fake-Door Test: Measure CTR before building. ⚠️ Don’t build without testing demand!
7. Solution Blindness: Fixating on a solution before validating the problem. ⚠️ Always write the problem statement first.
8. Problem-Solution Fit = Evidence the problem exists + users care. Solution-Market Fit = Evidence the solution works + users adopt.
9. North Star Metric (NSM): The one metric that captures core value (e.g., “Nights booked” for Airbnb).
10. Double Diamond: Discover → Define (problem space) → Develop → Deliver (solution space). ⚠️ Don’t skip the first diamond!