Product Discovery
Separate product assumptions from verified requirements
A requirement can look authoritative simply because it appears in a polished document. Separate evidence, inference, and policy decisions so teams know which assumptions need testing before they become expensive commitments.
A feature request often combines several kinds of statement: what a person observed, what the team believes, and what management wants to make true. Treating all three as verified requirements hides uncertainty. A useful discovery record makes the basis of each statement visible without turning every discussion into a formal research project.
Use evidence labels that describe the basis
Distinguish observed behavior, reported experience, inferred need, and an adopted business rule. A policy decision can be binding without proving that users prefer it. A participant’s request can be genuine without proving that the proposed feature solves the underlying problem.
GOV.UK discovery guidance asks teams to break down assumptions and investigate constraints.[1] Build a practical register around that work. For each consequential statement, record the source, the relevant user group, and what the evidence actually covers.
Write assumptions so they can be challenged
Replace customers need notifications with a testable proposition: customers miss a task because they do not notice its status change. That formulation leaves room for other explanations, such as unclear responsibility or an action that is impossible with the available information.
Identify what observation would weaken the assumption. Choose a proportionate method to investigate it, such as reviewing suitable records or observing a task. Test assumptions that could change feasibility or the purchase decision before polishing details that matter only after the concept succeeds.
Hypothetical example: a membership renewal reminder
A hypothetical membership service assumes that reminders will reduce incomplete renewals. Interviews reveal that some members notice the deadline but cannot identify which supporting document applies. The team records this account as reported experience, not proof of its prevalence.
The original notification assumption remains unverified. The team tests clearer document guidance in a prototype and checks whether participants can select the correct evidence. It does not convert a successful task test into a claim about future renewal rates.
Maintain an evidence register that supports decisions
Keep the register short enough to review during planning. Link detailed material separately, with appropriate restrictions for participant information.
- State the assumption in a form that evidence could contradict.
- Identify the user group and operational context it concerns.
- Record the evidence type, source, and important coverage limits.
- Name the next test and the decision it will inform.
- Assign an owner to revise or retire the statement.
Promote statements carefully, not permanently
A verified requirement still needs a boundary. State who it applies to and under which conditions. New user groups, changed policies, or different operating environments can require another review. Evidence should support a specific conclusion, not an unlimited label of certainty.
This discipline adds administrative work, so focus on statements with meaningful consequences. Mark routine preferences clearly without demanding elaborate proof. The goal is to prevent hidden bets from entering contracts and designs, while preserving the ability to act when the available evidence is sufficient.
