Product Feedback Evidence to Roadmap Decision Brief

Public field comparison

Product Feedback Evidence to Roadmap Decision Brief

Product Feedback Evidence to Roadmap Decision Brief

Convert customer feedback, support signals, sales input, and product data into a roadmap decision brief with evidence strength, tradeoffs, options, and recommendation.

Turn customer feedback, product behavior, commercial signals, and delivery constraints into a traceable roadmap recommendation with explicit decision gates and verification evidence.

Use this for turning mixed product feedback into roadmap options, evidence strength, customer problems, tradeoffs, validation needs, and decision recommendations.

Use this prompt to distinguish customer problems from requested features, reconcile mixed product signals, compare roadmap options, and prepare an evidence-gated decision brief for human review.

Roadmap prioritization review
Customer feedback synthesis
Product discovery handoff
Feature request triage
Executive product decision memo
Sales and support signal review or decline decisions

Evidence-gated roadmap prioritization
Conflicting enterprise feature-request triage
Customer feedback and product-usage reconciliation
Discovery, experiment, defer, or decline decisions
Executive roadmap decision memos with traceability
Pre-review of high-cost or customer-sensitive roadmap proposals

Feedback and feature requests
Customer segments and affected users
Support, sales, and customer success signals
Usage or product data
Strategic goals and business impact
Engineering constraints and dependencies
Decision owner and deadline

Feedback and feature requests
Customer segments and affected users
Support, sales, and customer success signals
Usage or product data
Strategic goals and business impact
Engineering constraints and dependencies
Decision owner and deadline

Fill in the variables with customer feedback, feature requests, affected segments, support/sales/customer success signals, usage data, strategic goals, business impact, engineering constraints, dependencies, decision owner, and deadline. Then run the complete prompt on Claude. Use the output for product review, roadmap planning, discovery scoping, executive decision briefs, or feature triage.

In Claude, replace every bracketed variable with the corresponding source material. Provide the actual feedback records, feature requests, segment definitions, support tickets, sales and customer-success notes, usage exports or summaries, strategy context, business-impact evidence, engineering constraints, dependencies, and decision ownership details. Redact unnecessary personal or confidential data, then run the prompt. Have the named product owner and relevant engineering or risk owners review the resulting recommendation and acceptance ledger before any roadmap or customer-facing action.

A product team has conflicting enterprise requests for a reporting feature and needs to decide whether to ship, validate, defer, decline, or monitor based on evidence strength, customer segment value, engineering constraints, and strategic fit.

A B2B product team receives conflicting requests for configurable reporting from several enterprise accounts. The team supplies interview notes, linked support tickets, CRM renewal context, feature usage data, segment definitions, strategic priorities, architectural dependencies, and the decision deadline. Claude separates the reporting problem from the requested implementation, detects duplicated signals, compares shipping, discovery, improvement, deferral, and decline options, and produces a traceable recommendation with unmet decision gates and human approvals.

Expert

Expert

Claude

Claude

roadmap

roadmap

product-management
roadmap
customer-feedback
evidence-review
prioritization
product-discovery
decision-brief
research-synthesis
tradeoffs
saas
feature-requests
customer-signals
product-strategy

product-management
roadmap-prioritization
customer-feedback
feature-requests
evidence-synthesis
product-discovery
decision-gates
opportunity-cost
product-strategy
executive-decision-brief

Product Feedback to Roadmap Decision Brief Prompt

Product Feedback to Roadmap Decision Brief Prompt

Synthesize customer feedback, support tickets, sales notes, usage data, and product constraints into a roadmap decision brief with evidence strength, tradeoffs, options, and validation needs.

Turn product feedback and usage signals into a traceable roadmap recommendation with decision gates, tradeoffs, verification, and human review.

Prompt-body line comparison

Removed Added Unchanged context

−You are a senior product manager translating messy customer feedback, support signals, sales input, usage data, and business constraints into roadmap decisions.
+Analyze the supplied product evidence and produce a traceable roadmap decision brief. Claude may synthesize only the materials included in this conversation. It cannot inspect product analytics, ticketing systems, CRM records, roadmaps, contracts, or engineering tools unless their contents are supplied. It must not approve, publish, promise, schedule, or execute a roadmap decision.
 
−Synthesize the supplied evidence into a roadmap decision brief that clarifies customer problems, requested solutions, affected segments, evidence strength, tradeoffs, risks, validation needs, and recommended next action.
+## Supplied inputs
 
−The goal is to help product, engineering, sales, support, customer success, and leadership teams make roadmap decisions based on evidence rather than volume, pressure, or isolated requests.
+- Feedback and feature requests: [Feedback and feature requests]
+- Customer segments and affected users: [Customer segments and affected users]
+- Support, sales, and customer success signals: [Support, sales, and customer success signals]
+- Usage or product data: [Usage or product data]
+- Strategic goals and business impact: [Strategic goals and business impact]
+- Engineering constraints and dependencies: [Engineering constraints and dependencies]
+- Decision owner and deadline: [Decision owner and deadline]
 
−## Context Placeholders
+## Input requirements
 
−Use the context below. If feedback sources, customer segments, or the decision being considered are missing, ask for them before producing the brief. If other inputs are missing, continue only with clearly labeled assumptions.
+Treat these as blocking prerequisites for a final roadmap recommendation:
 
−* [Feedback and feature requests]
−* [Customer segments and affected users]
−* [Support, sales, and customer success signals]
−* [Usage or product data]
−* [Strategic goals and business impact]
−* [Engineering constraints and dependencies]
−* [Decision owner and deadline]
+1. The decision or feature area under consideration.
+2. At least one identifiable item of customer, behavioral, support, commercial, or discovery evidence.
+3. The affected or hypothesized customer segment.
+4. The decision owner or the role authorized to accept the recommendation.
 
−## Important Constraints
+If a blocking prerequisite is absent or too ambiguous, ask focused clarification questions and return an intake-gap notice instead of a final recommendation. You may still organize available evidence and identify safe discovery work, but label the decision state as blocked.
 
−* Do not invent facts, metrics, customer quotes, usage data, revenue impact, stakeholder approvals, roadmap commitments, research findings, or engineering estimates.
−* Separate confirmed evidence from assumptions, hypotheses, risks, and recommendations.
−* Label confidence level and uncertainty for every major conclusion.
−* Do not confuse requested features with validated customer problems.
−* Do not recommend shipping a feature only because it was requested loudly or repeatedly.
−* Do not promise roadmap timelines, scope, commercial terms, product capabilities, or customer-facing commitments that were not supplied.
−* Customer-facing roadmap communication must be reviewed by the product owner, account owner, or leadership owner before sharing.
−* Treat missing behavioral data, unclear customer segment, weak problem evidence, unclear business impact, and unknown engineering cost as decision risks.
−* Include human review gates for executive, contractual, commercial, legal, compliance, security, customer-facing, or high-cost roadmap decisions where relevant.
−* Make recommendations specific to the supplied feedback, segments, usage data, strategic goals, engineering constraints, business impact, decision owner, and deadline.
−* Do not present this output as legal, financial, contractual, security, or regulatory advice.
+Useful but non-blocking context includes evidence dates, source identifiers, corpus size, account value, retention relevance, strategic goals, current workarounds, product usage, engineering estimates, dependencies, deadline, and prior decisions. Preserve missing items as unknown rather than estimating them.
 
−## Step-by-Step Instructions
+If inputs conflict, record each conflicting claim, its source, and the decision consequence. Do not silently reconcile disagreement. If the material contains personal data, credentials, confidential contract language, or unnecessary customer identifiers, avoid reproducing them and recommend redaction or restricted review.
 
−1. Summarize the roadmap decision context:
+## Evidence rules
 
−   * feedback sources
−   * customer segments
−   * requested features
−   * support signals
−   * sales notes
−   * usage data
−   * strategic goals
−   * engineering constraints
−   * revenue or retention impact if supplied
−   * decision owner
−   * decision deadline
+1. Assign stable identifiers to supplied evidence, problems, themes, options, assumptions, and open questions so conclusions can be traced.
+2. Distinguish:
+   - supplied fact or direct observation
+   - verbatim customer statement
+   - stakeholder interpretation
+   - behavioral product evidence
+   - commercial signal
+   - engineering constraint or estimate
+   - assumption
+   - hypothesis
+   - unknown
+   - conflict
+3. Never invent quotes, request counts, account values, usage rates, revenue effects, retention effects, dates, estimates, approvals, research findings, or commitments.
+4. Do not treat repeated mentions as independent validation when they come from the same account, copied ticket, sales thread, or underlying incident. Identify possible duplication.
+5. Do not describe request frequency as representative without a known corpus, time window, and denominator. Use qualitative wording when those are unavailable.
+6. Separate the requested solution from the user job, observed pain, workflow consequence, current workaround, and desired outcome.
+7. Treat sales urgency, executive sponsorship, competitive claims, and high-value accounts as relevant signals, not proof that a proposed feature is the correct solution.
+8. Attribute business impact only when supplied. Otherwise state the impact hypothesis and evidence needed to test it.
+9. Use High, Medium, or Low confidence for major conclusions:
+   - High: multiple relevant and reasonably independent sources converge, critical evidence is current enough for the decision, and no material contradiction remains.
+   - Medium: useful evidence exists but has limitations in coverage, independence, recency, or behavioral support.
+   - Low: evidence is sparse, indirect, anecdotal, materially conflicted, or missing on a decision-critical dimension.
+   Explain the basis; do not convert these levels into invented numerical scores.
 
−2. Separate customer problems from requested solutions:
+## Decision workflow
 
−   * underlying user job
−   * pain point
−   * workflow blocker
−   * usability issue
−   * reporting or visibility need
−   * integration need
−   * compliance or admin need
−   * requested feature
−   * workaround currently used
+### 1. Frame the decision
 
−3. Cluster feedback into themes:
+State the decision question, affected product area, target segment, decision owner, deadline, strategic objective, known constraints, and choices actually available. Mark anything not supplied as unknown.
 
−   * frequency of request
−   * affected segment
−   * customer value
−   * revenue or retention relevance
−   * severity
−   * recency
−   * source quality
−   * strategic alignment
−   * support burden
−   * sales pressure
+### 2. Build and normalize the evidence inventory
 
−4. Evaluate evidence strength:
+Extract discrete evidence items without changing their meaning. Identify source type, source date if supplied, segment, direct observation, relevance, independence or duplication concern, limitation, and confidence. Preserve exact quotes only when present and clearly mark them as verbatim.
 
−   * direct customer evidence
−   * behavioral product data
−   * support ticket evidence
−   * sales or renewal evidence
−   * customer success evidence
−   * research or discovery evidence
−   * competitive pressure
−   * internal assumptions
−   * missing validation
+### 3. Map problems separately from solutions
 
−5. Compare roadmap options:
+For each candidate problem, identify the user job, pain or blocker, context, consequence, affected segment, current workaround, requested solution, supporting evidence identifiers, contradicting evidence, and unanswered questions. Do not promote a requested solution into a validated problem statement.
 
−   * ship now
−   * run discovery
−   * prototype or experiment
−   * solve with documentation or onboarding
−   * improve existing feature
−   * defer
−   * decline
−   * monitor
+### 4. Cluster signals without inflating demand
 
−6. Assess tradeoffs:
+Group related evidence into themes. Explain whether each theme represents breadth across accounts or segments, depth within a small number of accounts, behavioral evidence, commercial pressure, support burden, or an internal hypothesis. Note overlap and likely duplicate signals.
 
−   * engineering effort
−   * opportunity cost
−   * maintenance burden
−   * UX complexity
−   * support impact
−   * strategic fit
−   * customer impact
−   * revenue or retention risk
−   * risk of building the wrong thing
+### 5. Evaluate evidence sufficiency
 
−7. Recommend a decision path:
+Assess directness, segment relevance, independence, recency, behavioral corroboration, severity, strategic fit, commercial relevance, and engineering knowledge. Identify which unknowns could change the decision and which are tolerable for the proposed next action.
 
−   * recommended action
−   * rationale
−   * confidence level
−   * assumptions
−   * validation needed
−   * owner
−   * next decision point
+### 6. Compare viable roadmap options
 
−8. Create a validation and handoff plan for product discovery, engineering scoping, stakeholder review, or customer communication.
+Consider only relevant options from: ship, improve an existing capability, prototype or experiment, conduct discovery, use documentation or onboarding, defer, decline, and monitor. For each option, show expected customer outcome, strategic fit, supporting and contradicting evidence, engineering or dependency status, opportunity cost, maintenance and UX implications, commercial or support effects, risks, reversibility, validation needed, and confidence.
 
−## Output Format
+A ship recommendation is eligible only when the problem and target segment are sufficiently supported, strategic fit is explicit, feasibility and dependencies have been reviewed by authorized engineering owners, material security, privacy, legal, compliance, contractual, and commercial concerns have appropriate review paths, and a decision owner is identified. If any gate lacks evidence, mark it unverified and recommend the narrower next action justified by the evidence.
 
−### 1. Evidence Inventory
+A discovery or experiment recommendation must name the decision-changing hypotheses, target participants or cohort, method, evidence to collect, completion signal, and decision rule. A defer, decline, or monitor recommendation must include rationale, affected stakeholders, revisit trigger, and the evidence that could reverse the decision.
 
−Use this table:
+### 7. Form the recommendation
 
−| Evidence Source | What It Shows | Segment Affected | Strength | Recency | Confidence |
−| --------------- | ------------- | ---------------- | -------- | ------- | ---------- |
+Choose one primary disposition and, when useful, one contingent alternative. Tie the rationale to evidence identifiers. State confidence, assumptions, unresolved conflicts, opportunity cost, required approvals, owner, timing constraint, and next decision point. Do not imply that the recommendation is approved or committed.
 
−### 2. Problem and Segment Map
+### 8. Verify and reconcile
 
−Use this table:
+Run the acceptance checks below against the drafted brief. For each check, record the expected condition, actual observation from the draft, evidence inspected, and status as Pass, Fail, or Blocked. Revise correctable failures before presenting the final brief. Preserve failures or blocked checks that require new evidence or human judgment.
 
−| Customer Problem | Requested Solution | Segment | Business Impact | Evidence | Open Questions |
−| ---------------- | ------------------ | ------- | --------------- | -------- | -------------- |
+Required checks:
 
−### 3. Feedback Theme Clusters
+- Every material problem, impact, and recommendation claim traces to supplied evidence or is explicitly labeled as an assumption or hypothesis.
+- Requested solutions remain distinct from validated problems and desired outcomes.
+- Counts, frequency claims, quotes, dates, segment labels, and commercial impacts match the supplied material.
+- Duplicate or dependent signals are not counted as independent corroboration.
+- Supporting evidence, contradicting evidence, and material source conflicts are visible.
+- Engineering constraints, dependencies, estimates, and unknown feasibility are represented without invented certainty.
+- Options are compared against consistent decision dimensions and include opportunity cost.
+- The primary disposition does not exceed the weakest unmet decision-critical gate.
+- Discovery or experiment plans contain a completion signal and decision rule; defer, decline, and monitor paths contain revisit triggers.
+- The named owner, deadline, approvals, and customer-facing commitments are supplied or marked unassigned, unknown, or pending review.
+- No output wording claims approval, validation, measurement, delivery, or customer commitment without corresponding evidence.
 
−Use this table:
+## Required output
 
−| Theme | Related Requests | Source Pattern | Severity | Strategic Fit | Notes |
−| ----- | ---------------- | -------------- | -------- | ------------- | ----- |
+### 1. Decision frame
 
−### 4. Roadmap Options
+Provide the decision question, product area, target segment, owner, deadline, strategic objective, constraints, available dispositions, blocking gaps, and current brief status.
 
−Use this table:
+### 2. Evidence inventory
 
−| Option | Description | Expected Benefit | Tradeoff | Risk | Validation Needed |
−| ------ | ----------- | ---------------- | -------- | ---- | ----------------- |
+| Evidence ID | Source Type | Supplied Observation or Claim | Segment | Date or Window | Independence or Duplication | Limitation | Confidence |
+| --- | --- | --- | --- | --- | --- | --- | --- |
 
−Include ship, discovery, defer, decline, and monitor where relevant.
+Follow with a short source-coverage note stating which relevant systems or records were not supplied and therefore were not inspected.
 
−### 5. Decision Recommendation
+### 3. Problem-to-request map
 
−Use this table:
+| Problem ID | User Job and Context | Observed Pain or Consequence | Requested Solution | Current Workaround | Segment | Supporting Evidence IDs | Contradicting Evidence IDs | Status |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- |
 
−| Recommendation | Rationale | Confidence | Owner | Deadline | Next Decision Point |
−| -------------- | --------- | ---------- | ----- | -------- | ------------------- |
+Use status values such as validated, partially supported, hypothesized, conflicted, or unknown, with a brief justification.
 
−### 6. Tradeoff and Opportunity Cost Review
+### 4. Signal clusters and demand quality
 
−Summarize what the team may need to delay, simplify, reject, or validate before acting.
+| Theme ID | Related Evidence IDs | Breadth and Depth | Source Pattern | Severity | Strategic Relevance | Duplication Risk | Key Unknown |
+| --- | --- | --- | --- | --- | --- | --- | --- |
 
−### 7. Validation and Handoff Plan
+Do not provide an exact frequency unless the supplied corpus and denominator support it.
 
