The customer research decision memo: six parts that turn interviews into a test

A customer research decision memo should say what you recommend, why the evidence supports it and what would change your mind. A teammate should be able to challenge the recommendation without rewatching every interview recording. (Nobody wants to rewatch every interview recording.)

The memo itself is a short chain from a decision to evidence, interpretation, alternatives and the next action. Keep the chain visible even when the research is incomplete.

The format suits a small product team. Its worked example, a maintenance scheduling product, is fictional, so don't reuse its observations as market evidence.

1. Name the decision, its owner and the deadline

Write the decision as an action. "Test a shared job-status view with dispatchers" is clearer than "Improve coordination." Name the person who decides and the date by which the team needs an answer.

State the scope. A prototype test is a much smaller commitment than building and supporting the feature. A memo that recommends a small experiment shouldn't quietly authorize a broader release.

Then list the options you really had, including keeping the current behavior. If every option assumes the feature gets built, the memo is explaining an implementation choice and the underlying need is still untested.

2. Link every important claim to a record

Each important claim should point to a source record the team can inspect, within the participant's consent and the organization's access rules. Use stable internal references instead of spreading personal details through the memo.

GOV.UK's research analysis guidance separates observations from findings and actions. This ledger applies that split to a decision record.

Don't copy every note in. Include what a reader needs to understand the recommendation, and link to the rest.

3. Write down the best case against your reading

Say participants report checking job status over and over. That might mean status isn't available. It could also mean the status shown isn't trusted, the work changes often, or responsibilities are unclear.

Each explanation points to different work. A new screen could show information without making it more accurate. Better updates could improve accuracy without settling who owns them. The memo should say which explanation the research currently favors, and why.

Counterevidence covers contradictions and gaps. "We did not speak with technicians" is not a contradiction. It is still a major limit on a proposal that changes what technicians do.

4. See it in a full 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 information available today. Find out 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.

The recommendation stays smaller than "Customers need a dashboard." It names the uncertainty the next test has to resolve.

5. Get a different kind of evidence for the gap

If the decision depends on how often something happens, a few interviews can identify the behavior but not estimate how widespread it is. If it depends on people succeeding with the product, a positive reaction is different from watching someone complete a relevant task.

Pick a source that addresses that limit: product data, support records, direct observation, a prototype study, or a survey designed for the population question. More of the same evidence rarely closes the gap.

NN/g describes triangulation as using different sources or approaches to examine a question. The value here is that a second method can show you something the first could not.

Don't treat several summaries of one interview as independent confirmation. Trace each piece of evidence back to where it came from.

6. Define the next test before collecting more opinions

A testable action has an uncertainty, an activity, an observable result and a consequence for the decision. "Get more feedback" is missing most of those.

For the fictional status example, the uncertainty is whether the information supports the dispatcher's next decision. The activity could be a prototype with representative task scenarios. The observation is what participants can work out, what they ask for and what they misunderstand. The consequence is whether to revise the concept, study the update process or consider building it.

Give any numerical threshold a stated purpose and basis; don't invent a success percentage to look rigorous. A qualitative test can have clear decision conditions without a made-up statistical rule.

Keep it short enough to argue about

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 point at 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.

Add the outcome after the test

When the team runs the test, add the result and whether it changed the recommendation. Keep the earlier reasoning instead of rewriting it as if the answer had always been obvious.

That history helps the next team tell a rejected idea from an untested one. The memo has done its job when the evidence changes a decision or defines a more useful test.