Discovering Customer Problems

Great solutions start with well-understood problems, not with features. This deep dive covers the discovery practices OLM expects before any investment conversation: structured customer interviews, problem framing, and separating observed evidence from opinion. You will learn how to write a problem statement that survives contact with a sceptical review board, how many interviews are enough, and the most common trap — pitching your solution during discovery and hearing only polite agreement. Includes the interview guide template and a worked example from an energy-management field team.
This module defines what acceptable Gate 1 evidence looks like: interview counts, problem statements with observed evidence, and opportunity sizing without solution bias. Knowing the standard helps you triage gate submissions consistently and push back on decks built from opinion. The interview guide template it ships is the artefact to expect in evidence packs. Ask for this: the raw problem statement and interview log, not just the summary slide.
Discovery is where your Gate 1 evidence comes from, and this deep dive shows what the board considers evidence: structured interviews, a problem statement separated from your favourite solution, and honest sizing. The worked field example shows how thin discovery gets a pitch sent back. Twenty minutes that will save you a failed gate. Takeaway for your backlog: park any item whose problem statement you could not defend with named customer evidence.
Useful even though the Product Owner leads discovery — teams do the interviewing, and you protect the practice. Learn to spot the anti-pattern of pitching during discovery so you can coach interviewers out of it, and to keep discovery work visible on the board instead of squeezed between sprint commitments. Try this with your team: run one practice interview in a retro and count how many questions were really disguised pitches.
Intended for
Ask Aimy
21:43:26 Aimy
Hi, I'm Aimy! Ask me anything about OLM, the learning modules or our governance processes.