The Label Isn't the Expensive Part

My car makes a noise on cold mornings that the dealership calls normal. I still flinch every time I hear it, and I have stopped asking them to check it because the answer never changes.

That's the argument I watch happen at work more than almost any other one: support says it's a bug, product says it's working as intended, and the ticket sits there while two teams who are both right build a case file. Support is right because the customer is confused and annoyed. Product is right because the thing did exactly what the spec said it would do. Both of those can be true at the same time, and I don't think I fully understood for a long time that the argument itself was the cost, not just the time it took to resolve.

I've been in that room more times than I can count, usually pushing for a decision faster than the room wants to make one. My instinct is almost always to side with the customer's experience over the internal definition, and I know that instinct has cost us at least once — I pushed to change something an engineer had built correctly, on spec, because a customer was upset, and the fix introduced a worse problem two weeks later. I still think siding with the customer's read is the right default. I don't think I handled that particular case well, and I'm not fully sure where the line is between "the customer's confused and we should explain it" and "the customer's confused and that confusion is the actual bug."

I'd been running some version of this for years before I ever heard Deming's line about quality being defined by the customer, not the manufacturer. It matched something I'd already lived — on the flight line, on the spec, "meets tolerance" and "the pilot trusts it" were sometimes different questions. I didn't need the name for the idea to be true. I needed it to stop feeling like I was arguing against my own engineers every time I said it.

What I keep coming back to is that the label — bug or not-bug — is almost never the expensive decision. The expensive decision is how long we spend proving we're right before we fix what the customer is looking at.

If you build the thing — when has "working as intended" actually been the wrong answer to give a customer, even though it was true?