CDT504 Chap.4 Discovering and Organising Customer Needs
Discovering and Organising Customer Needs
Evidence before interpretation
Interviews, observations and product-use evidence reveal explicit and latent needs. Preserve the original statement or behaviour before translating it, because another reviewer should be able to challenge the inference. A need describes an outcome in context and stays neutral about the mechanism.
Requested features belong in the concept pool rather than inside the need statement.
Organise without losing traceability
Primary and secondary needs connect detail to the overall value proposition. Importance ratings help allocate attention, but a precise number cannot repair a convenient sample or unsupported inference.
Latent needs require follow-up evidence because a workaround may reflect policy, habit or preference rather than dissatisfaction.
What this chapter covers
- 01
Interview evidence
- 02
Observation evidence
- 03
Explicit and latent needs
- 04
Solution-neutral statements
- 05
Needs hierarchy
- 06
Importance and traceability
Worked example · free
Separate a need from a feature request
- 2Preserve the evidence.
- 2Write the underlying need.
- 2Keep alternative concepts open.
Key terms
- Explicit Need
- An outcome a user states directly during research.
- Latent Need
- An outcome inferred from behaviour or context that users may not request directly.
- Need Statement
- A solution-neutral description of a desired user outcome in context.
- Needs Hierarchy
- An organisation of broad primary needs and more specific secondary needs.
- Representative User
- A participant whose context and capabilities reflect an intended user group relevant to the decision.
Discovering and Organising Customer Needs FAQ
Why should requested features not become needs?
A requested feature commits the team to a mechanism before alternatives have been generated. Preserve it as a concept while translating the underlying desired outcome into solution-neutral language.
How can a team justify a latent need?
Show the observed behaviour or workaround, state the inference and use follow-up questions or repeated observation to test it. Do not treat every unusual behaviour as proof of dissatisfaction.
What makes customer evidence traceable?
Keep the original evidence, anonymised participant context, interpreted need and later metric connected. The group report should show how user insight changed specifications or design decisions.
How should importance and satisfaction be used together?
Rate them as separate judgements. A highly important need may already be served well, while a lower-ranked need may be the product's largest weakness. Keeping both visible distinguishes an innovation opportunity from a basic correction and prevents one number from hiding the reason for priority.
What should remain after personal details are removed?
Preserve the task, setting, participant type, observed behaviour and words needed to evaluate the interpretation. Remove names, contacts and unnecessary identifiers. Anonymisation should protect people without stripping away the context that allows a reviewer to judge whether the need follows from evidence.
How is a needs hierarchy checked for coverage?
Trace every important branch to evidence and every relevant evidence item to at least one need. Look for duplicate secondary statements, gaps in user contexts and branches supported only by team opinion. Label unsupported but plausible needs as hypotheses and plan research rather than presenting them as findings.
Assessment move
Collect five everyday complaints and rewrite each as a positive outcome without naming a feature. Then identify which statement rests on direct language and which requires inference. Build a small hierarchy and check that no secondary need duplicates another. Finally, propose one follow-up question that could disprove each latent-need inference. Use a three-layer evidence sheet.
In the first column preserve what the participant said or what you observed, using anonymised labels and enough context to understand the task. In the second column write the interpreted need. In the third column list possible concepts, keeping them visibly separate from the need. This layout prevents a feature request from silently becoming a requirement. Audit the wording.
Replace vague claims such as easy, convenient or better with an outcome and context, but do not invent a degree of improvement before measurement. Check that statements are affirmative where that improves clarity and that they describe what the user seeks rather than how the product must achieve it. For latent needs, add an inference test.
Repeated repositioning might suggest discomfort, but it could also reflect unfamiliarity or a procedural rule. Write a follow-up question or observation that distinguishes those explanations. Build the hierarchy only after translation. Group statements by shared outcomes, preserve important detail at the secondary level and check whether one statement appears under several branches because its scope is unclear.
Rate importance separately from current satisfaction so a need that matters greatly but is already well served is not confused with an unmet weakness. Review representation. Name which intended users, use situations and capability ranges appear in the evidence and which remain absent. The assignment accepts several evidence forms, but quantity does not replace relevance.
Finish by tracing every important need to at least one evidence item and every evidence item to a decision. Before submission, remove names and contact details while retaining the setting needed to judge the finding.
