I Thought “The Model” Was Magic. So I Opened Google Colab .
For months, every AI conversation sounded the same.
“You don’t need to build models. You just need to understand them.”
That sounded reasonable.
Except...
What does “understand a model” actually mean?
I knew the vocabulary.
Regression.
Coefficients.
R².
Confidence intervals.
I could nod along in meetings.
But if someone asked me to explain why a model made a prediction, I’d have nothing intelligent to say.
So instead of reading another blog post, I opened Google Colab and decided to build the simplest model I could think of.
No LLMs.
No neural networks.
Just one question.
Can delivery time be predicted using only distance?
The Simplest Model Possible
I found a delivery dataset with around 220 orders.
Each row looked something like this.
One input.
One output.
One straight line.
Honestly, I expected this to be boring.
Instead, it completely changed how I think about AI.
The First Surprise
The model estimated that every additional kilometer added roughly 3.25 minutes to delivery time.
That wasn’t surprising.
What surprised me was what came next.
The notebook didn’t say:
Every kilometer adds exactly 3.25 minutes.
It said something much closer to:
Based on the data, it’s probably somewhere around 2.9–3.6 minutes.
That tiny detail hit me.
I’d been treating model outputs like answers.
The model treated them like estimates.
For the first time, I understood why statisticians obsess over confidence intervals.
The prediction wasn’t the interesting part.
The uncertainty was.
Then I Made a Mistake.
I looked at the model score.
R² = 0.55
My first thought?
“Well...that’s not very good.”
I genuinely wondered whether I’d done something wrong.
Then I stopped looking at the number as a grade.
Instead, I asked a different question.
If distance explains only 55% of delivery time….what explains the other 45%?
That single question changed the exercise.
I wasn’t trying to improve a model anymore.
I was trying to understand the business.
The Missing Variables
So I added three more features.
Restaurant preparation time
Traffic
Rain
The model suddenly explained roughly 81% of delivery time.
Prediction error dropped to around 3.4 minutes.
Better model.
But the interesting part wasn’t the accuracy.
It was what the coefficients revealed.
The Insight I Didn’t Expect
Rain looked enormous.
Whenever it rained, delivery times increased by almost five minutes.
My immediate reaction was obvious.
Rain is the biggest problem.
Except...
It hardly rains.
Distance only added a few minutes per kilometer.
But every single delivery has distance.
Rain had the biggest effect.
Distance had the biggest business impact.
Those are completely different things.
And suddenly I realized something.
Product teams make this mistake all the time.
We chase dramatic problems instead of important ones.
A feature can have a massive impact on a tiny percentage of users.
Another can have a modest impact on every user.
The first creates headlines.
The second creates business value.
That’s When This Stopped Feeling Like Statistics
None of the interesting questions were mathematical anymore.
They were product questions.
Is being wrong by 3.4 minutes actually acceptable?
Which variable is worth collecting?
Which prediction errors matter to users?
Is improving accuracy worth the engineering effort?
The model could calculate.
It couldn’t prioritize.
That’s still our job.
Three Lessons I’ll Carry Into Every AI Product
1. Models don’t give answers. They make arguments.
Every prediction comes with assumptions and uncertainty.
Ignoring that uncertainty is how bad product decisions happen.
2. A weak model is often a product discovery tool.
If your model performs poorly, it doesn’t always mean the algorithm is bad.
Sometimes it means you’re measuring the wrong things.
3. The biggest coefficient isn’t always the biggest opportunity.
Impact isn’t just about magnitude.
It’s about frequency.
That’s true in machine learning.
And it’s true in product management.
Why I’m Glad I Started With Linear Regression
I didn’t become a machine learning engineer that afternoon.
That was never the goal.
What changed was something much more valuable.
Now, when someone demos an AI system, I don’t immediately ask:
“How accurate is it?”
I ask:
What assumptions is it making?
What data is missing?
Where is the uncertainty?
Which variables actually drive the business?
What happens when the prediction is wrong?
Ironically, the oldest machine learning model taught me the newest lesson.
AI isn’t just about making better predictions.
It’s about learning to ask better questions.
And I think that’s a much more useful skill for a Product Manager.
I’m still early in my PM journey.
The more I learn about AI, the less I think it’s about models.
The more I think it’s about asking better questions.
Because users don’t care whether your product runs on Linear Regression, XGBoost, or the latest LLM. They care whether it solves their problem. And I think that’s what makes AI Product Management so exciting.
It’s not about building the smartest AI.
It’s about building the smartest product around it.
