Turn customer notes into a problem brief

A product brief should explain the problem before committing to a feature. Use the assistant to organize evidence and make uncertainty explicit, then let the product owner decide what to pursue.

Prepare the input

Supply anonymized interview notes, support references, and the intended user group. Include the decision you need to make. Do not treat a selected set of comments as a representative survey.

Run the workflow

Ask for the user job, observed friction, supporting references, current workaround, and unanswered questions. Keep requested features separate from the underlying need. Do not manufacture frequency or impact figures.

Prompt to copy

Create a problem brief from these notes: [material].
Include user, job, observed problem, evidence, workaround,
assumptions, proposed solutions, and validation questions.
Separate direct reports from interpretation.
Do not infer market size, frequency, or revenue impact.
Finish with the smallest useful next research step.

Review a worked example

Illustrative comment: “I export to a spreadsheet before every review.” This may show a reporting workaround. It does not prove that a new dashboard is the right solution. Check whether the brief preserves the job the user is trying to complete rather than simply rewording the requested feature.

Look for evidence that describes a workaround rather than the cause. Exporting data may reflect a missing field, a sharing need, or a familiar habit. The brief should preserve those alternatives. Ask what observation would distinguish them before choosing a feature. This keeps a vivid quote from carrying more weight than it can support.

Use it again

Add new evidence to the same structure and revisit assumptions. Keep a proposal distinct from an approved roadmap commitment. Explore Bot for personal product work or discuss connected feedback analysis.