AI in Product Management: Start with the Workflow
The useful question is where work gets stuck
There is no shortage of ideas for using AI in product management. Summarise a document. Write a PRD. Create a roadmap. Turn meeting notes into action items.
The harder question is whether any of these activities makes the work better. A longer document is easy to produce. A clearer decision takes more thought.
I find it more useful to start with a recurring task: something that consumes time, involves several sources, or requires people to carry context from one conversation into another. Then I ask which part AI can help with and which part still needs a person to make a call.
Separate preparation from decisions
A product requirement contains different kinds of work. Some of it is preparation: reading background material, grouping related requests, extracting constraints and drafting acceptance criteria. Some of it is judgment: deciding whose problem to solve, what to defer and what risk is acceptable.
AI can help with preparation. It can also suggest options for a decision. But a suggestion is not evidence that the option is commercially sensible or technically feasible.
For example, an integration specification may describe a successful response clearly while leaving timeout behavior ambiguous. A useful AI output would flag the missing behavior and point to the relevant section. An unhelpful output would quietly fill the gap with a plausible assumption and present the requirement as complete.
That distinction matters because polished language can make an unresolved question look settled.
Give the task a clear boundary
“Analyse this specification” leaves too much room for interpretation. A more useful instruction defines the output and how uncertainty should appear:
Extract the supported transaction types, mandatory fields, error responses and retry rules. Reference the relevant sections. Mark anything not explicitly stated as an open question.
This creates something a reviewer can check. It also makes the output reusable: the open questions can become a partner discussion, and the verified details can feed requirements and test scenarios.
The same approach works for meeting notes. Separate decisions, proposals, owners and unresolved questions. If no owner was agreed, leave the owner unassigned. If a date was discussed but not committed, keep that distinction visible.
Put review at the point where errors become expensive
Not every AI-assisted task needs the same level of checking. A first draft of an internal update is different from a requirement that engineering will build against.
I would place stronger review around API behavior, customer commitments, launch dates and any statement that becomes an acceptance condition. For those outputs, the reviewer should be able to trace a claim back to a source or identify it as a proposal.
For a weekly delivery update, a simple structure helps: what changed, what is blocked, what decision is needed, and who needs to act. The goal is to make the next conversation easier, rather than repeat every ticket description.
Measure the whole task
Generation time is only one part of the effort. If a draft takes seconds to create but a long time to correct, the gain may be small.
For a repeated workflow, compare total time before and after introducing AI. Include preparation, review, corrections and follow-up questions. Also look at quality: are requirements clearer, are fewer questions rediscovered, and can another person understand the output without attending the original meeting?
Start with one workflow and a small set of examples. Improve the instructions when a recurring error appears. If review still requires reconstructing the entire task, narrow the task further.
AI becomes useful when it reduces the effort of getting to a sound decision. The decision still needs an owner.