How an AI agent can turn product evidence into a de-duplicated roadmap discussion
This workflow gives an AI agent a defined job, a bounded set of records, and a result a person can review. The agent reads the relevant Pendo context and matches it with Linear, applies the rules in the prompt, and keeps the source behind every recommendation. It returns a proposed handoff rather than taking consequential actions on its own.
Can an AI agent turn product evidence into a de-duplicated roadmap discussion?
Yes. Start with the scope, date range, decision rules, and fields that identify the right records. The agent can collect the evidence, compare states or sources, mark conflicts and missing data, and organize the result around the outcome above. A reviewer then checks the matches and judgment calls before approving messages, record updates, bookings, purchases, publishing, or other write actions. The guide below shows the records, boundaries, prompt, and handoff needed for this specific workflow.
Match evidence to existing work
Pendo supplies source feedback, account context, themes, and product evidence. Linear supplies existing issues, projects, owners, status, and acceptance criteria. The pair helps a product team connect a real user problem to work already planned or discover that no issue represents it.
The agent should compare the problem described in Pendo with the scope of each Linear issue, not match on a shared keyword alone. One request may relate to several issues, and one issue may address only part of a theme. Preserve those partial matches.
Example starter prompt
Compare Pendo feedback in [saved view or source list] with Linear [team or project].
For each feedback theme, cite the Pendo records and find related Linear issues. Classify matches as direct, partial, duplicate, or none. Show issue status, owner, and which part of the user problem is covered or missing.
Draft updates or discovery issues for review, but do not change Linear, edit Pendo feedback, or assign priority.Keep evidence attached after handoff
Every proposed Linear change should carry links to the source feedback and a concise statement of the user problem. Avoid pasting sensitive customer details into broadly visible issues.
Questions this workflow answers
Does customer feedback already map to planned work, or is there a gap the roadmap has not captured?
The agent treats this as a scope comparison rather than a keyword search. It first reduces each feedback cluster to a user problem, affected workflow, conditions, and evidence links. It then reads candidate issues and projects to understand their promised behavior and acceptance criteria. An issue titled “improve exports” is not a direct match for complaints about missing filtered rows unless its scope says it will correct that behavior.
The output uses four useful relationships. A direct match covers the reported problem and affected path. A partial match addresses one condition but leaves another unresolved. A duplicate points to another issue that already represents the same work. No match means the team has evidence without a corresponding roadmap item. Each relationship includes a short explanation and the records on both sides, so a product owner can see why the agent chose it.
Status changes deserve another check. Feedback may still map to an issue marked done if the report concerns an old app version, a failed rollout, or a different surface. The agent records report dates, release context where available, and whether the user’s evidence predates or follows completion. It does not reopen work or declare a regression on its own.
For uncovered evidence, the agent can draft a discovery issue with the problem, affected audience, examples, unknowns, and a proposed validation step. It should not turn one customer request into a committed solution or paste private account notes into a broadly visible project. Existing labels, team ownership, and issue templates are followed rather than guessed.
The product owner receives a review queue: confirmed links, questionable matches, stale issues, and draft discovery work. Only after reviewing scope and visibility do they update an issue, create a new one, or decide that the evidence should remain in the research backlog.
The product owner reviews deduplication, scope, and priority. The final handoff should also preserve feedback that does not justify work yet, so it can be revisited with future evidence.