luvv to helpDiscover the Best Free Online Tools
Topic 1 of 12

Problem Discovery And Context

Learn Problem Discovery And Context for free with explanations, exercises, and a quick test (for Business Analyst).

Published: December 20, 2025 | Updated: December 20, 2025

Table of Contents

Why this matters

Business Analysts are often handed solutions before the real problem is clear. Strong problem discovery helps you avoid building the wrong thing, wasting time, budget, and stakeholder trust. You will use it to frame interviews, choose the right data to explore, and define requirements that actually solve business pain.

  • Clarify whether the issue is truly a problem, a symptom, or a constraint.
  • Align stakeholders who see the situation differently.
  • Translate vague complaints into measurable goals and decision-ready context.

What this subskill covers

Problem Discovery and Context means uncovering the true need, mapping who is affected, and documenting the environment where the problem lives: processes, systems, data, constraints, and success criteria.

What you'll be able to do
  • Turn a vague request into a validated problem statement.
  • Separate symptoms from root causes.
  • Capture constraints and assumptions explicitly.
  • Build a simple context map that others can review quickly.

Concept explained simply

Think of the problem as a leaky bucket:

  • Symptoms: The water on the floor.
  • Root cause: The hole in the bucket.
  • Constraints: Duct tape, time, and rules you must obey while fixing.
  • Context: Where the bucket sits, who uses it, what else is connected.

Your job: confirm there's actually a hole (and where), not just mop the floor.

Mental model: The Discovery Loop

  1. Trigger: What event/request kicked this off?
  2. Symptoms: What is observed? Where/when does it happen?
  3. Impact: What does it cost (time, risk, money, quality)?
  4. Root cause exploration: Ask "Why?" until causes stabilize.
  5. Stakeholders: Who feels the pain, who decides, who does the work?
  6. Goals & measures: What good looks like and how we’ll know.
  7. Constraints & assumptions: Limits and beliefs to validate.
  8. Context map: People, process, data, systems, and rules around it.
Use this one-page template during discovery
  • Problem statement: [Actor] struggles with [issue] when [situation], causing [impact].
  • Goals: [Goal] measured by [Metric].
  • Stakeholders: [List: R (Responsible), A (Accountable), C (Consulted), I (Informed)].
  • Constraints: [Time, budget, policy, tech, data].
  • Assumptions to verify: [List].
  • Context map sketch: [Process steps + systems + data touchpoints].

Framework you can apply today

  1. Collect triggers and symptoms
    • Prompt: "What happened that made this urgent now?"
    • Log exact examples: where, frequency, volume.
  2. Run a fast cause pass
    • Use 5 Whys or fishbone categories: Process, People, Tech, Data, Policy.
  3. Stakeholder sweep
    • Identify decision-maker, users, customers, operations, finance, risk/compliance, IT owner.
  4. Define goals and measures
    • Outcome metric (e.g., cycle time), leading indicator (e.g., queue length).
  5. Capture constraints and assumptions
    • Timeboxes, must-use systems, regulatory musts, capacity limits.
  6. Draft a context map
    • Process swimlanes, systems boxes, data flows, key rules at each step.
  7. Playback and align
    • Review the one-page summary for sign-off on problem, not solution.

Worked examples

Example 1: "We need a dashboard"

Trigger: Sales VP requests a dashboard.
Symptoms: Late monthly numbers, disputes about "latest" figures.
Why loop: Why dashboard? To see real-time sales. Why? Reps over-commit inventory. Why? They don't see stock; ERP updates nightly.
Root cause: Nightly ERP sync hides current inventory.
Goal: Reduce stockouts by 30%; measure: stockout incidents/week.
Constraint: ERP batch window cannot change this quarter.
Context: CRM, ERP, manual spreadsheet. Decision-maker: VP Sales.
Discovery outcome: Instead of a generic dashboard, implement intra-day inventory view for sales, plus alerting.

Example 2: "Customers abandon checkout"

Symptoms: 68% drop-off on payment step (spikes on mobile).
Why loop: Why drop-off? Card declines and form errors. Why declines? AVS mismatch on saved addresses. Why mismatch? Address normalization differs between app and gateway.
Root cause: Inconsistent address formatting before gateway call.
Goal: Increase payment success from 86% to 93%.
Constraints: Must keep PCI scope unchanged.
Context: Mobile app, payment gateway, address service.
Discovery outcome: Normalize address using gateway's spec before submit; A/B test.

Example 3: "Support backlog is huge"

Symptoms: Tickets open >10 days, many password resets.
Why loop: Why resets? Self-service flow confusing after MFA rollout.
Root cause: MFA edge cases not covered for travel users.
Goal: Cut reset tickets by 60%; measure: weekly ticket count.
Constraints: Security policy non-negotiable.
Context: IdP, email, helpdesk tool.
Discovery outcome: Add travel exception flow + clearer copy; reduce backlog drivers, not just hire more agents.

Techniques you can use

  • 5 Whys: Ask why until answers repeat or hit a constraint.
  • Event storming lite: Put key events on a timeline to spot bottlenecks.
  • Stakeholder RACI sweep: Ensure decision-maker and implementers are identified.
  • Impact mapping: Connect goals to actors, impacts, and deliverables.
  • Context mapping: Draw people, process, systems, and data. Keep it simple.
