If You Want to Make Your Product Better, Don’t Attack Your Testers
I’m a programmer, so I tend to think about product problems in terms of bugs and testing.
In the past, software companies had dedicated QA teams. They paid people to test their products and break things, looking for problems before users ran into them. Other industries have similar roles.
When someone does that work for free and finds a bug, I’d expect the company to thank them. Attacking them makes no sense to me.
I’m talking about the MAEXTRO V800 brake failure controversy. The car was launched just a few days ago, and a defect has already been confirmed. The people who exposed it deserve credit for finding it before a real accident occurred.
Software and cars are very different products. A software bug can be annoying, cause data loss, or bring a business to a halt. Faulty brakes can put people’s lives at risk, which makes finding the problem early all the more important. Testing is supposed to catch problems before they cause harm.
Building a car takes years of work by engineers and suppliers, with countless components and systems that have to work together. Manufacturers are responsible for testing it extensively before it goes on sale.
Problems still make it into production after all that work. The history of automotive recalls makes that clear: even major manufacturers with decades of experience have had to recall defective vehicles. No amount of time or money guarantees that you’ll catch every problem before a complicated product reaches the market.
That doesn’t excuse defects. It gives companies a reason to keep testing and to fix problems when someone finds them.
A company can’t test every possible situation on its own. Independent testers may try something the manufacturer didn’t think of or catch a problem that slipped through internal testing. When they find a real defect, they’re doing the manufacturer a favor.
Companies have every right to challenge flawed tests and correct inaccurate claims. They should explain what’s wrong with the test, though, and keep the argument focused on the evidence. Attacking the people who conducted it won’t resolve a confirmed defect.
I find it hard to trust a company that won’t admit a mistake. People know products can fail. They want to know whether the company will take responsibility and fix the problem when that happens, or spend its energy protecting its reputation.
With a car, that trust includes the safety of the buyer and their family whenever they travel in it. It takes years to build and can be lost very quickly.
Trying to suppress negative news leaves the problem unresolved. A company might spend a huge amount of money and resources getting a story taken down or limiting its reach, keeping it out of the spotlight for a while. If it hasn’t changed how it develops, tests, and manages its products, the same kind of problem can happen again.
Does it then pay to suppress the next story too? That can keep consuming time and money until an incident is too big to contain. Controlling what people hear about a product won’t make it reliable or earn lasting trust.
There may be a problem with the company’s culture that goes beyond one defective component. If protecting its image takes priority over fixing products, criticism becomes a threat and people become afraid to speak up. Removing negative stories won’t change that culture.
When someone finds a bug in my code, I want to hear about it, even if it hurts my feelings. I might disagree with their assessment; they might be wrong about the cause. If there’s a real bug, though, I want to find it and fix it. That’s how software improves, and I don’t see why the same principle shouldn’t apply to cars.
MAEXTRO should thank the people who found this defect and be open about how it plans to address it. Refusing to acknowledge a mistake makes it harder for consumers to trust the company. Admitting it and fixing it gives them a reason to do so. Attacking the people who found it wastes time that could be spent on the repair.