ML for PMs: Six Problems, Six Algorithms

The ML problems every AI PM should be able to name

I’ve been going deeper into the ML fundamentals lately, and one thing became clear pretty quickly: you don’t need to know how to build these models to work with them well. You need to know which one a given problem calls for, and which decisions are still yours once the model is built.

Here’s the shortcut I’ve started using. Almost every “which algorithm” question collapses into one of six questions about what the product actually needs to decide:

Let me walk through each one, with the examples that made them click for me.

Predict a number → Linear regression

This is the one you’ll run into constantly, because so much of product work is really about predicting a number: an ETA, a price, next month’s demand.

Take a food delivery ETA. The delivery time depends on a handful of things: distance, how long the kitchen takes, traffic, whether it’s raining. Linear regression just says: the outcome is a weighted sum of these inputs.

delivery time = (w1 × distance) + (w2 × prep_time) + (w3 × traffic) + (w4 × rain) + b

The model’s job is to find the weights that make its predictions match reality as closely as possible, using historical data (a classic 80/20 train-test split). Once it’s trained, the weights become a story: if traffic has the highest weight, geography and routing are your bottleneck. If prep time dominates, the fix is in the kitchen, not on the road.

DoorDash runs this kind of prediction across more than 2 billion orders a year, and their engineering team reported a ~20% relative improvement in ETA accuracy after refining their models, because an ETA people can trust is core to whether they come back.

The PM’s job here isn’t building the model, it’s deciding what error is tolerable. Users forgive a five-minute ETA miss. They don’t forgive fifteen. That tolerance number is a product call, not a data science one, and it’s what turns a metric into a ship decision.

Predict yes or no → Logistic regression

Some decisions aren’t a number on a scale, they’re binary. Approve the loan or not. Will this user churn or stay. Is this transaction fraud.

Logistic regression works like linear regression under the hood, but it squashes the output into a probability between 0 and 1. Then someone has to pick the cutoff: above what probability do we actually act? That threshold is where the real product thinking lives, because no classifier is ever 100% right. Every prediction lands in one of four buckets:

Precision is what you protect when a false alarm is expensive, think of a fraud model that’s too trigger-happy and starts declining good customers. Older rule-based fraud systems flagged 70–95% of alerts as false alarms; modern ML models with feedback loops bring that down to roughly 15–30%, which is the difference between wasting a compliance team’s week and actually catching fraud.

Recall is what you protect when a miss is dangerous, a disease screening tool that tells a sick person they’re fine is the failure mode you can’t accept, even at the cost of more false alarms.

This is why the PM sets the threshold, not the model: only the PM knows whether a false positive or a false negative costs the business more.

Explain the decision → Decision trees

Sometimes the output matters less than the reason behind it. If asked “ Why was this post flagged for review?”, a probability score isn’t an answer, a decision tree is.

A tree is basically a flowchart the model builds itself. At each split, it’s choosing the cut that produces the “purest” groups (using something called the Gini score, lower is cleaner). The result is a chain of if-then logic a human can actually trace and defend.

This is the trade-off worth remembering: trees are usually a little less accurate than the more complex models below, but in lending, hiring, or anything regulated, being able to explain the decision is often a harder requirement than squeezing out an extra percentage point of accuracy. That’s a call the PM has to make explicitly, not something to leave to whichever model scored best in a notebook.

Just maximize accuracy → Random forest

One tree is explainable but a bit fragile, it can latch onto quirks in your training data. A random forest fixes this by growing hundreds of trees, each trained on a different random slice of the data, and letting them vote. Individual mistakes cancel out and accuracy climbs.

The cost is that you lose the single clean story. A hundred trees voting isn’t something you can narrate to a VP the way one tree is, so this is the model you reach for once you’ve already decided accuracy matters more than explainability.

The one thing worth watching for as a PM: overfitting. If a tree is allowed to grow deep enough, it can start memorizing your training data instead of learning the actual pattern, splitting on something as oddly specific as an exact address. It’ll look flawless on the data it trained on and then fall apart on real users. So the only accuracy number worth trusting is the one measured on data the model has never seen.

No labels, find the groups → K-means clustering

Everything above assumed you had the “right answer” to train on, labelled supervised data to rely on. Clustering doesn’t. You hand the model raw behavior, nobody tells it what the segments are, and it finds the groups on its own.

K-means does this by picking a number of groups (k), sorting each data point into whichever group’s center it’s closest to, then repeating until the groups settle. This is the algorithm quietly running behind a lot of personalization you experience daily. Netflix groups viewers into taste clusters, and has estimated its recommendation engine is worth over $1 billion a year in retention, with roughly 80% of what people watch starting from a recommendation rather than a search.

Learn from live feedback → Multi-armed bandits

Last one, a normal A/B test splits traffic 50/50 and holds that split for weeks, which means half your users keep seeing the losing version the entire time, even once the data is already leaning hard one way.

A multi-armed bandit shifts traffic toward the winner while it’s still learning, instead of waiting for the test to “finish.” It’s constantly balancing exploring (keep testing to be sure) against exploiting (send more traffic to what’s already winning). Netflix uses exactly this to personalize the artwork for a title, a bandit can learn that a romance fan and a comedy fan should see two different thumbnails for the same movie, and keeps adjusting as more data comes in.

The PM’s job here is picking the reward the bandit chases. Point it at raw clicks and it will happily learn to produce clickbait. Point it at something that reflects real value, a completed order, a 30-day retention, and it optimizes for what actually matters.

The pattern underneath all six

Every one of these algorithms does the same kind of work: find the weights, split the data, group the points, chase the reward. What none of them do is decide what any of it should mean for the business. That’s still the PM’s job, every time:

• The metric: what “good enough” looks like for the user

• The threshold: which mistake you can afford

• The trade: accuracy versus explainability

• The name: turning a cluster number into a real segment and an action

• The reward: the one thing a live system is allowed to optimize for

One more thread I keep coming back to: in every example above, someone had to decide which inputs mattered in the first place, distance, prep time, credit history. For a long time that required domain experts, and it was a real bottleneck. Getting models to discover useful signals on their own, without a human hand-picking every feature, is a big part of what pushed the field toward deep learning. That’s probably its own post.

For now: the algorithm is the easy half. The judgment is still the job.

Shailesh Sharma Technomanagers