AI for Product Managers

Too much feedback, too little reading time

A product manager at a SaaS company with 800 customers can easily have 3,000 support tickets, 400 feature requests, a few hundred app reviews and a folder of interview notes from the last quarter. Nobody reads all of it. So decisions get made on the loudest customer, the most recent call or the sales team's latest complaint.

This is where AI for product managers is most useful. Grouping large amounts of text into themes and summarising each theme with representative quotes is a strength of current models, and it gives a PM a view of the whole pile rather than the top of it.

Feedback synthesis that stays honest

The risk with AI synthesis is that it produces neat themes that sound right but are loosely connected to the evidence. The fix is in the design.

• Every theme shows how many items it covers and links to them
• Every theme includes three to five direct customer quotes, not paraphrases
• Counts are computed by code from the classified items, not written by the model
• Themes are tagged by customer segment and plan, so enterprise and small accounts are not blended
• A 'did not fit' bucket that the PM actually reads, because surprises live there

Illustrative figures, but this is the output shape to aim for. The PM can click into 'permissions too coarse', read twenty real tickets in five minutes and decide whether the theme holds up.

Specs, stories and the blank page

Drafting is the second use. Given a problem statement, the relevant feedback theme and notes from a design session, a model can produce a reasonable first draft of a spec: context, user stories, acceptance criteria, open questions and edge cases.

The edge-case list is often the most valuable part. Models are good at asking 'what happens if the user has no permission, the export fails halfway, the currency differs', which are exactly the questions engineers raise in refinement. Getting them on paper earlier saves a meeting.

What a model cannot supply is the product judgement: why this, why now, what we are deliberately not doing. A spec where those sections were written by AI reads as plausible and says nothing.

One habit that works well: write the problem statement and the non-goals yourself, in a few plain sentences, before asking for any draft. The model then fills in stories and criteria inside a boundary you set, rather than inventing scope. It also makes review faster, because engineers can see at a glance whether the draft has wandered outside what was agreed. If a PM finds they cannot write those few sentences, the spec was not ready to be drafted by anyone, human or otherwise.

Research preparation and summaries

1. Draft interview guides from your research questions, then cut the leading questions the model will include
2. Transcribe and summarise interviews, keeping timestamps and quotes
3. Compare summaries across interviews to find agreement and contradiction
4. Summarise competitor documentation and public changelogs to see what has shipped

One caution on interviews: AI summaries flatten hesitation and tone. A customer who says 'yes, I suppose we would use that' is not the same as one who says 'we need that', and a summary can make them look alike. Read the transcripts for anything you are about to bet a quarter on.

There is also a sampling problem no model fixes. Interview summaries only reflect the customers you managed to interview, which tend to be the engaged ones. The silent accounts that quietly stopped logging in are rarely on the call list, so balance interview themes against usage data before drawing big conclusions.

What must stay with the product manager

Prioritisation is the job. A model can rank feature requests by volume, but volume is not value. Ten requests from customers about to churn may matter more than a hundred from happy free users, and strategy may say to build neither. We wrote about that tension in feature requests and roadmap decisions.

AI can tell you what customers asked for. Deciding what to build, and especially what to refuse, is still what you are paid for.

The same goes for stakeholder conversations, trade-offs with engineering and pricing decisions. These rely on context and relationships that do not live in any dataset.

When this is not worth building

If you have a few dozen customers and talk to most of them monthly, you already know the themes and a synthesis tool adds little. Several feedback and product analytics platforms also include AI clustering now, and they are usually good enough to try before building anything.

Custom work makes sense when feedback lives in many systems, when you need it joined with usage and revenue data, or when the platform's themes are too generic for your domain.

Building a feedback pipeline

At SpiderHunts we usually build this as a small pipeline: pull feedback from the helpdesk, CRM, review sites and interview notes; classify each item; join it to account data such as plan and revenue; and publish themes to wherever the product team already works. Our SaaS development team builds these for product companies, and the SaaS guide covers the wider product context.

Frequently asked questions