How ML Actually Works

Core ML concepts in plain language for better team conversations.

ML is pattern recognition at scale. You feed a system examples, it finds regularities in those examples, and it uses those regularities to make predictions on new data it hasn't seen before.

Three terms come up in almost every ML conversation. Training is the process of showing the model labelled examples until it learns the pattern. A model is the output of that process - a compressed representation of what the system learned. Inference is what happens at product runtime: the model receives new input and produces a prediction.

Most ML is supervised: labels tell the model what the right answer looks like. Unsupervised learning finds structure in unlabelled data - useful for clustering users or spotting anomalies. Reinforcement learning trains through feedback on actions, common in recommendation and robotics contexts.

Quiz

What happens during ML inference?

Quiz

Which learning type requires labelled examples to find the right answer?

02

Data Is the Product

Why training data quality shapes every product outcome downstream.

Your model will reproduce whatever patterns live in your training data - including the bad ones. Bias, gaps, and noise in the data become bias, gaps, and noise in the product.

As a Product Manager, the data pipeline is your product's foundation. The four data properties below determine how much you can trust your model's outputs.

Data property	What it means	PM risk if ignored
Volume	Enough examples to learn from	Model overfits; fails on edge cases
Coverage	Examples span the real-world distribution	Model works in testing, breaks in production
Label quality	Labels are accurate and consistent	Model learns the wrong signal
Freshness	Data reflects current user behaviour	Model drifts as the world changes

Data bias is the subtlest risk. If your training set overrepresents one user group, the model will underserve others - and it will do so confidently. Ask your team who is and isn't represented in the training data before any model ships.

Quiz

A model performs well in testing but fails frequently in production. Which data property is most likely the cause?

03

Multimodal Systems Explained

How ML systems combine different data types to solve harder problems.

A single-input model sees one type of signal - text, or image, or audio. A multimodal system fuses several of those signals together, which lets it solve problems no single-input model can.

Recent research on complex materials illustrates this well. A system analysing carbon nanotube films combined microscopy images, spectroscopy readings, surface area measurements, and electrical resistance data into one model. Each data type captured something the others missed. The fused model outperformed any single-input approach - and it could explain why it made each prediction, which matters as much as accuracy in product contexts.

Multimodal systems route different input types through a shared fusion layer before making a prediction.

For product teams, the practical implication is this: if your problem involves more than one data type - a user's text query plus their click history, or an image plus a price - a multimodal approach is likely worth exploring with your engineers.

Quiz

What is the main advantage of a multimodal ML system over a single-input model?

04

What ML Can and Cannot Do

Realistic ML capabilities mapped against common PM assumptions.

ML is good at finding patterns in data you already have. It is not good at reasoning from first principles, handling situations outside its training distribution, or making reliable predictions when labelled data is scarce.

ML can do this reliably	ML struggles here
Classify or rank items at scale	Reason about genuinely novel situations
Find non-obvious correlations in large datasets	Explain causality, not just correlation
Personalise based on historical behaviour	Handle users with no history (cold start)
Automate repetitive prediction tasks	Perform consistently when training data is sparse or biased
Combine multiple data types for richer predictions	Generalise far outside the training distribution

The most common PM mistake is scoping a feature that requires the model to generalise far outside what it was trained on. The model will still produce a confident-looking answer - it just won't be a reliable one.

Quiz

A PM wants to use an ML model to predict behaviour for brand-new users with no activity history. Which limitation applies?

05

Trade-offs and Decision Frameworks

Concrete frameworks for evaluating latency, accuracy, cost, and explainability.

Every ML scoping decision involves trade-offs. The four that come up most often are latency, accuracy, cost, and explainability - and they pull against each other.

Trade-off axis	When to prioritise it	What you give up
Latency	Real-time user-facing features	Model complexity and often accuracy
Accuracy	High-stakes or trust-critical decisions	Speed and infrastructure cost
Cost	High-volume, low-margin features	Model size and sometimes accuracy
Explainability	Regulated contexts or user-trust features	Predictive power of nonlinear models

Use this decision flow when your team presents a model choice or requests a scope change.

A starting decision flow for scoping an ML feature. Adapt it to your product's specific constraints.

Nonlinear models like gradient boosting tend to outperform simpler approaches on complex prediction tasks - research on multimodal material characterisation found exactly this pattern. But they are harder to explain. When your context demands explainability (regulatory review, user-facing reasoning, or internal audit), a simpler model with interpretable feature importance is often the right call even if its raw accuracy is lower.

Quiz

A PM is scoping a real-time product recommendation feature. Which trade-off axis should they prioritise first?

06

Questions to Ask Your Team

A practical question bank for reviews, launches, and vendor evaluations.

You don't need to understand the model internals to ask the questions that matter. You need to know what to probe - and when.

Before you build or buy

What data are we training on, and who is missing from it?
What does the model do when it encounters input it wasn't trained on?
How will we know when the model has drifted and needs retraining?

At sprint review or model launch

What metric are we optimising for, and does it match the user outcome we care about?
What are the failure modes, and how does the product handle them gracefully?
Can we explain to a user or regulator why the model made this decision?

When evaluating a vendor

What training data was used, and can we audit it?
How is accuracy measured, and on whose data?
What happens to our data once it enters the vendor's system?

Quiz

Which question is most important to ask before launching an ML feature to users?

07

Apply It: Quick Scenarios

Realistic PM scenarios to practise the judgment you've built.

Reading about ML is one thing. Applying it under pressure is another. Work through these four scenarios as if you're the PM in the room - then check your reasoning against the answers.

Scenario 1: The confident wrong answer. Your model flags 92% of fraud cases correctly. Your head of engineering says it's ready to ship. What's the first question you ask?

Scenario 2: The new user problem. A stakeholder asks why the personalisation feature doesn't work well for users in their first week. How do you explain it, and what do you suggest?

Scenario 3: The multimodal pitch. Your team proposes combining a user's search text with their browsing images to improve recommendations. What do you need to know before approving the scope?

Scenario 4: The vendor claim. A vendor says their model achieves 97% accuracy. What three questions do you ask before you trust that number?

You got to the end. That counts.

Sources

Multimodal machine learning for integrating heterogeneous analytical systems. - Muroga S, Nakajima H, Shimizu T, Kobashi K, Hata K. (2026). Multimodal machine learning for integrating heterogeneous analytical systems. Analytical sciences : the international journal of the Japan Society for Analytical Chemistry. https://doi.org/10.1007/s44211-026-00942-w Licensed under CC BY.