Becoming an AI product manager

Conventional software is deterministic: given the same input it does the same thing, and a bug is a defect to be fixed. An AI feature is probabilistic — it is right most of the time and wrong some of the time, and the wrong cases are often not fixable in the usual sense.

That single property changes requirements, testing, support, pricing and the conversation with customers. A product manager who cannot internalise it will keep writing specifications that cannot be met and promising behaviour that cannot be guaranteed.

It also changes what shipping means. There is no version where the feature is finished and correct; there is a version where the error rate is acceptable for a defined workflow, which is a judgement rather than a milestone.

The core new skill is deciding how good is good enough, and saying so in a way engineering can build against. Not "the summary should be accurate", but what the system does when it is unsure, what the user sees, what it costs when it is wrong, and what rate of error the workflow tolerates.

This requires thinking about the failure path as a designed experience rather than an exception. In good AI products the recovery path — the correction, the fallback, the escalation — receives as much design attention as the success path, because users will meet it regularly.

The question that unlocks most of these conversations is who bears the cost of an error. A wrong suggestion the user discards costs seconds; a wrong action taken on their behalf costs trust; a wrong answer they act on without checking can cost far more. Those three cases justify completely different designs.

• What the user sees when confidence is low
• How a wrong result gets corrected, and by whom
• What the error costs — an annoyance, or a bad decision
• Whether the feature degrades gracefully or fails outright
• What error rate the surrounding workflow genuinely tolerates

You do not need to build these systems. You need enough understanding to know which requests are reasonable, to recognise when an estimate is optimistic, and to follow a discussion about why quality is not improving.

The highest-value specific knowledge is cost structure. Because cost scales with usage rather than being a fixed build expense, a product decision about how much context to include is directly a margin decision. AI product managers who cannot reason about cost per request make commitments the business regrets.

The second most valuable is knowing which problems are retrieval problems. A great deal of what looks like poor model quality is the system not being shown the right information, and a PM who can ask that question saves weeks of misdirected work.

• Why the same prompt can give different answers
• What retrieval does and why it fails plausibly rather than obviously
• How evaluation works and what it can and cannot prove
• Cost per request, and which product choices move it
• Latency budgets and what they rule out

In conventional software, marginal cost per user rounds to nothing and pricing is a positioning exercise. With AI features the marginal cost is real, variable and driven by usage patterns you do not control, which puts unit economics back on the product manager’s desk.

The classic mistake is unlimited usage on a flat subscription. A small number of heavy users can consume more than the entire cohort pays, and the discovery usually happens a month after launch when the invoice arrives.

Design the limits as part of the product rather than bolting them on. Fair-use caps, tiering by volume, cheaper models for routine requests and caching of repeated work are all product decisions with revenue consequences, and they are far easier to introduce before customers have anchored on unlimited.

Deciding what "good" means is a product decision, not an engineering one. Engineering can measure anything; choosing what to measure requires knowing what users need, and that is your job.

Product managers who co-own the evaluation set become far more effective, because every quality debate then has a shared reference. Without it, arguments about whether the feature is ready are just competing anecdotes, and the loudest person wins.

It is also the most practical way to build technical credibility with an engineering team. Turning up with thirty real cases and the answers you would accept is a contribution nobody else is making, and it changes how your other opinions are received.

The reliable route is lateral rather than external. Companies overwhelmingly prefer to move an existing product manager onto AI work than to hire an unproven one, because domain and organisational knowledge are harder to acquire than AI literacy.

If you are already a PM, volunteer for the AI feature nobody wants to own. If you are not, become a PM first by the ordinary routes. Trying to enter product management and AI simultaneously is a much harder path than doing them in sequence.

Domain experts are the exception worth noting. In regulated or specialised fields, someone who understands the work deeply is frequently moved into product for AI features precisely because judging whether output is correct requires expertise the team lacks.

• Already a PM — claim the AI feature in your existing product
• Engineer — move via a technically demanding PM role first
• Domain expert — lead with the domain, add AI literacy
• Neither — become a PM conventionally before specialising

Expect to be asked how you would handle a feature that is right eighty-five per cent of the time. Weak answers try to raise the number. Strong answers ask what the fifteen per cent costs, design the recovery path, and identify whether the workflow tolerates that rate at all.

You will also be asked about a launch decision under uncertainty. Interviewers want to hear that you would define acceptable failure in advance and measure against it — not that you would wait until quality is perfect, which never happens.

Expect at least one question about cost. Being able to say that you would instrument cost per request before launch, route cheap requests to a smaller model, and cap the heaviest usage tier marks you out immediately from candidates who treat AI features as free.