AI Product Management

I am moving from systems analysis and production support toward AI product management and ownership. This page is the working map: what the role actually is, which parts of an operations background carry over, and what I am building to close the gaps.

It is a living page. It will change as I learn.

What an AI product manager actually does

A product manager decides what gets built and why. An AI product manager does that for products where a model sits in the middle, and that changes the job in three ways.

• The output is probabilistic. The same input can give different answers, so "does it work?" becomes "how often, for whom, and what happens when it doesn't?"
• Quality has to be measured on purpose. Evaluations, test sets and human review replace the pass/fail checks of ordinary software.
• Cost and speed are product decisions. Model choice, context size and latency change both the experience and the unit economics.

What an operations background already gives you

People who have run production systems tend to underestimate what they know.

• Living with incidents teaches you which failures matter to real users and which are noise.
• Support work puts you close to what users actually complain about, which is the best source of product problems.
• Managed services teach SLAs, escalation paths and the cost of downtime.
• Systems analysis is requirements work: turning a vague ask into something a team can build.

The gaps to close

• Writing a clear product requirement for a system whose behaviour is not fully predictable.
• Designing evaluations: what to measure, how to build a test set, how to read the results.
• Understanding the moving parts well enough to hold a conversation with engineers: prompting, retrieval, fine-tuning, guardrails.
• Pricing, unit economics and the build-or-buy call.
• A portfolio that shows decisions, not only tools.

How I am working on it

1. Build small, real AI features and write down the product decisions behind each one: the problem, the user, the evaluation and what I would change.
2. Keep the evaluation set and the results visible, including failures.
3. Read the product write-ups of teams shipping AI at scale and note which decisions I would have made differently.
4. Publish what I learn here, in plain language.

If you are on the same path

Start with a problem you already understand deeply, from your own work. Build something small for it, measure whether it helps, and write about what you decided and why. That one page is worth more in an interview than a list of courses.

← Back to Guidance