From Empathy Interview to Problem Statement: A Worked Example

Teams often know they should run empathy interviews. Fewer teams can show how interview notes become a problem statement the product org will fund. This article walks through one cycle - composite from field work, but structurally identical to what I use in consulting and MBA workshops.

The scenario: a mid-size operations company wants to reduce repeat service visits. Leadership's opening hypothesis is "technicians need a better mobile app." That is a solution, not a problem. Empathy work is how you find out whether it is even the right bet.

Step 0: Set a learning goal (not a verdict)

Before scheduling interviews, the team wrote one sentence:

We need to learn what breaks down between dispatch assigning a job and the technician closing it on the first visit.

Notice what is missing: no mention of an app, no feature list, no NPS target. A learning goal keeps empathy interviews in discovery mode instead of validation mode.

They interviewed dispatch coordinators, field supervisors, and technicians. Below is a condensed version of one coordinator interview.

Step 1: Run the interview - and capture verbatim pain

Interviewer: Walk me through the last time a job came back incomplete after the technician left the site.

Coordinator (Priya): Yesterday. Customer called saying the part we shipped was wrong. The tech had the work order, but the SKU on the truck did not match what the customer actually had installed. He could not finish. We re-dispatched today - second truck roll, angry customer.

Interviewer: What did you do when you got that call?

Priya: I checked three systems. Work order in the dispatch tool, inventory in the warehouse module, photos the tech uploaded from the last visit six months ago. The photos were in a shared drive folder named by date, not by customer. I lost twenty minutes just finding the right file.

Interviewer: What would have to be true for this to feel easy?

Priya: I would trust that what dispatch sends matches what is on site - before the truck rolls. Right now I am guessing, and the tech pays for my guess.

Three signals worth highlighting:

• Workaround: Priya searches three systems and a folder tree - the process works, but only through heroics.
• Emotional weight: "The tech pays for my guess" - failure lands on the field, not the office.
• Repetition: Same pattern as two other interviews that week (wrong part, missing site history, re-dispatch).

Raw notes are not the deliverable. But verbatim quotes preserve the user's language for Define.

Step 2: Extract pain points (Empathize output)

From five interviews, the team listed observations without solutions:

Pain point	Who	Frequency
Work order does not reflect on-site equipment reality	Coordinator, technician	4 of 5 interviews
Site history scattered across tools and folders	Coordinator	5 of 5
Re-dispatch decided reactively after failed visit	Supervisor	3 of 5
Technicians lack confidence to challenge incomplete work orders	Technician	3 of 5
Customer sees one brand; internal handoffs are invisible	Coordinator	4 of 5

This table is Problem space work in the Growth Diamond Model - still Empathize, not Define. The team resisted jumping to "build a unified dashboard" because only one row mentions tools directly. The others describe trust, information gaps, and decision timing.

For a deeper process on clustering, see From Pain Points to Problem Statements.

Step 3: Cluster and choose a POV (Define)

Affinity mapping grouped the pains into three themes:

1. Information fragmentation - site history hard to assemble
2. Upstream accuracy - work orders sent before reality is verified
3. Downstream cost - failed first visits trigger re-dispatch and customer churn

The team could not solve all three in one release. Define forces a point of view: which user, which need, which insight from empathy.

They chose Priya's world first - dispatch coordinators - because every failed visit flows through her desk. Fixing upstream accuracy for coordinators would also reduce technician rework.

Draft POV (too vague):

Dispatch coordinators need better tools.

Revised POV using the standard needs statement format:

Dispatch coordinators need a way to verify on-site equipment context before a technician is dispatched because work orders are often built from incomplete history spread across systems, and first-visit failures erode customer trust and field morale.

That sentence does three jobs:

• Names the user (not "the business")
• States a need without prescribing an app
• Anchors to empathy insight (fragmented history, first-visit failure)

Step 4: Attach success criteria

A problem statement without success criteria is a slogan. The team added measurable outcomes for Ideate and Develop:

• First-visit completion rate on jobs requiring parts - baseline 71%, target 85% within two quarters
• Coordinator prep time per complex job - baseline 18 minutes median, target under 8 minutes
• Re-dispatch rate for part mismatch - track weekly, target 50% reduction

Success criteria belong in Define, not after launch. They tell Ideate which ideas are in scope.

Step 5: Socialize before Ideate

The team shared the POV with warehouse ops and field leadership - people who were not in the interview room. Two useful challenges came back:

• Warehouse asked whether "verify before dispatch" could slow same-day SLAs
• Field lead asked whether technicians should co-own verification, not only coordinators

Both sharpened the problem statement. The final version added a boundary: verification must fit inside existing same-day dispatch windows for priority jobs.

Only then did the team run brainstorming. Ideas included pre-dispatch photo checklists, customer-confirmed asset IDs, and ML on past visit photos - none assumed at the start.

What would have happened without this path

If the team had skipped to Ideate with leadership's original brief ("build a better mobile app"), they would likely have shipped offline mode and a prettier work-order view. Priya would still have searched three systems before every complex dispatch. First-visit failure rates would barely move.

That is the difference between activity and Problem space clarity. Empathy without synthesis is conversation. Synthesis without a POV is a research report nobody funds.

Template you can reuse

Copy this into your next workshop:

1. Learning goal - one sentence, no solution words
2. 3-5 interviews - same role or adjacent roles in the journey
3. Pain point table - observation, who, frequency
4. One POV - user + need + because [insight]
5. 2-3 success criteria - measurable, tied to the pain
6. 30-minute stakeholder readout - before brainstorming

Where to go next

• Full Define tooling: Academy Define hub
• Interview technique: Empathy Interviews in Practice
• Framework context: Methodology guide
• Why bad problem choice kills products: Why 80-95% of Products Fail

Running this exercise with your team? Book a 15-minute call to walk through your scenario.