Quality teams are often seen as the bogeymen of product development, the unwelcome gatekeepers ready to block progress and prevent agility. Much like Procurement and Finance, who frequently bear the brunt of project teams' frustrations and rarely top the list of engineers' favourite people, Quality Management (QM) teams don’t tend to fare much better. Clients often complain to us that QM is either slowing them down or stifling innovation. We discuss speed-to-market in our article Speed vs quality in product development: striking the perfect balance, so this time we’ll consider why ‘Quality’ kills innovation. – or doesn’t.
Don’t talk to the quality team
We see so many development teams desperate to keep their quality department at arm’s length –usually because of bad experiences in the past, where things have been held up, stalled, or buried in paperwork, leaving them stuck at the first prototype stage.
It’s not just corporates that have issues with quality management. Start-ups struggle too, though for different reasons. Often, they don’t have a quality process at all; they’re too small, or they’ve drunk the Kool-Aid labelled “move fast and break things.” Either way, facing up to quality testing can be a real shock.
But if you think the quality team is stopping you from innovating, it’s worth considering what you really mean by the terms ‘innovation’ and ‘quality’.
Innovation: Better, or just riskier?
The word innovation has undergone an interesting shift in meaning over recent years. Dictionaries define it as “a new idea or method, or the creation of one.” Yet, somewhere along the way, innovative has also come to mean better. Innovation equals progress, and progress is always good. Except it isn’t.
You could argue that businesses should innovate as little as possible since innovation inherently means risk, and the more innovative the idea, the higher the risk. But innovation is vital for any business, so there’s no way around it – the risks simply need to be managed. And if you’re doing something that’s never been done before, the risks are significant; after all, there’s no guarantee it will work.
Product development is fundamentally about identifying and managing risk. The question becomes: how can we reduce risk in the process and increase the chances that what we’re building will actually work? You could stick with what you know. In this approach, the dream would be to bolt the same bits together in a different order and achieve an advantage. But that won’t work for every development project. Sometimes, you have to buckle up, enjoy the ride, and break new ground.
The key lies in understanding the level at which innovation happens. You can create something genuinely new while taking only minimal risks.
What quality actually means
It’s worth taking a moment to think about what quality really means and how it’s achieved. The role of Quality Management is to make sure that what you’re designing does what it’s supposed to do – safely, reliably, and in line with all the relevant regulations. It’s also there to ensure that, even if it’s misused or mistreated, it won’t cause harm or catastrophic failure.
Quality Management is the embodiment of best practice in product design. Once you’ve followed the rules explicitly a few times, they should start to become second nature – something you apply instinctively. You might not spend as much time writing up every minute from a review board meeting or documenting three levels of specification traceability, but you’re still applying the same tests and criteria. It’s about knowing when to follow the process rigorously and when to use your judgement to keep the project moving, rather than blindly skipping steps and putting everything at risk.
That doesn’t mean you should always say, ‘How high?’ when the Quality team says, ‘Jump!’ Just as development teams can become so obsessed with innovation that they forget their goal is to create something that works, Quality teams can sometimes get carried away enforcing process. There will be times when it’s right to push back, particularly in the early stages of a project. When working with big corporates that have strong Quality functions, we often find ourselves saying, “We don’t need that level of documentation yet; it’s not appropriate because we need to keep moving quickly.”
Of course, it can go the other way too. When working with start-ups desperate to go faster, we sometimes have to slow things down – whether it’s to run a risk assessment, hold a design review, or make sure the project isn’t heading in the wrong direction.
As with so much in product development, it’s about balance. Finding the right amount of process is key to success. Too little, and you’ll waste time figuring out the basics over and over again. Too much, and the project will grind to a halt.
Quality is a two-way street
Hopefully, you’re now fully convinced that Quality Management is a vital element of product development—not just a bureaucratic hurdle to overcome. But if you’re still on the fence, consider where we started. At the end of the day, the Quality team has to sign off your design before it can become a product. The question is: is that easier to achieve by working with them or without them?
The fact is, Quality Management can’t be killing innovation; otherwise, nothing new would ever be created. But equally, you can’t afford to ignore it, because chances are your product won’t work without it.
So how do you get the quality team on your side, helping you build a better product without burying you in paperwork?
Firstly, stop thinking of them as the enemy. They want the same thing as you: a successful product that does its job as well as possible.
Secondly, get them involved. The old saying, “It’s better to seek forgiveness than ask for permission,” doesn’t apply here. If you approach them in the spirit of asking for their help, things will run much more smoothly. You don’t want them brought in before they’ve bought in.
Thirdly, get them involved early. Explain what you’re trying to do and how you’re trying to do it. Ask them what you’ll need to do at every stage for them to sign off, but also make sure they understand when and why you might need to pause the process. Quality naturally tends toward stability—as soon as something is documented, it becomes harder to change. That’s why the timing of when things are documented and locked down is so important. Ideally, you’d lock down a top-level set of user requirements early but leave detailed elements flexible until later. For example, you wouldn’t want to finalise the geometry of tiny mechanical parts in your device too soon, because you won’t know if they’re right until you’ve tested them.
Fourthly, make sure you’re speaking the same language. This is a common issue in large organisations with siloed teams or multiple areas of activity, but it can also happen in start-ups where the founders and development teams use different terminology or jargon.
Finally, test everything as soon as possible. Don’t assume only physical objects need testing. And remember, everything you do should aim to ensure the next step works. If you’ve tested and documented everything at stage X, there should be nothing at stage Y forcing you to revisit X. For instance, we often make notes – such as how instruments are calibrated – because we know it’ll matter later, even if we’re not formally testing yet. You don’t want a product to fail quality because no one noted the lab temperature one afternoon in the early stages.
Understanding the role of each prototype
All of the above comes to a head at the prototype stage. First, everyone involved – across all departments – needs to agree on what each prototype is for. In some organisations, any prototype is treated as a showpiece: the first item off the future production line. But you need the freedom to test, fail, refine, and repeat to achieve ultimate success, and successive prototypes are a part of that: keeping the messaging and expectations clear materially increases the chances of a smooth project.
In all engineering development, the real proof lies in your ability to build something and show that it works. Modelling and simulation can take you far, but the product ultimately needs to work in the real world. It doesn’t matter if earlier prototypes look rough; what matters is that you can test them. They might not work at all, but as long as you can figure out why, the next prototype will be better.
You might go through ten or more prototypes, testing each one and then discarding it. That doesn’t matter. What does matter is ending up with a product that reliably, effectively, and efficiently meets the requirements—and one the Quality team can sign off on.
Find out more about the role of the prototype in our article on Speed vs quality in product development: striking the perfect balance
Quality doesn’t kill innovation; it nurtures it
Ultimately, you should aim to work with the quality team, not just do the bare minimum to keep them off your back. They should be an active partner, helping you take an approach that’s appropriate for the level of risk involved in the development. In this way, they’re not killing innovation—they’re nurturing it. Together, you’re assessing the risks, determining which are worth taking, and finding the best path to develop a truly innovative product.
You can find out more about our flexible approach to product development programmes here.
