Phase 1: AI & ML Literacy for PMs · 40 min · Python
How Machine Learning Models Actually Learn
"The model learned that discount codes correlate with churn" is a statement about weights, not about understanding.
Hiring signal: PMs are not expected to write code or derive gradient descent, but they are expected to hold a real technical conversation with ML engineers without nodding along to words they don't understand. A PM who can correctly classify a use case as supervised, unsupervised, or reinforcement learning, and who can explain why a model fails on an edge case in terms of correlation rather than 'the AI got confused,' earns trust in scoping and roadmap conversations that a PM who treats ML as a black box never does.
What you will learn
- Distinguish supervised, unsupervised, and reinforcement learning conceptually and match each to a realistic product use case
- Explain the difference between training and inference, and why one is expensive/occasional and the other is cheap/repeated
- Explain what 'the model learned X' actually means mechanically, without invoking human-style understanding
- Use the correlation-vs-understanding distinction to explain why a model generalizes well in some cases and fails unpredictably on edge cases
- Choose the right learning paradigm for a given product use case and justify the choice to an ML engineer
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.
Unlock the full lesson
You've read the first 2 sections. The rest of this lesson covers Training vs. Inference, What "The Model Learned X" Really Means, Build It, What to Practice — plus a hands-on lab, quiz, and project artifact.
Create a free account to unlock Phase 0 and Phase 1 of every course — no credit card.
Browse all courses · View pricing · DeVenture Academy