Finding a problem worth solving — Examples

Example 1 — Sizing a problem before acting on it

A research session surfaced a real frustration and the team is about to act on how loud it felt. Attaching a rate and a cost changes the argument from taste to arithmetic, and naming who pays shows the business case the finance team will judge. Size the finding below, using the figures as illustrative, and state the threshold below which you would not act.

Finding from eight sessions: repeat buyers dislike re-entering their
card details at checkout. Six of eight called it annoying. Support
says it comes up often.

Solution

Problem   repeat buyers re-enter card details at checkout
Rate      about 42% of repeat buyers, roughly 1,900 sessions a month
Cost      about 40 seconds each, and 28% abandon at the step
Value     recovering half the abandoners is roughly 9k a month
Margin    the rate is from analytics; the value is illustrative

Others who pay
  support   around 60 calls a month, 5 minutes each of agent time

Threshold  below 8% abandonment, do not act; not worth a fortnight.

Three numbers with their sources turn the finding into something the team can rank, and the support line shows a second payer who was invisible in the session notes. The usual mistake is reporting only the user’s cost, which leaves the business case resting on an adjective.

Example 2 — Writing the problem statement last

The team has agreed the evidence, but the first draft of the statement already contains a solution, which quietly excludes the cheaper options. The problem statement should name the person, the goal and the obstacle, with no solution in it. Rewrite the draft below and show that two different solutions are possible from the result.

Draft problem statement:
  We need saved cards, so that repeat buyers do not have to type
  their details again.

Solution

Problem statement
  Repeat buyers abandon at the card step because they must re-enter
  details they have already given us.

Solutions this leaves open
  1 remember the details for the next purchase, without storing a card
  2 keep the last order one tap away, so re-entry never comes up

The draft supports only the first and excludes the second before the
design session has seen it.

The rewritten sentence states the obstacle and nothing else, so the approaches can be compared on cost and risk and the cheapest stays in play. The common mistake is a statement whose verb is “build”; it reads as a requirement, gets estimated, and the alternative that removes the work never enters the room.