How to Turn a Product Idea Into a Research Brief

Quick answer

Turn a product idea into a research brief by naming the decision you need to make and the evidence that could change it. Give the assistant a defined audience, specific questions, source requirements, and a stopping point. Request findings with uncertainty and implications, rather than a generic market overview.

A product idea often arrives as a solution: “We should add a shared inbox.” Research becomes more useful when you identify the problem underneath it: which people lose track of requests, what happens today, and whether shared ownership would help. Otherwise, the assistant may assemble a persuasive report about the feature you already proposed.

Write the decision before the questions

Use a decision sentence such as: “Decide whether to prototype shared request ownership for our existing small-team customers.” This establishes the audience and the near-term choice. It does not ask the research to justify a complete product launch.

Then list what you need to learn:

• Which request-handling failures customers describe in their own words.
• How frequently the problem appears in the supplied evidence.
• What workaround customers use today.
• Which assumptions a prototype should test.
• What evidence would support postponing the idea.

Include counterevidence on purpose. An assistant asked only for opportunity may miss that users prefer a single accountable owner or already solve the problem through a simple process.

Worked example: an ownership feature

Consider an illustrative product team with eight authorized interview notes. Three customers describe duplicate replies, two describe unanswered requests, and three have no apparent ownership problem. These are invented example counts, not research results.

A useful assistant output keeps the cases separate. Duplicate replies may suggest visibility is missing. Unanswered requests may suggest responsibility is unclear. Those are related problems, but they do not automatically imply the same interface.

Ask for a short evidence map linking each observation to the interview passage and an explanation of plausible alternatives. The next prototype might test a visible owner field before a larger shared-inbox redesign. That is a decision informed by evidence, not a declaration that a market exists.

A research brief template

Decision: whether to prototype shared request ownership for current small-team customers. Sources: only the interview notes and support tickets I provide initially. Questions: where requests stall, how people assign responsibility today, and which workarounds succeed. Deliverable: a two-page brief with evidence links, recurring patterns, exceptions, unknowns, and three prototype questions. Separate customer statements from your interpretation. Do not invent market size, interview results, or demand. Stop after the supplied sources and identify any additional research you recommend.

If you later authorize public research, require current primary sources for product features and prices. Keep that research separate from customer evidence. A competitor having a feature is a fact about the competitor's offering, not proof your customers need it.

Define an evidence hierarchy

Choose sources that answer the actual question. Support tickets show reported friction. Interviews provide context and explanations. Usage data can help establish observed behavior when available and appropriately authorized. Public product pages can show how another vendor positions a capability.

Each has limits. A ticket is not a representative survey, an interview statement is not a guaranteed purchase, and a vendor page is not independent proof of effectiveness. Ask the assistant to name these limitations beside the conclusions they affect.

Set a research time box and a completion rule. A brief should end when the requested evidence has been examined and the decision-relevant unknowns are visible. Continuing to add background may increase reading time without improving the choice.

Frequently asked questions

Should the assistant recommend a feature?

It can recommend a next experiment with supporting reasoning. The product owner should decide whether the evidence and business context justify it. Preserve alternative interpretations when the evidence is thin.

How much context should I provide?

Provide the intended customer, current workflow, known constraints, and the decision deadline. Include prior research so the assistant does not treat an already rejected assumption as a new discovery.

Can it write a specification immediately?

It can help prepare one, but avoid turning unresolved research questions into firm requirements. A research brief and a delivery specification serve different decisions.

See Righthand's product manager role, natural language requests, and task delegation for related ways to structure product work.