How to turn customer interviews into a testable product decision

A useful research decision memo tells a reader what you recommend, why the evidence supports it, and what could change your mind. It should be possible to challenge the recommendation without reopening every interview recording.

The memo is not a collection of favorable quotes. It is a short chain from a decision to evidence, interpretation, alternatives, and the next action. Keep that chain visible even when the research is incomplete.

The memo format below is designed for a small product team. Its worked example concerns a fictional maintenance scheduling product; the observations in that example are invented for explanation and must not be reused as market evidence.

Start with the decision and its owner

Write the decision as an action: “Test a shared job-status view with dispatchers” is clearer than “Improve coordination.” Name the person responsible for deciding and the date by which the team needs an answer.

State the scope. A prototype test is different from a commitment to build and support the feature. A memo that recommends a small experiment should not quietly authorize a broader release.

Then list the options that were genuinely available. Include keeping the current behavior when that is plausible. If every option assumes the same feature must be built, the memo is explaining an implementation choice rather than testing the underlying need.

Build a compact evidence ledger

Each important claim should connect to a source record the team can inspect within the participant’s consent and the organization’s access rules. Use stable internal references rather than spreading personal details through the memo.

GOV.UK’s research analysis guidance distinguishes observations from findings and actions. The ledger applies that distinction to a decision record. Read the analysis guidance.

Do not copy every note into the ledger. Include the evidence necessary to understand the recommendation and link to the fuller record where appropriate.

State the strongest alternative explanation

Suppose participants report repeatedly checking job status. That might mean status is unavailable. It could also mean the available status is not trusted, the work changes frequently, or responsibilities are unclear.

Each explanation suggests different work. A new screen could expose information without improving its accuracy. Better updates could improve accuracy without resolving ownership. The memo should say which explanation the research currently favors and why.

A useful counterevidence section includes both contradictory observations and missing coverage. “We did not speak with technicians” is not a contradiction, but it can be a major limit on a proposal that changes technician behavior.

Use an original worked memo

The following example is fictional:

Decision: Run a task-based prototype test of a shared status view before scheduling implementation.

Question: Can dispatchers identify the next action for a job without separately contacting a technician?

Illustrative evidence: A dispatcher described asking for updates outside the scheduling tool. A technician described delays in updating the tool when work changed on site. Another dispatcher described a reliable routine for confirming changes.

Interpretation: Visibility may matter, but freshness and ownership may matter as much as the interface.

Alternative explanation: The main difficulty may be the update process rather than the display.

Proposed test: Use realistic, non-sensitive job examples to compare a status view with the current information available. Investigate what each role needs to trust the displayed status.

Decision conditions: If participants can identify the next action but distrust the status, study the update process before refining the screen. If a needed fact is absent, revise the information model and test again. If the current workflow already supports the task, reconsider the proposed view.

Limit: These accounts do not establish how widespread the issue is or whether the new process would be maintained in daily work.

Notice that the recommendation stays smaller than the claim “Customers need a dashboard.” It names the uncertainty the next activity must resolve.

Match additional evidence to the claim

If your decision depends on frequency, a few interviews may identify the behavior but not estimate its prevalence. If it depends on successful use, a person’s positive reaction is different from observing them complete a relevant task.

Consider another source that can address the specific limit: product data, support records, direct observation, a prototype study, or a broader survey designed for the population question. Adding more of the same evidence may not resolve the gap.

NN/g describes triangulation as using different sources or approaches to examine a question. Its value here is the possibility of discovering information your first method could not provide. Read the triangulation guidance.

Do not treat several summaries of one interview as independent confirmation. Trace evidence back to its origin.

Define the next test before collecting more opinions

A testable action has an uncertainty, an activity, an observable result, and a decision consequence. “Get more feedback” is missing most of those elements.

For the fictional status example, the uncertainty is whether the information supports the dispatcher’s next decision. The activity could involve a prototype and representative task scenarios. The observation concerns what participants can determine, what they ask for, and what they misunderstand. The consequence is whether to revise the concept, study the update process, or consider implementation.

Any numerical threshold should have a stated purpose and basis. Do not invent a success percentage merely to make the memo appear rigorous. A qualitative test can have clear decision conditions without a fabricated statistical rule.

Keep the memo short enough to debate

Use this order:

1. Decision requested and responsible owner.
2. Recommendation and its scope.
3. Evidence supporting the recommendation.
4. Counterevidence and missing perspectives.
5. Alternatives considered.
6. Next test, decision conditions, and review date.

A reader should be able to locate the assumption they disagree with. Replace abstract confidence labels with an explanation: strong evidence about this workflow, limited coverage of this role, no evidence yet about adoption over time.

Record what happened after the decision

When the team runs the test, add the outcome and whether it changed the recommendation. Preserve the earlier reasoning rather than rewriting it as though the answer had always been clear.

That history helps the next team distinguish a rejected idea from an untested one. It also prevents a polished research readout from becoming the endpoint: the memo has done its job when the evidence changes a decision or defines a more useful test.