What an AI product manager actually does

Ordinary software does what its code says. If a button calculates tax wrongly, somebody finds the line, fixes it, and the bug is gone for every user. An AI feature does not work like that. The same input can produce different outputs, a fix for one case can quietly break another, and no amount of engineering produces a version that is never wrong.

That single difference changes the product manager's job more than any tool or model release. The question is no longer only "what should this do?" It becomes "how often must it be right, what happens when it is wrong, who notices, and what does the user see in that moment?" A product manager who cannot answer those questions is writing requirements for software that does not exist.

The work, in four parts

• Deciding whether AI belongs in the product at all. Many proposed AI features are better served by a rule, a search box or a form, and saying so early saves a quarter.
• Judging feasibility and cost before the build. Which approach, roughly what it costs per user, and what quality is realistic on the organisation's own data.
• Specifying behaviour precisely. The happy path is the easy part; the requirement must also state the confidence at which a human must review, the failure modes the interface must absorb, and what the product does when the model cannot answer.