Best Prompts for Product

Product feedback arrives in fragments: support tickets, sales notes, interview transcripts, cancellation reasons, usage comments, and feature requests. The same underlying problem may appear in different language, while a loud request may represent only one customer’s preferred solution.

The product team needs a brief that preserves the evidence without turning a pile of comments into an invented consensus. AI can help organize the material, but only if it is required to trace each conclusion back to the source.

Why ordinary prompting fails

“Summarize this feedback and recommend a feature” jumps from anecdotes to solution. It encourages the model to merge distinct users, hide contradictory evidence, and count repeated copies as independent signals. The resulting brief may sound decisive while losing who experienced the problem, in what context, and with what consequence.

A stronger prompt separates observations, interpretations, and solution ideas. It also treats frequency as unknown unless the dataset supports counting.

Reusable prompt

Copy
ROLE
You are a product discovery analyst. Turn supplied customer feedback into a problem brief that helps a product team decide what to investigate next. Do not design a feature or claim market demand beyond the evidence.

REQUIRED INPUTS
1. Feedback records with stable source IDs, dates, channels, and exact text: [paste or attach]
2. Relevant customer or user segments: [definitions]
3. Product area and current workflow: [description]
4. Research period and selection method: [details]
5. Known product constraints or strategy boundaries: [list]
6. Optional usage or support data linked to the same problem: [data]

STEPS
1. Check source quality, duplication, and selection bias.
2. Extract atomic observations while preserving source IDs.
3. Group observations by underlying job, obstacle, context, and consequence, not by requested feature name.
4. Separate reported facts, user interpretations, and proposed solutions.
5. Identify affected segments and situations only where supported.
6. Surface contradictions, edge cases, and feedback that does not fit the main pattern.
7. Draft a problem statement without embedding a solution.
8. List assumptions and the smallest research questions needed to reduce uncertainty.

OUTPUT FORMAT
- Brief title
- Problem statement: 80 words maximum
- Who encounters it: supported segments and contexts
- Current journey: 4 to 7 steps
- Evidence table: theme, source IDs, representative quotation, consequence
- Frequency: count only deduplicated records in this dataset, plus a warning that sample frequency is not market prevalence
- Contradictory or weak evidence
- Existing workarounds
- Business or user consequence: observed evidence only
- Assumptions
- Questions for further discovery
- Solution ideas mentioned by users: separate appendix, not recommendations

EVIDENCE AND UNCERTAINTY RULES
- Every theme and consequence must cite source IDs.
- Never create quotations or combine words from different sources into one quote.
- Deduplicate repeated or syndicated records where identifiable.
- Do not infer segment, intent, severity, or prevalence from missing fields.
- Label interpretations as interpretations.
- Use “not established” when the evidence cannot answer a question.
- Preserve meaningful disagreement rather than forcing one narrative.

What to provide

Provide raw feedback with stable identifiers. Include metadata that matters to interpretation, such as customer segment, product plan, workflow stage, and date, but remove unnecessary personal data. Explain how records were selected. Fifty tickets found through a search for one feature name are not a neutral sample of all customer needs.

Include the current workflow and any relevant product constraints. Without that context, the same comment can be misread. “Export takes too long” could mean generation time, approval delay, file download, or the work required to clean the output.

How to review the output

Audit the evidence table first. Open a sample of source records for every major theme and confirm that the quotations are exact and the grouping is defensible. Look for themes supported by many near-duplicate tickets from one incident or one account.

Next, remove solution language from the problem statement. “Users need a dashboard” describes an answer. “Finance leads cannot see which invoices are awaiting approval, so they reconcile status manually” describes a situation that can be investigated.

Finally, ask what is missing. The brief should make uncertainty visible: silent users, excluded segments, sparse usage data, or contradictions between stated preferences and observed behavior.

Where it fails

Feedback is not a representative measure by default. Customers who contact support, attend interviews, or respond to surveys differ from those who remain silent. A clean synthesis cannot correct a biased sample.

The prompt also cannot establish strategic priority on its own. Product choices depend on company direction, opportunity cost, technical constraints, risk, and evidence from behavior. Nor can it verify whether the stated problem persists after a recent product change unless current data is included.

Sensitive research requires appropriate consent, access control, and redaction. Do not paste confidential customer information into an unapproved system.

Practical takeaway

A problem brief should compress the reading, not erase the trail. Keep source IDs attached, preserve disagreement, and stop before solution selection. Try the prompt in Agentic Workers with one bounded set of feedback, then use the unanswered questions to plan the next discovery step.

<!-- X derivative: The best feedback synthesis preserves source IDs, separates problems from requested features, and treats sample frequency as evidence about the sample, not the whole market. -->