Customer needs analysis: find the problem worth solving next
Turn customer needs into product choices using a hierarchy and evidence register. Keep confidence, severity and occurrence separate in solution comparison.
Customer needs analysis identifies the outcome a buyer is trying to achieve, the context in which it matters and the constraints current solutions leave unresolved. Separate that need from a requested feature. Use recent episodes and contrary cases to choose which problem to investigate and which alternative solutions deserve prototype work.
Imagine you are developing a bag for commuters who carry work items and lunch. In this illustrative account, a commuter asks for a washable compartment because lunch leaked onto work items. Your decision is which solution to prototype. The need is to arrive with usable, organized belongings; a compartment, separate pouch, better container or different packing routine might meet it.
Keep the desired outcome constant while comparing those solutions. That gives the team room to find an effective response rather than researching why its favorite feature should exist. Follow the account into a prototype brief that keeps the outcome constant.
Build a need hierarchy from evidence
Keep the outcome. Compare the solutions.
Arrive with usable, organized belongings
A washable compartment?
Inspect containment and cleanup.
A separate pouch?
Inspect separation and packing effort.
A better lunch container?
A different packing routine?
Verify containment, space and packing effort in the same routine.
Compare these proposed solutions in the same carrying routine before claiming they solve containment or cleanup.
Level | Account, interpretation or proposal |
|---|---|
Desired outcome | Arrive with work items usable and organized: your interpretation of the account. |
Context | The account describes commuting with a laptop and packed lunch in wet weather. |
Constraint | “If the lunch container leaks, I have to empty the whole bag.” |
Current workaround | A separate plastic bag around lunch, reported in the account rather than observed in use. |
Proposed solution | A washable compartment: a product hypothesis to test. |
The need is not “add a washable compartment.” Other solutions might meet the same outcome: a separate pouch, a better lunch container or a different packing routine. Preserving the outcome lets the team compare alternatives rather than validate its first feature idea.
Ask about a concrete episode
Use this short interview sequence:
- Tell me about the last time you carried these items on your commute.
- What happened, from packing to arrival?
- Which part, if any, caused a problem?
- What did you do when that happened?
- What did that workaround cost in time, money or inconvenience?
- What have you tried before? Why did you keep or stop using it?
- What would a satisfactory outcome look like?
Probe for details without offering your preferred explanation. Ask about episodes where the problem did not occur too. This helps identify whether the need is specific to a context or a routine assumption in the research team.
If the conversation is simulated, label the answers as modeled accounts. They can generate candidate needs and questions, but a modeled episode should not enter the evidence repository as a human interview.
Keep the need linked to the episode
Use the needs register below and its copyable CSV. Each row holds a need, source identifier, source type, context, supporting evidence, contradictory evidence and confidence rationale. Separate the quotation or observation from your interpretation.
For human interviews, preserve permission, dates and a source location that another researcher can check. For behavior data, record the event definition and denominator. For modeled results, record the profile, stimulus and run provenance available. A count of model mentions is not a count of customers experiencing the problem.
The example row's confidence rationale is “No occurrence estimate or tested solution.” That concerns the evidence behind the need. Its severity rationale, “May disrupt workday,” concerns the consequence if the outcome fails. Keep those judgments separate; a serious potential problem can still have weak evidence about prevalence or solution value.
Complete needs-register record
Keep these fields when you copy the register into your own research record. Replace the example entries with evidence from the source you can inspect.
Field | Example entry |
|---|---|
| EXAMPLE-FICTIONAL |
| Arrive with items dry and organized |
| Wet commute with laptop and lunch |
| FICT-01 |
| Fictional teaching account |
| 2026-10-04 |
| Example in article |
| Lunch leak requires emptying bag |
| Contain leaks separately |
| Not established |
| Unknown |
| May disrupt workday |
| Fictional teaching account only; no occurrence estimate or tested solution. |
| Separate plastic bag |
| Does a compartment solve it in use? |
| Human prototype use test |
| Example only |
Copy the complete register CSV
need_id,outcome,context,source_id,source_type,source_date,source_location,evidence,interpretation,contradictory_evidence,occurrence_evidence,severity_rationale,confidence_rationale,current_alternative,next_uncertainty,next_method,owner
EXAMPLE-FICTIONAL,Arrive with items dry and organized,Wet commute with laptop and lunch,FICT-01,Fictional teaching account,2026-10-04,Example in article,Lunch leak requires emptying bag,Contain leaks separately,Not established,Unknown,May disrupt workday,Fictional teaching account only; no occurrence estimate or tested solution.,Separate plastic bag,Does a compartment solve it in use?,Human prototype use test,Example only
Choose whether to study occurrence or the solution
Evaluate a need on four separate dimensions:
- Severity: What happens when the outcome fails?
- Occurrence: How often does it arise, according to suitable evidence?
- Current satisfaction: How well do alternatives solve it?
- Feasibility: Can the team address it within the commercial and operational constraints?
Do not multiply arbitrary one-to-five scores and treat the result as a measured market opportunity. Use the dimensions to explain the judgment. Mark occurrence as unknown if the evidence is qualitative or coverage is limited.
For the bag example, a consequential leak may merit prototype work even if prevalence remains uncertain. A broad investment in a new compartment system needs stronger evidence about how often the need occurs and whether buyers value the proposed solution.
Compare solutions without replacing the need with a feature
The commuter's outcome is to arrive with usable, organized items. A washable compartment is one hypothesis; a separate pouch or better lunch container may solve the same problem differently. Compare those alternatives against the outcome before defending the feature the team can most easily build.
Candidate response to the need | Details |
|---|---|
Washable compartment | Benefit to investigate: Contain the effect of a leak and simplify cleanup Tradeoff to inspect: Bag weight, space and actual separation |
Separate pouch | Benefit to investigate: Keep lunch apart from work items Tradeoff to inspect: Extra packing step and where the pouch fits |
Better container | Benefit to investigate: Prevent the initiating leak Tradeoff to inspect: Closure performance and carrying routine |
Changed packing routine | Benefit to investigate: Reduce disruption without a new product Tradeoff to inspect: Whether the workaround is realistic in the commute |
Investigate the episode where the problem did not happen
A leak story is memorable, but a useful comparison includes trips that went well. How was lunch packed? Which container and route were involved? Did the buyer use a separate pouch, carry different items or avoid the situation? Those details can reveal a workable alternative or a condition the feature actually needs to address.
Keep an episode log rather than pool every “messy bag” comment into one need. The desired outcome may be shared while the cause differs: container failure, poor separation, an exposed laptop or an awkward packing routine. A compartment solves only some of those conditions.
Ask what tradeoff the buyer would accept to solve the problem. More bag weight, less space or another packing step may change the concept’s usefulness. Compare the alternatives with the same commute and items, then verify the physical mechanism appropriate to each candidate.
Write the prototype brief in outcome language
The prototype brief is “Keep work items usable when lunch is carried on this commute,” with the actual items and routine specified. Develop a compartment and a separate-pouch direction. Inspect containment, access, cleanup and packing effort under the same task. A favored feature no longer defines success.
Use the needs register to retain what the episode supports and what remains unknown. A serious consequence can justify exploratory prototype work while its frequency is unresolved. A major range decision requires suitable occurrence and commercial evidence; the useful next step depends on that commitment.
Turn the hierarchy into a research plan
Prototype the compartment and pouch against the same carrying routine.
Ask whether each keeps lunch separate without adding an unacceptable packing step or sacrificing useful bag space. Verify physical containment and cleaning in an appropriate use test. Explore where the need recurs through recent episodes and contrary cases. This sequence spends effort on the consequence and solution first, while leaving a broader market-size decision for evidence that can measure occurrence.
For each priority need, write the next uncertainty and the method that can resolve it. Human observation can examine packing and leakage in practice. A survey with an appropriate sample can examine reported frequency. Concept research can compare proposed solutions. An in-market test can examine actual take-up.
With Sapien’s synthetic users, you can explore needs, habits, motivations and product choices. A scoped study can return modeled needs priorities and segment differences, compare proposed solutions and recommend which problem or response deserves attention. Retain provenance and define which conclusions the grounding and task-specific validation support. Identify any additional evidence required by the remaining risk; direct observation is needed to verify physical leakage in use, while a supported modeled comparison can inform solution choice. Discuss your evidence register with Sapien. Use our concept testing guide to assess solutions and our consumer behavior guide to distinguish accounts from actions.
