Product development is a hugely challenging business. It’s hard to know how many ideas actually reach the market, but research suggests it could be few as one in 1,000(1).
The good news is that very few of the problems that can afflict a development project need to be terminal. Most of them can be worked around or fixed. The bad news is that in the wrong hands the cost of doing so can make the project unviable. Often, it’s not the problem that kills, it’s the solution.
Clearly, it’s much better to anticipate and work around any problems before they occur. That way you can address them before the cost of doing so becomes prohibitive. At TTP, we’ve spent nearly 40 years helping our clients cut through complexity and accelerate innovation, to go from brilliant idea to successful launch and beyond. So we’ve pulled together a list of common problems that come up during product development. Hopefully it’ll help you avoid them and make your product the one-in-a-thousand.
So, what do people do wrong when they do product development?
1. They develop the wrong product. Almost every product development project starts with someone spotting a gap in the market. Though this sounds like a winning formula it can mean development teams head off in the wrong direction from the start. They may have failed to understand what the market truly needs or will move towards. (And having said that most of these problems don’t have to be terminal – this one almost always is.) Or because the people who spot these elusive market gaps work in marketing and their commercial objectives don’t take technical constraints into consideration. In some cases, this can mean the project objective is unachievable from the outset. So the best option is to get the right market and technical input early on. That way the team can move on to something else before they waste too much time and money. This doesn’t have to be about shutting ideas down. Often looking at a problem from a different direction or through a different lens can lead to even better outcomes. Which is why we work in partnership with our clients and in agile interdisciplinary teams.
2. They don’t communicate properly across the team. Or the business. This is a particular issue for large, siloed organisations. We worked on a project for a big international client where there was a significant breakdown in communication at almost every handover stage. The marketing people didn’t tell the engineering team what they wanted. The team that did the conceptual work didn’t communicate effectively to the detailed design team; who are the people who write every line of code and design every piece of every mechanical part. The detailed design people then handed over to the prototype build and test function team, who built and tested the wrong thing. At no stage did anyone check back to the people earlier in the chain to make sure what they were doing still matched the original intent. And the marketing people, who started the project and should have been checking in at every stage, didn’t. Unsurprisingly, a lot of time and money was wasted.
Communication issues are most crucial at the start as this will set so many other stages in motion. In our experience, you can tell the way a project is going to go in the first two or three months of work. That’s when you’re capturing the requirements and working out what needs to be done. Clarity is vital, and it’s a balance. A project can be stymied at this point just as much because the requirements are too detailed to be communicated effectively, as when they are not detailed enough.
If they’re too detailed, it’s often because the priorities are unclear, so everything is on the wish list and it becomes impossible to focus on what needs to be done. This most often happens in big organisations. If there’s not enough detail, it’s usually a sign that the people who wrote the brief don’t really know what they want or need, they just want to get going. Start-ups are most often guilty of this. And again, it becomes impossible to focus on the right result.
3. They don’t manage the risks properly. There’s always a possibility that something will go wrong, so you need to plan accordingly. You need to identify the risks to the project – rather than the product – and work out their potential impacts. That way, you can rank the risks in the order you need to address them. So if you think there’s one particular technical requirement that, if it can’t be achieved, means the project will be in trouble, focus on that. Fix it and you’ll reduce a key risk to the project before it goes too far.
Communication or the lack of it – is also involved here. In siloed organisations, there are often different teams overseeing development and managing risk. For medical device development in particular, that’s a massive problem, because identifying risks guides the design. We worked on a consumer device development which illustrates the point in a fairly explosive way. The project was to develop an artificial cigarette. When we were brainstorming what might go wrong, somebody asked what would happen if someone were to light the end. And the answer was “It’ll go bang”. So we went back around the loop and fixed the design to allow for this basic user error. But if different teams had been looking at the risk assessment and the design, that issue would probably have fallen through the gap.
Sometimes businesses will have an aggressive approach to risk. They might be eyeing the benefits of getting to market as early as possible, or they might need to have something to show investors by a certain date. This may mean they look to save critical development time by starting the next phase before the current one is completed. We’re all for agile programs, but as this approach can significantly increase risks, they need to be commercially worth it and properly managed.
For example, running a clinical trial is a major project expense, so if you are going to do it at the same time as your design validation test (DVT) to speed the program up, then even before you start, you need to have good evidence that you’re going to predominantly pass the DVT. This way even though there is a known and significant risk, you are doing what you can to keep the project viable. As with anything, the ends can at least prioritise the means. If the benefits and gains are big enough, designing a program which builds in, even very expensive, risks can be worth it. But beware. Some businesses decide that even if they don’t have a stable design or a stable product, they’re ready to start building very expensive production lines. That’s very aggressive. And if they do run into problems, they often turn to teams like us, with the immortal request; “Fix it, but don’t change anything”.
4. They force the design and development teams into quiet submission. Taking a high-risk parallel staging approach can create the additional problem of making the entire project team less brave. This can not only hamper innovation but also stop people from calling out problems and risks when they spot them. For example, if you wait to start production tooling until the design is finalised, you maintain design flexibility. So even if you get halfway through your DVT and realise there’s a major problem which requires a few months of additional work, you’re still working towards a common goal with room to innovate. However, if you’ve commissioned £Xmillion of production tooling during the DVT and the design team spots a problem, they may not feel brave enough to raise it with so much at stake. And when issues do come to light, the development team might respond by saying they can’t redesign within the current parameters.
5. They bypass internal quality teams in pursuit of speed. There are two parts to every product development; the product itself, and the documentation of the development process. The two things should be in sync, particularly in heavily regulated industries. But because the documentation isn’t needed until the later stages of the process, it’s easy to let it slide while you’re focusing on the design. However, if you’re not keeping up with the collateral, one of two things is probably happening. Either you’re being very lucky and following all the regulations anyway, you’re just not writing any of it down. Or, much more likely, you are slipping, and you’re just saving up pain for later.
As with so many of these issues, it’s a question of balance. Writing everything down slows the development process and adds inertia. It discourages the team from making changes, because of the extra work involved in updating the documentation. But not writing everything down means there’s a good chance that, when the quality team do finally get involved, you’ll have to repeat a lot of your testing to complete the documentation. Sometimes it’ll be appropriate to push ahead, sometimes it won’t. The trick is knowing which situation is which.
Ideally, you want quality management involved from the beginning. Think of it as the difference between handing in an exam paper to be graded and collaborating with a supervisor on a thesis, reviewing it together as you go along. You want to be doing the latter. Either way, you need a passing grade. If you fail, you have to keep trying until you pass, and you’ll pass a lot sooner working collaboratively.
6. They see the prototype as the end-goal. Put simply, a working prototype isn’t enough. In fact, several hundred working prototypes may not be enough, depending on the volumes you intend to manufacture. If high volume production is part of the commercial requirements you need to design for it from the start. You also need to work out whether the product you’re working on is going to have special packaging or transport requirements. You could design something fantastic, but not robust enough to cope with standard transport and delivery options, and something so basic could make the difference between success and failure.
This is often a problem area for start-ups. The people in charge have the specific knowledge and experience required to come up with a great idea, or a piece of technology. But they rarely combine that with a solid grasp of manufacturing. In one project we were brought into, the concept design called for a hole of a particular length and shape to be drilled into a piece of plastic. The problem was that it just couldn’t be manufactured reliably. The hole was too long and too tiny, so when the piece was moulded, the material would block the holes in 1% of cases, which was way too many to pass the quality testing.
Often this situation can be avoided at the early stages of the project by approaching things mathematically. Even when you’re selecting which concept to proceed with, you can look at the layout of a design, assign dimensions, assign tolerances to those dimensions, and calculate whether the concept will work.
7. They don’t consider ‘aftersales’. Just because a product successfully rolls off the line doesn’t mean the development process is finished. There could be in-market failures or unforeseen usage issues which need to be fixed before the product is a true success. Just think of the sustainability issues that have come with disposable vapes or single use injector pens which have exponentially multiplied with the development of weight loss drugs. Being open and able to go back to the design development to create new generations of your product is critical to ongoing commercial success. If not, you risk damaging your profits or your brand, and in mass markets the possibility of governments stepping in with regulations which limit or even ban production. We did some work for a consumer electronics company. They’d bought a private label product, styled it to match their brand, and put it into production. But then about 10% started failing in use. So they were having to replace that 10%, which meant they had to manufacture 10% more, increasing their costs. But the real problem wasn’t that the products were failing. It was that the company had no process for collecting products that had been returned, analysing them and understanding what was going wrong. So they couldn’t stop the failures, and they were putting up with the cost of the returns, and with the damage being done to their brand. TTP addressed the underlying design issue and some minor manufacturing errors, bringing the failure rate down to well below industry standard.
8. They end up with the wrong product. The ruthless selection continues once new products make it onto the market. More than 30,000 products are launched every year, but some estimates put the proportion that succeed at only around 20%(2). There are a number of reasons for this, many of which have nothing to do with the actual product. But there are two that do. The first is there isn’t a market need. Marketing got it wrong. People don’t want that thing, or they do want it, but not at that price. The second reason is that marketing got it right, but people don’t want it anymore. The development project took too long, and the market moved on. Or someone else came up with and similar, or better solution, quicker or cheaper.
Goldilocks and the three reasons product development succeeds
As any golden-haired child wandering into strange houses knows – product development needs to be ‘just right’. So after listing the things we think can, and often do, go wrong what advice can we give to help you get it right? Well as discussed, there are all sorts of factors that can stop you achieving success, and some will be outside of your control. But there are three things you can do to mitigate most of them:
- Be clear of your goals and have a plan;
- Pay close attention to risk;
- Keep everyone involved talking
You can find out more about how to balance and innovation with quality management in our articles on ‘Speed vs quality in product development: striking the perfect balance’ , ‘How to stop quality management blocking innovation’ and 'Is your company culture the biggest risk to your product development?'
And of course, we’re always here to help with the complex and the difficult so you can succeed with your next market defining opportunity. You can find out more about our flexible approach to product development programmes here.
References
