The Problem
You're in a roadmap review. The lead ML engineer says, "we retrained the churn model, and it learned that discount codes correlate with churn." Everyone nods. You nod too. Then, on the walk back to your desk, the sentence starts to bother you. Learned how? Does the model now know that discount codes cause churn, the way a person on the retention team knows it after five years of seeing frustrated customers redeem a code and leave anyway? Could you ask the model why, and get a real answer? If a customer used a discount code and stayed, would the model be "confused"?
You don't ask, because asking feels like it would expose that you don't know what "learned" means here — and in an AI PM interview or a real roadmap conversation, that gap shows. It's also exactly the gap that separates a PM who can scope an ML feature from one who can only relay what engineering tells them. So: what actually happened when that model "learned" something?
Nothing symbolic happened. No rule got written down anywhere. A large set of numbers — the model's parameters — shifted, through a repeated mathematical process, until the model's output on past examples got closer to being statistically consistent with what happened afterward. "The model learned that discount codes correlate with churn" means: when this model sees input patterns that resemble a discount-code redemption, its parameters now push its output probability of churn upward, because that pattern was statistically present in the training data. That's it. No causal claim, no concept of "discount code" as a discount code, no theory of why. Just a shifted set of numbers that produces useful-looking outputs on inputs similar to what it was trained on.
That distinction — between statistical association and understanding — is the single most useful mental model a PM can carry into any ML conversation, and it's what the rest of this lesson unpacks.
Three ways a model can learn
Models don't all learn the same way. The learning paradigm — how the model gets feedback about whether it's doing well — is one of the first things an ML engineer will ask you to help pin down, because it determines what data you need before anything else can happen.
Supervised learning trains a model on labeled examples: pairs of input and known correct output. A spam classifier is the canonical case — engineers feed it thousands of emails, each one hand-labeled "spam" or "not spam," and the training process adjusts the model's parameters so its predictions match the labels as often as possible. The defining product question for supervised learning is always: do we have, or can we get, labeled ground truth? If you want to predict which support tickets will lead to a refund request, you need historical tickets that are already labeled with the outcome. No labels, no supervised learning.
Unsupervised learning finds structure in data with no labels at all — nobody tells the model what the "right answer" is, because there isn't one. Customer segmentation is the classic example: you hand the model your customer data and ask it to find groups, and it might surface a cluster of "high-frequency, low-basket-size, mobile-only" shoppers that no one on your team had defined or named in advance. The model isn't predicting a label; it's discovering a shape in the data that a human then has to interpret and name. This is why unsupervised results always need a human sense-check before they drive a roadmap decision — "the model found four segments" is a starting point for a PM conversation, not a finished insight.
Reinforcement learning (RL) learns from a reward signal generated by trial and action, rather than from a fixed labeled dataset. The model (or "agent") takes an action, gets a reward or penalty, and adjusts to get more reward over time. The most product-relevant example for you is RLHF — Reinforcement Learning from Human Feedback — the technique used to align LLM behavior with human preferences. Human raters compare pairs of model responses and say which one they prefer; that preference signal becomes the reward that nudges the model toward answers people rate as more helpful, honest, and harmless. If you've ever wondered why a chat model's "personality" changed between versions without anyone touching its base training data, RLHF on updated preference data is very often the reason.
same underlying mechanism, three different feedback sources
All three paradigms still come down to "adjust parameters to do better next time" — they differ only in where the "better" signal comes from: a labeled answer key (supervised), structure the model finds on its own (unsupervised), or a reward from an action's outcome (reinforcement). When you're scoping a feature, the fastest diagnostic question is: what feedback exists or can be generated? That answer picks the paradigm for you more often than any other factor.
Training vs. inference
Two words get used loosely in every ML conversation, and mixing them up is one of the fastest ways to lose credibility with an engineering partner.
Training is the process of adjusting a model's parameters using data — running examples through the model, checking how wrong its outputs were, and nudging the parameters to be less wrong next time, repeated over the entire dataset, often many times over. Training is expensive: it can take hours to weeks of compute, cost real money in GPU time, and for large models happens relatively rarely — a retrain is a deliberate, planned event, not something that happens on every user interaction.
Inference is using an already-trained model to produce an output on a new input. This is what happens every single time a user sends a message to a chatbot, every time your churn model scores a customer, every time a spam filter checks an incoming email. Inference is cheap and fast relative to training, and it happens constantly — it's the thing your product actually runs in production, on every request.
The parameters are frozen during inference. The model isn't learning anything new when a user talks to it; it's applying the same fixed set of parameters that training left it with. This is why a production LLM doesn't "remember" one user's conversation into the next user's session unless your product explicitly engineers that (via conversation history, RAG, or a separate fine-tuning step) — inference doesn't change the model.
An ML engineer tells you: "our fraud model's false-positive rate has been creeping up in production for the last two weeks, but we haven't retrained it or changed the code." A teammate suggests the model is "learning bad habits from recent transactions." What's the more likely explanation, given that inference doesn't update parameters?
Inference does not update parameters — the model is not learning anything from the transactions it's scoring in production. What's actually happening is almost certainly drift: the real-world distribution of transactions has shifted away from what the model was trained on, so its frozen parameters produce worse predictions on the new pattern. The fix is a retrain (or a model update) on more recent data, not "correcting" a model that was never learning in production in the first place. Confusing drift with "the model learning bad habits" is a common and costly misdiagnosis — it leads teams to look for a code bug when the real issue is stale training data.
What "the model learned X" really means
Go back to the opening scenario. "The model learned that discount codes correlate with churn" means the model's parameters shifted during training such that input patterns resembling a discount-code redemption now push its output toward "will churn." It does not mean the model has a stored rule like IF discount_code THEN churn_risk += 1, and it does not mean the model understands why discount codes and churn co-occur — maybe the causal story is that price-sensitive customers seek out discount codes and were always going to churn regardless of the code, and the code is just a marker of that underlying trait, not a cause of anything. The model has no way to distinguish "correlated" from "causal." It only knows that the pattern was statistically present in the data it saw.
This is exactly why models generalize well on some things and fail unpredictably on edge cases they were never trained on: nothing in the training process forces the model to form a causal or symbolic understanding of the problem, only a statistical correlation across the examples it saw. On inputs that resemble training data, those correlations tend to hold up and the model performs well. On inputs that are structurally different from anything in the training set — a genuinely novel fraud pattern, a customer segment that didn't exist when the model was trained, a phrasing an LLM has never encountered — there is no guarantee the correlation still applies, because the model never had a causal model of the world to fall back on. It has patterns, not reasons. When you hear "the model is hallucinating" or "the model broke on this edge case," this is very often the root cause: the input fell outside the statistical neighborhood the model's parameters were shaped by, and there was no deeper understanding underneath to catch the gap.
For a PM, this is not a philosophical footnote — it's a scoping tool. It tells you to ask "what's the range of inputs this model will actually see in production, and how well does that match the training data?" before you commit to an accuracy number in a PRD, and it tells you why "just add more training examples of edge cases" is usually a more durable fix than "make the model smarter."
A product team is building a resume-screening feature. They want the model to identify "candidates likely to succeed in the role." They have five years of hiring data: resumes, and whether each hire was rated a strong performer after one year. Which learning paradigm fits, and what's the biggest risk in how "learned X" will actually manifest?
This is a supervised learning setup: labeled input-output pairs already exist (resume -> performance rating). But the deeper point is the risk in what "the model learned X" will mean here. The model will learn statistical correlations present in five years of hiring and performance data — and if that historical data reflects biased hiring or rating patterns (e.g., certain schools, employment gaps, or demographic proxies correlating with who got hired and then rated well), the model will learn those correlations as if they were signals of job success, with no mechanism to distinguish a real predictor of performance from a historical artifact of biased hiring. This is exactly the scenario where "the model found a pattern" and "the model found something legally and ethically defensible" are very different claims, and a PM who understands training-as-correlation (not causal understanding) is the one who asks for a fairness audit before launch instead of after a lawsuit.