Imagine you're boiling water for tea. You grab the kettle – and the handle suddenly comes off. Boiling water runs over your hand.
That actually happened less than a month ago: Zwilling, a company based in Solingen, had to recall kettles[1] after handles detached. In at least one case, people suffered second-degree burns.
How can something like that happen?
One thing upfront: there's no such thing as absolute safety. No quality standard in the world guarantees 100% safety. But quality management systems (QMS) help identify risks like this systematically and push a product's residual risk below a tolerable level. Anyone who skips that risks reputational damage, hefty contract penalties, recalls, or liability costs.
Quality standards don't always have the best reputation – cumbersome, bureaucratic, tedious paperwork. And yet they're – often invisibly – embedded in almost every product we use every day. From the humble kettle to highly complex industrial plants.
Quality matters
"It was always unbearable to think that someone examining one of my products might prove I was delivering something inferior in any way. That is why I have always tried to put out only work that stood up to every objective test – in a sense, the best of the best." — Robert Bosch
The ambition to deliver the highest quality is timeless. And yet how we pursue it has shifted noticeably in recent years: products are getting more complex, development cycles are shrinking, new tools and technologies – massively accelerated by AI – are shipping almost weekly and creating constant pressure to change.
The result: we often lack exactly what quality needs – time, focus, and clear ownership. Quality gets reduced to checklists; filling them in serves compliance more than real assurance. Dedicated quality engineers matter, but as product complexity rises they quickly hit their limits and depend heavily on domain expertise.
How can we standardize quality?
All the more reason not to leave quality to chance. Over the decades, a whole family of standards has emerged. By far the best known and most widely adopted is ISO 9001[2], which has established itself across virtually every industry.
The trick: you can't standardize every product individually – there are simply too many, and they change too fast. Instead, we work with management standards (as opposed to product standards). They don't prescribe what a kettle must look like;
they describe how a company must run its processes so that a reliable product reliably comes out the other end.
ISO 9001 – the baseline
Over a million organizations worldwide are certified to ISO 9001. From small tradespeople to multinationals – if you want to be taken seriously in B2B, you can hardly avoid it.
The standard is deliberately generic and rests on seven principles. I want to look more closely at a few of them, because in practice they often decide whether quality management succeeds or fails:
Customer focus. Quality is measured by what the customer actually gets – not by what's technically elegant internally. Concretely: customer needs have to be translated into traceable requirements, tracked through the entire development process, and finally checked against tests. That chain from customer need → requirement → implementation → test is surprisingly often broken.
Process approach. Consistently good results only come from consistently good processes. Who is responsible for what? When is what checked, and against which criteria? What artifacts get produced? ISO 9001 doesn't mandate how you implement this – only that it's done systematically and documented.
Risk-based thinking. Since the 2015 revision, this is explicit in the standard. Not every screw needs an FMEA, but safety-critical functions do. Risks have to be identified and assessed, and where needed, safeguards built into the product to reduce them.
Continual improvement. The classic PDCA cycle: Plan – Do – Check – Act. Processes are set up, run, measured, and sharpened based on the results.
On paper it all sounds straightforward. In practice, the devil is in the details: where does this information live? How does it stay consistent when requirements change? Who makes sure a change in the requirements spec actually reaches the test plan and the risk assessment? If those questions aren't answered cleanly, the principles quickly turn into empty buzzwords.
Industry-specific standards
In higher-risk industries, generic ISO 9001 isn't enough. Specialized standards have emerged that build on it and add industry-specific requirements. A few well-known examples (far from exhaustive):
| Industry | Standard | Focus |
|---|---|---|
| Automotive | IATF 16949 | Zero-defect strategy, series production, supply chains |
| Medical devices | ISO 13485 | Patient safety, traceability, regulatory conformity |
| Aerospace | EN 9100 / AS 9100 | Configuration management, reliability, product safety |
| Functional safety | IEC 61508, ISO 26262 | Guarding against safety-critical malfunctions |
| Information security | ISO 27001 | Protecting information, risk management, access control |
All of these – like ISO 9001 – are management or process standards: they define how a company must operate, not what the finished product looks like. Alongside them, often in parallel, come product standards with concrete technical requirements. Even our kettle from the opening is far from "standard-free" – CE marking, EN IEC 60335 for household electrical appliances, EMC and RoHS directives cover safety, compatibility, and materials.
Compared with medtech or automotive, the difference is less about whether requirements exist than about how strictly they need to be demonstrated. But even without an auditor breathing down your neck, it's worth tracking requirements explicitly – EMC compliance or customer expectations around power use, size, and longevity, say – and maintaining proactive risk management so hazards like a detaching handle show up early.
Aside: Standards vs. laws
Standards are not laws. Formally, compliance is voluntary. In practice, that's mostly a theoretical freedom: customers demand certificates as proof, courts treat relevant standards as the benchmark for the state of the art, and regulations (such as the MDR or the Cyber Resilience Act) point directly to harmonized standards. Those who comply enjoy the so-called presumption of conformity and stand on much stronger ground in product liability cases.
Conclusion
Quality will never be a no-op. No matter how good the tools, how experienced the team, or how clever the AI. What we can do is make quality work a lot more appealing. Today it's too often treated as a necessary evil – spreadsheets emailed around departments, requirements tools with the charm of the late nineties, evidence stitched together on a Friday afternoon for the audit.
If we want quality to be taken seriously rather than merely performed, we need tools people actually want to use. Tools that bring specifications, risk management, and test evidence together on one platform. That keep specs locked to the product so they can't drift apart. Tools where real collaboration actually happens.
That's exactly what we're building with OakCore.