Section 1
Discovery is where the gains sit
Before anything is built there is a pile of unread evidence: support tickets, sales call recordings, churn interviews, feature requests, competitor changelogs. Nobody reads all of it, so decisions get made from whatever a senior person remembers. This is the strongest use of AI in product work. Code the pile consistently, count the themes, and bring numbers to the prioritisation meeting instead of anecdotes. It is unglamorous and it changes roadmaps. The second use is the pre-mortem. Have a model argue the case against a proposed feature, listing the ways it could fail to matter, then answer those arguments with evidence. Cheap, fast, and it catches the features that survive only because nobody wanted to challenge the person who suggested them. The forecasting parallel is set out in [Leveraging AI Automation for Predictive Sales Analytics](/blog/leveraging-ai-automation-for-predictive-sales-analytics).
Section 2
Specifications: fast draft, slow review
Drafting a specification with AI is quick, and the output reads well, which is exactly the problem. A specification is a set of decisions, and the model has no basis for making them. It will fill the gaps with reasonable-sounding defaults that nobody chose. Use it to produce structure and to enumerate cases: error states, empty states, permission combinations, what happens on a slow connection. It is genuinely good at the list of things you forgot. Then have a human make every decision in the document explicitly. A useful test before handing anything to engineering: can you point at each requirement and name who decided it and why.
Section 3
Where it helps during the build
Inside engineering the reliable gains are in the surrounding work rather than the core logic. Test generation, migration scripts, documentation, changelogs, reviewing a diff for the obvious mistake, and summarising a long incident thread. The constraint is reviewability. Generated code that nobody understands is a liability that arrives fast, and it tends to surface months later when the person who accepted it has moved on. Quality assurance is a better target than most teams realise. Generating test cases from a specification, including the awkward ones a tired human skips, catches real defects and does not require anyone to trust generated code in production.
Section 4
Launch is a workflow problem, not a creative one
Launch consistently slips on coordination rather than on writing. The release notes, the help article, the sales one-pager, the in-app message, the internal briefing, the pricing page update. Each is small, each waits on the others, and each is a chance for the message to drift. This is automation-shaped work. One source document that a human writes, then generated variants for each channel, all reviewed by the same owner. The gain is consistency as much as speed. What stays human: the pricing decision, the promise made to customers, and any claim about results. Those three create obligations.
Section 5
The failure mode: automating away the customer
The specific risk in product development is not a bad model output. It is that a team with fast synthesis stops talking to people. Summarised feedback loses the thing that makes customer conversations valuable: the hesitation, the workaround someone built in a spreadsheet, the sentence they cannot finish. You cannot ask a summary a follow-up question. Set a floor and protect it. Some number of live customer conversations per cycle, attended by whoever is deciding, regardless of how good the analysis pipeline is. Use the automation to arrive at those conversations better prepared, not to replace them. Keeping the customer's own account intact is part of what [Storytelling in the Age of AI and Automation](/blog/storytelling-in-the-age-of-ai-and-automation) argues for.
Section 6
What to measure
Features shipped is the metric that lets a product team look productive while the business stalls. Measure cycle time from decision to release, the share of shipped features that reached their stated adoption target, defect escape rate, and the time between a customer raising a theme and a change addressing it. Add one honest counter: the number of features shipped in the last year that nobody uses. It should be non-zero, and it should be falling. If AI-assisted work is helping, cycle time falls while defect escape stays flat or improves. If cycle time falls and defects rise, the automation moved work from before the release to after it.