Conversation starters you can copy
  • "What happened recently that made this a priority?"
  • "Show me the last time it failed, step by step."
  • "If we fix only one part, which metric should move first?"
  • "What is absolutely non-negotiable (policy/tech/time)?"
  • "Who else touches this before or after your step?"

Exercises (do these now)

These mirror the two exercises below in the Exercises section. Use the checklists as you work.

Exercise 1: 5 Whys + Context Map (Scenario: Late invoices)

  1. Write the initial symptom.
  2. Ask "Why?" at least 4 times, logging evidence for each answer.
  3. List stakeholders (R, A, C, I).
  4. Draft goals and measures.
  5. Sketch a simple context map (process + systems + data).
  • [ ] Symptom captured with concrete example
  • [ ] 5 Whys complete and plausible
  • [ ] Stakeholders listed with roles
  • [ ] Goal has a metric and target
  • [ ] Context map includes upstream/downstream
See a sample output

Symptom: Invoices sent 10 days late after shipping.
Why chain: 1) Waiting for shipping confirmation. 2) Confirmation delayed by manual batch. 3) Batch held until QA approves. 4) QA waits for signature scan. 5) Scanner breaks twice/week.
Stakeholders: Ops (R), Finance (A), Warehouse (C), IT (C), Customers (I).
Goal: Send invoices within 2 days; measure: avg days-to-invoice.
Context map: WMS -> Scan -> QA -> ERP -> Email gateway.

Exercise 2: Stakeholder Sweep + Assumptions Log

  1. From the same scenario, list all stakeholder groups.
  2. For each, write 1 pain, 1 goal, 1 constraint.
  3. Log at least 5 assumptions and mark how you will validate them.
  • [ ] Decision-maker identified
  • [ ] Implementers identified
  • [ ] External dependencies noted
  • [ ] 5+ assumptions with validation method

Common mistakes and how to self-check

  • Mistake: Solving for symptoms. Self-check: Does your measure change if you only mask the symptom?
  • Mistake: Missing decision-maker. Self-check: Who can approve scope and accept trade-offs?
  • Mistake: Ambiguous goals. Self-check: Can you express the target with a number and timeframe?
  • Mistake: Over-detailed maps. Self-check: Can a new teammate grasp it in 2 minutes?
  • Mistake: Hidden constraints. Self-check: List time/budget/policy/tech limits explicitly.
Quick self-audit
  • Problem statement ≤ 2 sentences, includes impact.
  • At least 2 metrics: outcome and leading indicator.
  • RACI has a named Accountable person.
  • Assumptions marked as "To Validate" with method (data, interview, test).

Practical projects

  • Shadow a process for one hour and produce a one-page context map and problem statement. Share for feedback.
  • Take an old project post-mortem and reconstruct the discovery loop. Mark where earlier discovery would have helped.
  • Run a 30-minute discovery workshop with 3 stakeholders using the template. Capture decisions and open questions.

Who this is for

  • Business Analysts, Product Analysts, and junior PMs needing clearer problem framing.
  • Engineers or designers stepping into discovery meetings.
  • Anyone preparing to gather requirements with multiple stakeholders.

Prerequisites

  • Basic understanding of stakeholder roles and business processes.
  • Comfort talking to users and reading simple process diagrams.
  • No advanced tools required; paper or a whiteboard is enough.

Learning path

  1. Learn to capture symptoms and impacts clearly.
  2. Practice root cause techniques (5 Whys, fishbone).
  3. Map stakeholders and context at a high level.
  4. Define measurable goals and constraints.
  5. Run a playback to align on the problem statement.

Next steps

  • Complete the exercises and compare to the sample solutions.
  • Do the Quick Test to check understanding (your score is available to everyone; only logged-in users get saved progress).
  • Apply the one-page template to your current project this week.

Mini challenge

In 5 minutes, write a problem statement for any request you heard recently that sounded like "We need X." Replace X with the underlying need, include impact and a measurable goal. Then list two assumptions to validate.

Quick Test

Ready? Take the Problem Discovery And Context — Quick Test below. It’s available to everyone. Only logged-in users will have their progress saved.

Practice Exercises

2 exercises to complete

Instructions

Use the scenario: "Invoices are sent about 10 days after goods ship. Finance says they lack timely shipping confirmations." Perform discovery and produce outputs.

  1. Write the initial symptom with a concrete example (date, order, delay).
  2. Run at least 5 Whys to explore causes. For each why, note evidence you would seek.
  3. Identify stakeholders (R, A, C, I).
  4. Define one outcome metric and one leading indicator with targets.
  5. Create a simple context map (text description is fine): process steps, systems, data, and rules.
  • [ ] Symptom defined with example
  • [ ] 5 Whys complete with evidence notes
  • [ ] Stakeholders with RACI roles
  • [ ] Metrics with targets
  • [ ] Context map described clearly
Expected Output
A short document including: problem statement, 5 Whys chain with evidence notes, RACI list, two metrics with targets, and a text-based context map.

Problem Discovery And Context — Quick Test

Test your knowledge with 8 questions. Pass with 70% or higher.

8 questions70% to pass
Stakeholder Interviews

Have questions about Problem Discovery And Context?

AI Assistant

Ask questions about this tool