We were making fudge.

If you have ever made it in volume, you learn pretty quickly that it is not perfectly consistent. Some batches set wrong. Some come out with the wrong texture. Sometimes you throw the whole thing away. If you are lucky, you only throw part of it away.

We were talking about standards. About whether you change the process. About whether you try to make it better.

That is when my dad said it, casually, like it was not advice at all.

People want consistency.

Not as a correction. Not as an argument. Just as a statement of how manufacturing works, and how customers behave when they find something they like. Once something works, you keep doing it, because you already have customers who chose this thing. Changing it means you are starting over in ways you do not always see.

At the time, I did not fully buy it. I believed what most people believe early on. Better quality should always win. Improve something and customers will naturally gravitate toward it.

That belief feels obvious when you are standing inside it.

What I did not recognize was the assumption inside the belief.

It assumes that customers are optimizing for the same things you are.

They are not.

Often, customers are optimizing for predictability. Familiarity. The thing they already learned how to use. The thing they already decided to trust. The thing they can fit into their routines without thinking about it.

Years later, that lesson showed up again, this time in a place that surprised me.

I worked at a financial company where a loan loss calculation was wrong for a specific class of loans. Not wildly wrong. But wrong. When we finally understood it, the reaction from the team was immediate. We should fix it.

The engineering manager said no.

At the time, it sounded insane. Why would you knowingly leave something incorrect in production?

His reasoning was uncomfortable but clear. We were wrong, but we were consistently wrong. Every downstream system already knew how to accommodate that behavior. Reports, reconciliations, controls, and workflows were built around it. If we fixed it, we would not just correct a formula. We would break everything that depended on it and then spend months rediscovering all the places that had quietly adapted.

It was not a proud decision. It was not elegant. But it was operationally honest. Knowing exactly how something behaves, even when it is imperfect, is often safer than changing it and hoping nothing else breaks.

I think about this a lot now, especially when building software and user interfaces.

I once consulted on a product where a new product owner wanted to redesign an aging system. And to be fair, it showed its age. The interface was not modern. The experience was not beautiful. But it worked, and more importantly, users knew how it worked.

This was not an application people lived in every day. Some users logged in once a month. Some logged in once every six months. Some logged in once a year to do a specific task and then disappeared again. They did not love the product, but they could get through it. It was familiar.

The redesign aimed to make things better by putting tighter bounds on what users could enter. The theory was that correctness should be enforced up front, instead of letting a back office team review submissions and fix issues later.

On paper, that sounds like an improvement.

In practice, it broke the value proposition.

Those users were not paying for perfect validation. They were paying to not have to think about edge cases. They wanted to enter data and move on. If something needed to be corrected, they expected the system and the people behind it to handle it. That was the service. A white glove posture that the organization had operated on for years.

When the software changed, users got frustrated. Then angry. Internally, the reaction was confusion. Why are they being difficult?

They were not being difficult.

We changed what we were offering them.

That is the part that is easy to miss. People do not always leave because you made something worse. Sometimes they leave because you changed the deal they thought they had with you.

Consistency is not glamorous. It does not make for a dramatic roadmap. It rarely wins internal applause. But it is what people build their lives, habits, and systems around.

Being consistently off can be better than fixing something and breaking everything around it. Not because correctness does not matter, but because predictability compounds. Familiarity compounds. Trust compounds.

I still think about that fudge. About throwing away bad batches, but not reinventing the recipe every week. About how much effort it takes to earn a repeat customer, and how casually that trust can be spent.

Every time someone says, “We should change this,” I pause a little longer now.

Sometimes the right move is to improve.

But sometimes the right move is to keep the promise you are already keeping.