−Use this table:
+### 5. Decision-critical evidence assessment
 
−| Action | Owner Role | Purpose | Evidence Needed | Completion Signal |
−| ------ | ---------- | ------- | --------------- | ----------------- |
+| Dimension | Supporting Evidence | Contradicting or Missing Evidence | Decision Consequence | Confidence |
+| --- | --- | --- | --- | --- |
 
−### 8. Executive Decision Brief
+Include problem validity, segment fit, behavioral support, strategic fit, business impact, support burden, commercial relevance, feasibility, dependencies, and risk review where relevant.
 
−Provide a concise leadership-ready memo covering the customer problem, evidence strength, recommended decision, tradeoffs, risks, validation needs, and unresolved questions.
+### 6. Roadmap option comparison
 
−### 9. Missing Inputs and Human Checks
+| Option ID | Disposition | Customer Outcome | Supporting and Contradicting Evidence IDs | Strategic Fit | Feasibility Status | Opportunity Cost | Material Risks | Reversibility | Validation or Approval Needed | Confidence |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
 
−List missing inputs, assumptions made, blocked decisions, unresolved risks, confidence level, and human reviews required before execution.
+Use not evidenced or unknown instead of filling gaps with assumptions.
 
−## Verification Checklist
+### 7. Decision-gate register
 
−Before finalizing, confirm that:
+| Gate | Required Evidence or Review | Actual Evidence Available | Status | Owner Role | Consequence if Unmet |
+| --- | --- | --- | --- | --- | --- |
 
−* feature requests are separated from validated customer problems
−* evidence strength is clearly labeled
−* customer segments are identified
−* roadmap options include tradeoffs and opportunity cost
−* recommendation includes confidence level
−* validation needs are listed
−* customer-facing commitments require review
−* engineering constraints and dependencies are considered
−* missing inputs and human checks are clearly listed
+Include problem validation, segment definition, strategic alignment, engineering feasibility and dependencies, material risk reviews, decision authority, and customer-communication review as applicable.
 
−## Final Instruction to Begin
+### 8. Recommendation record
 
−Begin now. First review the supplied feedback, feature requests, customer segments, support signals, sales notes, usage data, strategic goals, engineering constraints, business impact, decision owner, and deadline. If required context is missing, ask for it. Otherwise, produce the full product feedback evidence to roadmap decision brief in the requested markdown format.
+State:
+
+- primary disposition
+- contingent alternative
+- rationale linked to evidence identifiers
+- confidence and its basis
+- assumptions and unresolved conflicts
+- expected benefit stated without unsupported quantification
+- opportunity cost and rejected alternatives
+- required human approvals
+- accountable owner or unassigned status
+- next decision point and timing constraint
+- whether the recommendation is decision-ready, conditionally ready, or blocked
+
+Explicitly state: Recommendation only; not an approval, roadmap commitment, engineering estimate, or customer promise.
+
+### 9. Validation and handoff plan
+
+| Action ID | Hypothesis or Question | Method | Target Segment or Cohort | Evidence Needed | Owner Role | Completion Signal | Decision Rule | Handoff Recipient |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- |
+
+Separate proposed work from work already completed. If completion evidence was not supplied, do not mark an action complete.
+
+### 10. Verification and acceptance ledger
+
+| Check | Expected Condition | Actual Observation | Evidence Inspected | Status | Reconciliation or Required Action |
+| --- | --- | --- | --- | --- | --- |
+
+After the table, assign both states independently:
+
+- Brief quality state: accepted only if all correctable checks pass and every remaining blocked item is explicit.
+- Decision authorization state: pending unless an authorized human approval is supplied; never infer authorization from the brief quality state.
+
+### 11. Executive decision memo
+
+Provide a concise memo covering the customer problem, affected segment, evidence strength, primary disposition, alternatives considered, opportunity cost, unresolved risks, required validation, owner, and next decision point. Preserve uncertainty and avoid unsupported commitments.
+
+### 12. Open issues and human review
+
+List missing inputs, assumptions, conflicts, failed or blocked acceptance checks, unassigned owners, and required product, engineering, commercial, customer-success, security, privacy, legal, compliance, or leadership reviews that are relevant to the supplied decision. Do not add irrelevant review categories.
+
+Begin by checking the blocking prerequisites. If they are sufficient, produce the complete brief. If not, provide the intake-gap notice, focused clarification questions, and any bounded evidence organization that can be completed safely.