Using MCP to cross-check roadmap requests
With more and more services exposing MCPs, the number of clever ways to get insights and take actions based on disorganized data is growing.
Previously I shared how I automated my diary habit with Tana MCP and Claude Code, which helped me streamline my goal achievement.
In today’s article, I’d like to share an example from my professional field – building products. Read my take on how AI can help you arrive at a more customer-focused roadmap, spot and correct gaps in your current product strategy.
The problem
Imagine that you’re building a B2B app and (obviously) want to improve your sales funnel and customer retention.
You are meeting with potential and existing clients, using your tool of choice for meeting recordings and note keeping. You also encourage customers to share their problems on a portal, in a Slack channel or a social media group, or by commenting on your public roadmap.
However, when it comes to piecing it all together, you might face 2 problems:
- Selection bias: some of your customers will be more vocal than others, skewing the picture towards their problems
- Complicated synthesis: aggregating and unifying all data sources into a coherent narrative will take too long
So, you decide to go with your gut and make some roadmap bets, which might (or might not) play well. However, you would still very much like to have a more feedback-driven approach for yourself, your team and stakeholders.
Using AI and MCPs to read and synthesize the data
Luckily, with AI the task becomes much easier. Let’s assume your stack is:
- Granola for meeting recording
- Slack for community discussions
- Pipedrive for storing sales notes
- Claude Code for AI
Make a directory (call it customer_feedback), run Claude inside it, and add MCP tools:
claude mcp add --transport http granola https://mcp.granola.ai/mcp
claude mcp login granola
claude mcp add --transport http pipedrive https://mcp.pipedrive.ai/mcp
claude mcp login pipedrive
claude plugin install slack
Hint: run claude mcp list afterwards; each server should come back connected rather than Needs authentication.
Then run /init and explain the purpose of the project, e.g. to collect and organise sources of customer feedback.
Now, when you need to understand which features are continuously raised by customers across all sources in 2026, you can use any thinking model to build the dataset. Below is an example prompt; yours will probably take a few more iterations.
## System prompt
You are a customer intelligence expert.
Read customer insights by calling each of these MCP servers:
- Granola (meeting notes)
- Slack (community channel)
- Pipedrive (sales notes)
## Task
Build a dataset of the features most demanded by customers in 2026.
Work in this order, and stop for my confirmation after step 2:
1. Pull the raw mentions from each source separately. For every mention record
the date, source, customer, feature requested, and a quote from sales notes.
Report how many meetings, messages and deals you actually searched.
2. Normalise feature names. The same feature is named differently in different
places ("SSO", "Okta login", "SAML"). Map them to one canonical name per
feature and show me the mapping before you score anything.
3. Score every mention on the factors below, then combine them into a weighted
average per feature, per month, per lifecycle stage:
- tone of the conversation (keywords like "urgent", "must have", "critical")
- customer LTV
- customer lifecycle stage (lead, new customer, loyal customer)
- direct reference to a competitor already having this feature
- the feature being given as a reason for churn (1/0)
State the weight you assign to each factor and why. I want to argue with the
weights, so don't bury them.
## Expected result
A CSV file, one row per feature x month x lifecycle stage, with columns:
| column | type | notes |
|------------------------|---------------|----------------------------------------|
| month | YYYY-MM | calendar month of the mention |
| feature | text | canonical name from step 2 |
| description | text | one line, what the customer wants |
| lifecycle_stage | enum | lead / new customer / loyal customer |
| mentions | int | distinct mentions in that cell |
| weighted_mention_score | float 0-100 | weighted average, never a sum |
| competitors | ;-separated | named competitors, empty if none |
| churn_linked | 0/1 | tied to a churn or lost-deal event |
| lost_revenue_usd | int | attributed revenue, 0 when not churned |
Rules:
- Never invent a mention. If a source returns nothing for a month, leave the
gap; an empty cell is data.
- Quote the customer's own words in `description` where you can.
- Flag any feature where fewer than three mentions carry the score.
Once the AI is done, it should produce something like this:
| month | feature | stage | mentions | score | competitors | lost revenue |
|---|---|---|---|---|---|---|
| 2026-07 | SAML / SSO | loyal customer | 6 | 91.1 | Northwind, Quantly | $20,300 |
| 2026-07 | EU data residency | loyal customer | 5 | 91.1 | Northwind, Orbital | $29,700 |
| 2026-07 | SAML / SSO | new customer | 6 | 82.4 | Northwind, Quantly | — |
| 2026-07 | Salesforce two-way sync | loyal customer | 7 | 78.1 | Orbital | $17,700 |
| 2026-07 | Audit log export | loyal customer | 6 | 71.9 | Quantly | — |
| 2026-07 | Salesforce two-way sync | new customer | 7 | 69.8 | — | — |
Writing a Jupyter notebook to show and tell
You can just put the data in a spreadsheet, but there are reasons I like to take it a bit further and do a step-by-step exploratory data analysis:
- You can share both the data source and the analysis with your team, so they can explore side alleys and derive their own conclusions
- If the data needs to be presented, you can lean on step-by-step exploration to tell the story with numbers
So, let’s use AI again and ask it to do an EDA and answer the following questions:
- Which features contribute the most to the churn rate for leads (potential customers)? Which for the loyal customers?
- Which top-3 features grew or declined by mention score throughout this year?
- Which competitors are currently brought up the most, and what’s the cost of churn for each of those?
You can find the resulting example notebook in my skills repo, together with the sample dataset it runs on.
Results might tell you a very interesting story. Imagine the two cohorts turned out not to churn over the same things at all – leads walked away over the features they get evaluated against during the buying process, while long-standing customers left over gaps they only hit after months of living in the product. And the competitor named most often was not the competitor that cost the most; the loudest one was cheap, and a quieter one showed up rarely but almost always on a deal that then died.
I encourage you to give it a try, either locally, or with try-jupyter, or with your BI tool of choice (e.g. Hex).
Saving results and cross-checking the requests against your roadmap
Now, when you have the results of the analysis, it’d be great to save it for later, so that you won’t need to recreate it from scratch next month. Just tell Claude to save the session as a skill, and next time you could just use it with the /customer-feedback-analysis command. Start with my ready-to-use skill as something that already works, and tailor it to your needs.
Then, during your next roadmap planning session, check how the roadmap actually matches against the analysis you did. Three buckets to explore here: which roadmap items have no demand behind them at all, which high-demand features are missing from the roadmap, and where is demand vs effort is unbalanced.
Word of caution
Despite the power of what we just did, I’d like to warn against over-using AI, or blindly trusting the results. Don’t write off your gut and your knowledge of the product and customers, stay informed and apply critical thinking, and always check for hallucinations. :)
Drop your thoughts in comments on Substack, and good luck with your data explorations!