📈 #90 Stop perfecting algorithms, start owning your data

How taking control of your inputs can save your optimization project

In optimization, trust is binary.

Either users look at the plan and say “yes, this works”, or they dismiss it outright.

And often, the difference between trust and rejection doesn’t lie in the math. It lies in the data.

Three years ago, I learned the hard way I needed to spend more time on improving the data that feed our models. Our team spent months on building a system that consistently failed on giving good plans, and one of the reasons was because data had several issues.

That’s why I believe one of the most underrated responsibilities of an OR Engineer is owning the data that enters the model.

If you don’t own the inputs, you don’t control the outputs.

So today in Feasible we’ll see:

• 🔑 Why you must own the inputs

• 🧭 What data ownership really means

• 🛠️ How to put it into practice

Ready? Let’s dive in… 🪂

🔑 Why you must own the inputs

Optimization is unforgiving.

One wrong flag can invalidate an entire plan. It creates a domino effect difficult to stop.

Unlike Machine Learning, where noisy data just lowers accuracy, optimization collapses when data contradicts business reality.

But in most companies, data ownership is fragmented. Sales owns customer data. Operations owns asset and driver data. IT owns the pipelines.

And the OR team? We get whatever flows downstream.

This creates an “accountability gap” where:

• 🤷 Everyone owns a piece of the data, but nobody owns the fitness of the data for optimization.

• 📉 When the model produces bad solutions, upstream teams point to the solver. The solver points to the data, and the only thing left is distrust.

• 🙅 Users don’t care where the failure started, they only see that the plan doesn’t work.

And when a plan fails, users don’t say: “Ah, must have been the upstream data pipeline”.

They say: “This model doesn’t work”.

Prevent this by focusing on input reliability before algorithm sophistication. Instead of spending weeks perfecting algorithms to squeeze another 0.5% improvement, spend more time making sure the inputs are trustworthy.

It pays for itself: you’ll build faster, more reliable models that meet business constraints and win user trust.

The math usually favors ownership.

🧭 What data ownership really means

Owning the inputs doesn’t mean becoming a data engineer.

It means taking accountability for what the solver consumes.

And it can consume input in different stages, all of them breaking trust in its solutions.

I’ve seen several of them in the past few years, so let’s take a look at the most common ones with examples from logistics: