# Prioritize product problems with customer and usage evidence
> Compare repeated customer pain with observed feature usage and backlog context before proposing roadmap priorities.
Canonical: https://www.mcpfolio.com/workflows/customer-feedback-priority-brief
## Target user

Product managers deciding which customer problems deserve discovery or roadmap time.

## Trigger

Quarterly planning or a backlog item has strong opinions but little comparable evidence.

## Why run it repeatedly

At planning and discovery checkpoints. A team's actual cadence and time spent are unvalidated.

## What you receive

A ranked discussion brief showing customer evidence, affected usage cohorts, existing work, uncertainty, and follow-up research questions.

## Pain evidence

Several first-person product discussions describe combining feedback and usage signals; no reliable prevalence, cost, or willingness-to-pay estimate was found.

## Alternatives and remaining gap

Productboard and analytics suites already connect feedback and product usage. A warehouse query is stronger for repeatable numeric joins. AI helps summarize qualitative evidence and explain disagreement, not calculate counts or set strategy.

## Execution flow

1. Define one product problem, date range, event/cohort definition, and approved customer fields.
2. Retrieve matching feedback and group by underlying task/problem while retaining links and counterexamples.
3. Query Amplitude for the agreed events and cohorts; validate event freshness, identity stitching, and sample sizes.
4. Search Linear for planned work and duplicate issues; compare evidence without treating usage as causal proof.
5. Return a ranked discussion brief with criteria, evidence gaps, and research questions; do not change roadmap priority.

## Required tools

- Intercom: search_conversations, get_conversation, get_company
- Amplitude: query_amplitude_data, get_amplitude_charts, get_session_replays
- Linear: list_issues, get_issue

## Prerequisites and costs

Intercom read access; Amplitude project access and agreed event taxonomy/identity joins; Linear read access; product team supplies prioritization criteria. Feature availability and plans depend on accounts.

## Run this prompt

```text
Assess [problem/theme] over [date range]. Use only approved Intercom fields and Amplitude events [list]. Show direct customer evidence and usage counts separately. Validate event definitions, identity stitching, data freshness, and cohort sizes. Compare existing Linear work. Apply these criteria [criteria], but do not commit roadmap scope or infer causality. Return evidence, counterexamples, uncertainties, and questions for customer research.
```

## Review checkpoints

A PM validates event definitions, account identity, sample size, business criteria, and customer interpretation. Human discovery remains necessary before a roadmap commitment.

## Limitations

Evidence supports the broad prioritization task, but does not prove that MCP synthesis beats product-management platforms. Event schema and account revenue joins are organization-specific; correlation between feedback and usage is not causal evidence.

## Manual work and missing capabilities

Event taxonomy verification, stable account/user mapping, business value/effort estimates, customer interviews, and a PM decision.

## Failure handling

Use bounded retries for read failures and mark partial results incomplete. Keep source record IDs and links. Do not guess across missing or conflicting identifiers. Search for an existing target record before any approved write, then retrieve it to verify.

## Pilot acceptance criteria

All metrics reproduce from the named Amplitude query; all qualitative claims link to records; low sample sizes and broken instrumentation are flagged; no unsupported priority or causal claim is made.

## Product fit

MCPfolio recipe for evidence assembly. A durable product-discovery package is justified only if interviews show these joins are repeatedly missing from existing feedback platforms.

## Demo storyboard

Compare two synthetic product problems with linked feedback, defined usage cohorts, an event-quality caveat, and current Linear status; show that the output recommends a research question rather than declaring a winner.

## Evidence

Pain reported by users; official tool docs/catalog checked; workflow not runtime tested

## Required MCPs

- [Intercom MCP](https://www.mcpfolio.com/servers/intercom): Supplies source conversations and customer-stated impact.
- [Amplitude MCP](https://www.mcpfolio.com/servers/amplitude): Queries usage cohorts and product events for the relevant flow.
- [Linear MCP](https://www.mcpfolio.com/servers/linear): Checks current backlog commitments and drafts a reviewed decision record.

## Official sources

- [PM discussion of prioritizing customer requests](https://www.reddit.com/r/ProductManagement/comments/1ggdzb9/)
- [Qualitative feedback triage discussion](https://www.reddit.com/r/ProductManagement/comments/1l7n9lr/)
- [Intercom MCP docs](https://developers.intercom.com/docs/guides/mcp)
- [Amplitude MCP docs](https://amplitude.com/docs/amplitude-ai/amplitude-mcp)
- [Linear MCP docs](https://linear.app/docs/mcp)


## Related

- [All workflows](https://www.mcpfolio.com/workflows)