Product Feedback Evidence to Roadmap Decision Brief

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.

## Supplied inputs

- 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]

## Input requirements

Treat these as blocking prerequisites for a final roadmap recommendation:

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.

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.

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.

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.

## Evidence rules

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.

## Decision workflow

### 1. Frame the decision

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.

### 2. Build and normalize the evidence inventory

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.

### 3. Map problems separately from solutions

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.

### 4. Cluster signals without inflating demand

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.

### 5. Evaluate evidence sufficiency

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.

### 6. Compare viable roadmap options

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.

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.

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.

### 7. Form the recommendation

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.

### 8. Verify and reconcile

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.

Required checks:

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

## Required output

### 1. Decision frame

Provide the decision question, product area, target segment, owner, deadline, strategic objective, constraints, available dispositions, blocking gaps, and current brief status.

### 2. Evidence inventory

| Evidence ID | Source Type | Supplied Observation or Claim | Segment | Date or Window | Independence or Duplication | Limitation | Confidence |
| --- | --- | --- | --- | --- | --- | --- | --- |

Follow with a short source-coverage note stating which relevant systems or records were not supplied and therefore were not inspected.

### 3. Problem-to-request map

| Problem ID | User Job and Context | Observed Pain or Consequence | Requested Solution | Current Workaround | Segment | Supporting Evidence IDs | Contradicting Evidence IDs | Status |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |

Use status values such as validated, partially supported, hypothesized, conflicted, or unknown, with a brief justification.

### 4. Signal clusters and demand quality

| Theme ID | Related Evidence IDs | Breadth and Depth | Source Pattern | Severity | Strategic Relevance | Duplication Risk | Key Unknown |
| --- | --- | --- | --- | --- | --- | --- | --- |

Do not provide an exact frequency unless the supplied corpus and denominator support it.

### 5. Decision-critical evidence assessment

| Dimension | Supporting Evidence | Contradicting or Missing Evidence | Decision Consequence | Confidence |
| --- | --- | --- | --- | --- |

Include problem validity, segment fit, behavioral support, strategic fit, business impact, support burden, commercial relevance, feasibility, dependencies, and risk review where relevant.

### 6. Roadmap option comparison

| Option ID | Disposition | Customer Outcome | Supporting and Contradicting Evidence IDs | Strategic Fit | Feasibility Status | Opportunity Cost | Material Risks | Reversibility | Validation or Approval Needed | Confidence |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |

Use not evidenced or unknown instead of filling gaps with assumptions.

### 7. Decision-gate register

| Gate | Required Evidence or Review | Actual Evidence Available | Status | Owner Role | Consequence if Unmet |
| --- | --- | --- | --- | --- | --- |

Include problem validation, segment definition, strategic alignment, engineering feasibility and dependencies, material risk reviews, decision authority, and customer-communication review as applicable.

### 8. Recommendation record

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.