How do product managers use AI?

Product managers use AI mostly on the front half of the job, deciding what to build, not just shipping it. Four uses work well today: clustering a pile of customer calls and support tickets into the themes that matter, drafting evidence-based product requirement docs that cite the customer signal behind each request, reading product analytics to find where users drop off and why, and writing precise specs that AI coding agents can execute. In each case AI removes the grunt work of synthesis and first drafts, while the PM keeps the judgment about which problem is actually worth solving.

Will AI replace product managers?

No, but it changes the job. AI is good at producing the artifacts of product management (the docs, the summaries, the analytics digs) and weak at the core of it, which is deciding which problem is worth solving from noisy, conflicting user signal. Andrej Karpathy argues taste and judgment stay important precisely as agents handle more of the technical details. The likely outcome is fewer hours spent on synthesis and documentation, and more weight on the part that was always the real work: knowing your users well enough to pick the right thing to build.

What is the "Cursor for product managers"?

It is an idea on Y Combinator's Spring 2026 Request for Startups list: an AI-native system for product discovery. The pitch is a tool where you upload your customer interviews and product usage data, ask what you should build next, and get back an outline of a feature grounded in real feedback with the reasoning shown. Today teams use AI in isolated parts of product development, but no single product supports the full loop from raw user signal to a ranked decision about what to build. That missing loop is the opportunity YC is pointing at.

What skills do product managers need in the AI era?

The two that compound are spec-writing and judgment. As AI agents take the first pass at building, the way you define intent has to get sharper, because an agent has none of the shared context a human engineer assumes and does exactly what the spec says. The PMs who thrive can write an unambiguous spec with testable acceptance criteria, which lets them drive a fleet of agents. The other skill is the one AI cannot do for you: deciding which problems are worth solving, which is rooted in talking to users and developing real taste for the product.

AI for product managers: a real playbook

In its Spring 2026 Request for Startups, Y Combinator put a deceptively simple idea on the list: a "Cursor for product managers." The pitch opens with a line every founder should sit with. Writing code is only part of building a product people want, and the most important part is figuring out what to build in the first place.

That is the real question behind "AI for product managers." The coding agents get the headlines, but the harder job, deciding what is worth building, is still mostly done by hand. Here is how product managers, and founders who do their own PM work, are actually using AI today, where the tools fall short, and the one skill that decides who wins.

What product management actually is

Strip away the artifacts and product management is a loop: talk to users, understand the market, synthesize the feedback, and decide which problems are worth solving. The visible output, the product requirements doc, the Figma mock, the Jira ticket, exists to communicate that intent to engineers. The documents are not the work. The judgment is.

This matters because AI is very good at producing the documents and much weaker at the judgment. A coding agent can turn a clear spec into a working feature. It cannot tell you, from a noisy pile of sales calls and support tickets, which feature actually matters. That gap is the whole opportunity, and the whole risk.

The gap: AI fills pieces, not the loop

Right now most teams use AI in isolated parts of product development. An agent here summarizes a call. A model there drafts a ticket. But there is no single system that supports the full loop of product discovery, from raw user signal to a ranked decision about what to build next. That is exactly the gap YC is pointing at: an AI-native system focused on what to build, not just how to build it.

Picture the tool YC describes. You upload your customer interviews and your product usage data, ask what you should build next, and get back an outline of a feature grounded in actual customer feedback, with the reasoning shown. None of the pieces are science fiction. The reason it does not exist yet as one polished product is that the loop is messy and the judgment is hard to automate. But the pieces are already usable on their own, and that is where a sharp PM gets an edge today.

How PMs actually use AI today

You do not need the all-in-one tool to capture most of the value. Four jobs are working right now.

Synthesizing customer conversations. Enterprise AI assistants like Glean, which indexes a company's internal knowledge, and Cresta, which works on contact-center conversations, already summarize large volumes of customer interactions to surface trends. The same move works at startup scale. Drop a month of call transcripts and support tickets into a model and ask it to cluster the complaints. You still decide what matters, but you read the signal in an hour instead of a week.

Drafting evidence-based PRDs. In a YC Root Access talk on giving agents enough context, Skyvern's co-founder described pointing internal agents at the company's call recordings, Slack, and customer interactions to draft product docs that cite the evidence behind each request. The PRD stops being a blank page and becomes a first draft you edit, grounded in what customers actually said rather than what you remember them saying.

Reading product analytics. AI can analyze product analytics to find friction points in a funnel and even propose A/B tests to fix them. Instead of staring at a dashboard, you ask where users drop off and why, and you get a hypothesis to check. The judgment about which drop-off is worth fixing stays with you.

Writing the spec for the agent. This is the newest job and the most important, so it gets its own section.

Writing specs is the new core skill

As AI agents increasingly take the first pass at implementation, the way you define and communicate what to build has to evolve. The PRD written for a human engineer assumed a lot of shared context and judgment. An agent has neither by default. It does exactly what the spec says, no more and no less.

The teams furthest ahead treat this as a discipline. In one YC talk on building a company with AI from the ground up, the model was a "software factory": a human writes a precise spec and a set of tests that define success, and agents generate and revise the implementation until the tests pass. The bottleneck moves from typing code to specifying intent clearly enough that a machine cannot misread it. That is a product management skill, not an engineering one. If you can write an unambiguous spec with crisp acceptance criteria, you can drive a fleet of agents. This is the same shift I covered in building software with AI agents: the spec and the review are where the advantage sits now.

Why taste and judgment still decide

It is tempting to assume the AI will eventually do the deciding too. The people closest to the frontier do not think so. Andrej Karpathy, in his conversation with Sequoia on agentic engineering, argues that taste and judgment stay important precisely as agents handle more of the technical details. The wisdom to choose what to build, and how to execute, is still the critical skill, even with AI doing the typing.

That is good news for product managers and for founders doing PM work. AI removes the grunt work, the synthesis, the first-draft doc, the analytics dig, and leaves the part that was always the actual job: knowing your users well enough to pick the right problem. It is the same edge behind the age of the solo founder, where experience and taste, not headcount, become the differentiator.

What to do this week

Take your messiest pile of user signal (call transcripts, support tickets, sales notes) and have a model cluster it into the top five themes. Read the result critically; do not ship its conclusions, use them as a starting point.
Rewrite your next PRD as a spec an agent could execute: explicit acceptance criteria, edge cases named, success defined as a testable condition.
Run one analytics question through AI ("where do new users drop off in week one, and what are three likely causes") and verify the answer against the raw data before you act on it.
Write down which product decisions you would never hand to AI. That list is your real job, and it is where your judgment compounds.

Want the full system for running your startup on AI without losing the judgment that makes it work? That is what we teach in AI Operating System for Startups.

Sources

Cursor for Product Managers, from Y Combinator's Request for Startups: the source this article distills (the "figure out what to build" framing and the product-discovery tool concept).
How to Give AI Agents Enough Context to Be Useful (YC Root Access): Skyvern's co-founder on drafting evidence-based PRDs from internal call recordings and Slack.
The Enterprise Brain for AI Agents with Glean and Cresta (Greylock): agents summarizing large volumes of customer interactions for product insight.
How to Build a Self-Improving Company with AI (Y Combinator): using AI on product analytics to find funnel friction and automate A/B tests.
How To Build A Company With AI From The Ground Up (Y Combinator): the "software factory" pattern, where humans write specs and tests and agents build until they pass.
Andrej Karpathy: From Vibe Coding to Agentic Engineering (Sequoia Capital): why taste and judgment stay essential as agents take over the details.
The Most AI-Pilled CEO We Know (Y Combinator): the wisdom to choose what to build remains a critical founder skill.