A product manager’s path through AI literacy

When “Optional” becomes “Obligatory”

There’s a version of AI adoption that looks like this: a product manager adds a few AI-powered features to the backlog, watches the team ship them, and calls it done. The product manager’s (PM) job stays roughly the same: prioritize, clarify scope, ship,  just with fancier outputs.

I lived that version for a while. And then something shifted.

It wasn’t a single moment, but somewhere in the past two to three years of watching AI show up in more and more places, first in how I was doing my own analysis and prioritization work, then increasingly as features we were actually building, it stopped feeling like a capability I could choose to understand and started feeling like something I was responsible for understanding. That’s a different kind of pressure entirely. 

And it’s what pushed me toward two years of formal AI training that changed how I think about products more broadly.

What changes when AI is in product management?

I’ve been in product management for over 20 years, after a stint as an engineer. I’ve seen a lot of capability shifts. But AI in production is genuinely different, and not in ways that are always obvious from the outside.

Earlier in my career, when I worked with Machine Learning (ML) systems around 2010, the model’s output fed into a human decision somewhere downstream.

The risk was contained. Failures were more predictable. Now, with LLMs and generative AI embedded directly in product workflows, the system behavior is the product experience.

When something goes wrong, the blast radius can be immediate and hard to trace.

On my current team, as we moved from exploratory conversations about AI, “what could we use this for?”, to actually building features with AI components, I noticed decisions carrying more weight.

The outcomes became less predictable. The risks weren’t always visible up front. And clients still had significant misconceptions about what AI could and couldn’t do, which meant a PM couldn’t just build; they had to explain, educate, and reason through tradeoffs in real time.

That’s when I decided I needed more than curiosity. I needed a real foundation.

How I built that foundation (and why the order mattered)

I deliberately structured my learning in four stages, and I want to be honest that skipping ahead would have cost me something. Each stage answered a different question, and I couldn’t quite see the shape of the next question until I’d finished the one I was on.

Stage one: AI for product managers 101

The biggest value wasn’t the technical depth, though that was there. It was developing a mental model for how AI products work end-to-end, from model training basics and evaluation metrics all the way through to how system behavior translates into product outcomes. What it confirmed for me was something I’d already suspected: you don’t need to build models, but you absolutely need to know how to reason about them.

Stage two: AI product leadership

The focus now shifted from understanding AI products to understanding AI systems inside organizations. It went deep on Machine Learning Operations (MLOps), system anatomy, and strategy, and what it made unmistakably clear is that how an AI system behaves in production is shaped at least as much by organizational decisions as by the model itself. Those two courses together gave me a qualitatively different ability to look at AI systems and ask harder questions.

Stage three: AI prototyping

This one surprised me the most. I’ve done a lot of prototyping with traditional tools over the years, but this was different. Prototyping with vibe coding became a thinking tool, not a building tool. And what it showed me, fast and repeatedly, was how fragile AI systems actually are. Users don’t prompt the way you expect. Happy path testing hides failure modes. Behavior that looks fine in a controlled scenario breaks with real inputs. What assumptions do you make about data drift? Probably too optimistic. There’s something about actually watching a prototype fail at the edges that teaches you things no whitepaper can.

Stage four: Agentic AI product management

I saved this for last on purpose. The course was the most intense thing I’ve done in a while,  a full boot camp running from concept to MVP, with a Shark Tank-style pitch to industry leaders from Meta, Google, Amazon, and MIT. Intimidating, yes, but genuinely useful. And what became clear through all of it is that agentic AI isn’t about smarter features. It’s about designing systems with autonomy across an entire workflow,  and that means the PM becomes the owner of how that system behaves when the human steps out of the loop.

Three questions I ask about every agentic system

The formal training gave me a lot, but the most durable thing it gave me was sharper judgment, not a richer toolbox. And that judgment now runs through three questions I apply any time I’m evaluating whether and how to automate something with an agentic system:

Question 1: Is it reversible?

If this goes wrong, can we undo the harm? Some mistakes are recoverable. Some aren’t. The nature of the mistake matters as much as the probability.

Question 2: Can we see what the system decided and why?

This is the one I feel most strongly about. If we can’t articulate what the system is doing and why users are getting the outputs they’re getting, we don’t actually have a product; we have a black box with a UI.

Question 3: What’s the blast radius like?

If something fails, how many people are affected, and how fast does it spread? The answer to this question should shape how much human oversight lives in the loop, and where.

These aren’t new questions. Any experienced PM would recognize them as classic product thinking. But in an agentic context, they aren’t just risk management questions; they’re ethical ones.

Not everything deserves to be automated. Deciding what shouldn’t be is now as important as deciding what can be.

Victoria Ragulina

Product Leader, Flexion

What does this mean for PM fundamentals?

One thing I want to be direct about: the core PM disciplines didn’t become less important because of AI. They became more exposed. 

In traditional software, you can sometimes muddle through with fuzzy problem framing or vague assumptions. The team will figure it out, QA will catch most of it, and the feedback loop is tight enough. With AI products, ambiguity is expensive in a different way.

• Unclear intent doesn’t just slow your team down; it can propagate into system behavior in ways that are genuinely hard to trace or correct.
• Clear problem framing, explicit assumptions, crisp intent, and outcome-based metrics are structural in AI product work. And on top of that foundation, AI PMs need enough technical literacy to collaborate meaningfully with engineers, not to build models, but to understand failure modes, recognize tradeoffs, and ask the questions that matter. 
• Accuracy versus explainability. Automation versus oversight. Speed versus cost. These tradeoffs don’t resolve themselves, and you can’t navigate them from a purely functional perspective.
• The iterative mindset matters here, too, and not just during development. Because AI systems in production behave differently as data drifts and user behavior evolves in unexpected directions, the monitoring and experimentation never really stop. 
• You don’t ship and move on. You ship and watch, adjust, and keep watching. Flexion’s emphasis on feedback loops as a continuous mechanism maps directly onto this; the loop doesn’t close at launch.

Learning was never about keeping up

I want to close with this, because I’ve heard the “keep up with AI” framing a lot and it’s not quite right, at least not for how I experienced it. The formal training didn’t primarily teach me tools, though working with those tools was genuinely fun. What it actually did was sharpen my judgment. And judgment, in AI product work, is what separates a PM who can ship AI features from one who can actually be responsible for them.

For anyone considering a similar path, I’d point toward the Maven as a structured starting point. The progression from foundations through agentic systems gave me the ordering I needed. But more than any specific course, the insight I’d leave you with is this: don’t skip the foundations to get to the exciting stuff. The exciting stuff only makes sense because of what’s underneath it. I’m still practicing, still refining my judgment, still watching new tools appear faster than I can fully evaluate them.

The shift from optional to obligatory already happened; the only variable now is how deliberately you build for it. If your team is navigating that shift, Flexion’s work on AI enablement picks up where the learning path leaves off.