This closing topic assembles everything from the module into one end-to-end pass: raw CRM data in, a prioritized, evidenced backlog item out, with full traceability back to the source records. It's written as a runnable sequence you can adapt to any client covered so far — Claude Code, Cursor, Gemini CLI, or OpenCode — since the underlying tool calls are identical; only the surrounding ergonomics differ.
Workflow Overview: CRM Data to Product Decision
The failure mode this workflow is designed to avoid is the one every product team has lived through: a loud customer, a squeaky-wheel escalation, or a single memorable sales call ends up driving a roadmap decision that a quieter, larger pattern in the data would have deprioritized. HubSpot MCP doesn't remove human judgment from prioritization — it removes the excuse for prioritizing on vibes when the evidence was sitting in the CRM the whole time.
The workflow has four stages, each producing an artifact that feeds the next:
Tickets + Deals + Notes → Themes → Quantified Impact → Backlog Item
(raw CRM objects) (extraction) (revenue/segment) (linked, ranked)
Each stage is deliberately a separate prompt/session rather than one giant request. Chaining four non-trivial CRM operations into a single unreviewed prompt is where things go wrong — pagination gets silently truncated, a theme extraction conflates two distinct issues, or a revenue sum double-counts a deal that appears in two searches. Reviewing the intermediate artifact at each stage is the actual discipline this workflow teaches; the tool calls are the easy part.
Tips
- Run this as four checkpoints, not one prompt — the value of the workflow is in reviewing each intermediate artifact, not in automating away the review.
- Timestamp and snapshot each stage's output (a markdown file per stage is enough) — CRM data changes daily, and a backlog item justified by data from two weeks ago should say so explicitly.
- Assign a human owner to the final judgment call at Step 3 → Step 4 — quantified impact narrows the debate, it doesn't end it; a $200K theme with three affected customers and a $200K theme with thirty affected customers carry very different retention risk even at equal dollar totals.
Step 1: Extracting Themes from Tickets, Deals, and Sales Notes
Start wide, across all three CRM object types that carry customer voice, over a fixed and stated time window:
> Search: (1) open tickets from the last 90 days with priority HIGH or
URGENT, properties: subject, content, product_area; (2) closed-lost
deals from the last 4 quarters with amount > 5000, properties:
dealname, amount, closed_lost_reason, closedate; (3) notes
associated with any deal in stage "Contract Sent" or later dated in
the last 90 days.
Paginate fully on each search and report total counts.
From the combined text across all three sources, extract every
distinct product theme or missing-capability mention. Do not merge
themes that are only superficially similar — "export is slow" and
"export times out" are the same theme; "export is slow" and "can't
filter export columns" are not.
The instruction to resist over-merging matters more than it looks — LLMs default toward tidy, small category counts, and a theme-extraction pass with no guardrail will happily collapse eight distinct complaints into three neat buckets, which destroys exactly the granularity you need for prioritization later.
A first-pass output, saved as an artifact for the next stage:
## Raw Theme Extraction — 2026-08-21 (90-day ticket window, 4Q deal window)
Sources: 214 tickets (of 214 total), 89 closed-lost deals (of 89 total),
61 notes (of 61 total)
1. Bulk CSV export timeout on large accounts — 23 ticket mentions, 4
closed-lost deal mentions
2. No SSO/SAML support — 6 ticket mentions, 11 closed-lost deal
mentions, 4 note mentions from Contract Sent-stage deals
3. No field-level export column filtering — 9 ticket mentions
4. Slow report generation on dashboards with >10 widgets — 14 ticket
mentions, 1 deal mention
5. Missing audit log export — 3 ticket mentions, 2 note mentions
Note that every count here is source-labeled and the total pool sizes are stated up front — that's the difference between an extraction you can defend in a prioritization meeting and one you can't.
Tips
- Explicitly instruct against over-merging themes — the default LLM behavior toward tidy small category counts actively works against the granularity prioritization needs.
- State the full source pool size (total tickets/deals/notes searched) alongside every theme's mention count — a count without its denominator is not evidence, it's a vibe with a number attached.
- Re-run extraction with a wider time window if a theme's mention count looks suspiciously low — 90 days can miss a slow-building pattern that a 6-month window would catch clearly.
Step 2: Quantifying Impact by Revenue, Segment, and Churn Risk
Take the raw theme list from Step 1 and attach dollar and account-level weight to each — this is the step that turns "23 people complained" into "this is worth building."
> For each theme in the attached list, calculate:
1. Total lost ACV — sum of amount on closed-lost deals mentioning
this theme (avoid double-counting a deal that matches two themes;
list it under both but flag the overlap).
2. Total at-risk ACV — sum of amount on OPEN deals whose associated
company also has a ticket mentioning this theme.
3. Affected account count — distinct count of companies across all
mentions (tickets + deals + notes) for this theme.
4. Segment breakdown — for affected companies, pull the "customer_tier"
custom property and show the count by tier (Enterprise, Mid-Market,
SMB).
Flag any theme where affected accounts skew heavily toward one
segment — that changes the urgency calculus independent of raw
dollar totals.
This step requires the widest association fan-out in the whole workflow — ticket to company, deal to company, note to company — and is the most likely place for double counting if you don't explicitly ask for overlap flagging, since the same enterprise account often shows up in multiple sources for the same underlying complaint.
## Quantified Impact — Theme Ranking
| Theme | Lost ACV | At-Risk ACV | Total | Accounts | Segment Skew |
|----------------------------|----------:|------------:|----------:|---------:|--------------------------|
| No SSO/SAML | $410,000 | $260,000 | $670,000 | 14 | 12/14 Enterprise |
| Bulk export timeout | $85,000 | $140,000 | $225,000 | 22 | Even across tiers |
| Slow dashboard reports | $12,000 | $30,000 | $42,000 | 15 | Mostly Mid-Market |
| No field-level export | $0 | $0 | $0 | 9 | SMB only, no deal impact |
| Missing audit log export | $60,000 | $180,000 | $240,000 | 5 | 5/5 Enterprise |
The table reshuffles the naive mention-count ranking from Step 1 in an important way: "field-level export filtering," which had a healthy 9 mentions, drops to the bottom because it's never once shown up attached to a deal — it's an SMB usability annoyance with zero revenue signal, not a retention or expansion risk. "Missing audit log export," with only 5 accounts and 3 raw mentions, jumps up because every single one of those 5 is Enterprise and worth real money. That reordering is the entire point of doing Step 2 at all — mention count alone would have prioritized wrong.
Tips
- Explicitly ask for overlap/double-counting flags on any deal or account that matches multiple themes — CRM associations fan out fast, and silent double-counting inflates exactly the numbers a prioritization decision will lean on hardest.
- Segment skew is often more decision-relevant than raw dollar total — a $42K Mid-Market issue with broad reach and a $240K Enterprise-only issue with concentrated reach require genuinely different responses (self-serve fix vs. white-glove retention play).
- Treat a $0-revenue-impact theme as real feedback, not noise — it may be exactly right for a fast, low-cost UX fix even though it doesn't belong at the top of a revenue-ranked list.
Step 3: Creating Prioritized Backlog Items Linked Back to CRM Records
With the ranked, quantified theme list validated by a human (this is the checkpoint where a PM or eng lead should actually look at the table before proceeding), generate the backlog items themselves — one per theme that clears whatever bar your team uses for roadmap consideration.
> For the top 3 themes by total impact, draft a backlog item each with
this structure:
- Title
- Problem statement (2-3 sentences, cite specific ticket/deal IDs)
- Quantified impact (from the Step 2 table)
- Representative customer quotes (2, verbatim, with source ticket/
note ID, redact any customer names/emails/phone numbers)
- Segment affected
- Suggested acceptance criteria (functional, testable)
- Linked CRM records (ticket IDs, deal IDs, note IDs for traceability)
Do not suggest a specific engineering implementation approach unless
I ask — that's a separate conversation with the owning team.
A resulting backlog item, ready to paste into Jira, Linear, or GitHub Issues (or created directly if that tool's MCP server is also connected in the same session):
### Backlog Item: SAML/SSO Support for Enterprise Accounts
**Problem statement:** 14 distinct accounts have raised SSO/SAML as a
blocker across sales notes, support tickets, and closed-lost deal
reasons over the last 4 quarters. 12 of 14 are Enterprise-tier. Total
revenue impact: $670,000 (lost + at-risk ACV).
**Representative quotes:**
- Deal note, [REDACTED-NAME] (Acct #a19f3b): "Security team confirmed
they cannot proceed without SAML — this is a hard procurement gate,
not a preference." (Deal ID 90234871, stage: Closed Lost)
- Ticket #5102: "Our compliance team flagged the lack of SSO during
renewal review. Need a timeline or we have to escalate internally."
**Segment affected:** Enterprise (12/14 accounts), Mid-Market (2/14)
**Suggested acceptance criteria:**
- Support SAML 2.0 SP-initiated login for at least one major IdP
(Okta, Azure AD) in the first release
- Existing password-based login remains available during transition
- Admin UI to configure SAML settings per organization
**Linked CRM records:** Deals #90234871, #88213904, #91002211 (+11
more); Tickets #5102, #5089, #4991 (+3 more); Notes: 4 associated with
above deals
*Data snapshot: 2026-08-21, 90-day ticket window, 4-quarter deal
window. Re-verify before final roadmap commitment if more than 30 days
have passed.*
That "Linked CRM records" section and the data-snapshot timestamp are not optional flourishes — they're what separates this from a plausible-sounding AI summary. Anyone skeptical of the prioritization call can click through to deal #90234871 in HubSpot directly and read the original note themselves. That auditability is the actual deliverable of this whole module — not the summary text, but the ability to verify it.
If your team also has an issue tracker MCP server connected (Jira, Linear, GitHub — see the relevant modules elsewhere in this course), you can close the loop in the same session:
> Create this as a Linear issue in the "Product" team, label
"customer-driven", priority based on the impact tier (Enterprise-
majority + >$500K = P1). Include the linked CRM record IDs in the
issue description, not just in a comment.
Tips
- Never omit the source CRM record IDs from a generated backlog item — they're the difference between a decision someone can audit and one they just have to trust.
- Stamp every backlog item with the data snapshot date and window used — a "customer-driven" ticket that's secretly six months stale is worse than one honestly labeled as needing a refresh before final commitment.
- Keep the acceptance criteria functional and testable, and explicitly hold the agent back from prescribing implementation details unless asked — CRM data tells you what customers need, not how your team should architect the fix, and blurring that line undercuts the engineering team's own design judgment.
Tips
Tips
- Run the four stages as separate, reviewed checkpoints every time — the discipline of checking each intermediate artifact is what makes this workflow trustworthy, not any single clever prompt.
- Standardize the redaction and traceability requirements (redact PII in quotes, always include source record IDs, always stamp a data snapshot date) as a reusable prompt template or project-level agent instruction, so every backlog item produced this way meets the same bar regardless of who ran the session.
- Revisit closed-out themes periodically — a theme that scored low three months ago (like the SMB-only export filtering request) can shift materially as your customer mix changes, and this whole workflow is cheap enough to re-run quarterly rather than treating any single pass as final.