Mitigating Product Development Risk

What happens when a key supplier drops the ball

Drew Westrick
Glassboard Blog

--

Risk mitigation is important so that when things go wrong, they have less impact on a project

Working in product design and development, we live and breath change. Alas, it can be difficult, even for us, when something unexpectedly changes. We spend our time developing and refining a product, only to find that a key supplier or component is no longer available.

Sun setting. Discontinued. Not for New Designs. Obsolete.

Being on the cutting edge of development and technology means that when we pick a tech to implement into a customers product, we want to make sure that it will be available for that products lifetime. Prediction is hard (it’s why I don’t bet on sports), my time machine is vaporware (same goes for my electric John Deere), and this computer engineer doesn’t know when it will be completed, we have to do the next best thing: prepare.

How do we prepare? Being prepared means before starting any project at Glassboard we identify the high-risk components, study and understand alternative technologies and their options, communicate with the key suppliers, and independently and thoroughly vet critical components. During this time we aim to keep the client informed of changes in their products development and the overall plan.

1 | Identify High-Risk Components

identifying risk isn’t binary, it operates on a continuum

There is always a riskiest component. However, if each of your sub-components has multiple suppliers, then it may not be worth spending time mitigating supplier risk. It may not be a big deal to simply switch between suppliers. More often, however, there is one or more parts of the device that involves a high-risk component. Are any of the components used in your device proprietary or only available from a single supplier? You must pay special attention to these.

One example is the burgeoning field of wireless communication for the Internet of Things (IoT) and Machine-to-Machine (M2M). There are many different types of communication protocols with different technologies and different competitors within each technology. They all have their own set of advantages and disadvantages. The market is changing rapidly, with new networks and feature coming online in the near future. When comparing the competing technologies, the tradeoffs are not always clear — and the tradeoffs we make at the beginning of a project may not have been the right choices by the end of the project, or further into the future.

Use generics when available

2 | Understand the Alternative Options

use generics where possible

If a new technology is not going to set your product apart and is not required to make the product work… then don’t include it. It is better to include a tried and true reliable generic technology for the parts that don’t need to be spectacular.

Another rapidly changing technology is portable rechargeable batteries. There are many different chemistry configurations and associated electronic protection circuits, and it is sometimes overwhelming to try and find a battery that fits a particular device. A custom battery will add development expense due to the testing involved in certifying the new configuration. A generic battery that lasts long enough may be better than the custom battery that can eek out 20 minutes more runtime. There are tradeoffs, but there is no sense in developing a great product that has no long-term viability.

If your supplier is at a risk of not being around for the duration of the product, it may be good to follow an industry standard in order to ensure that other suppliers exist and will be there to pick up the slack. If you have done the research to determine the best supplier to go with, then you have an idea of the next best. It may be prudent to watch them and if possible, design in a versatile interface from the beginning, such that the product could use either.

3 | Communicate with Key Suppliers

before prototyping starts

Make contact with key suppliers and discuss your potential product, either through a sales channel or application engineering group. If you can determine their long(er) term plans for the component you are using, that is great, but at a minimum, talk to them and show that you are interested in understanding those plans. Try to understand where your supplier is going, and determine if any new products are coming through their pipeline or if certain features will be dropped. Suppliers have competitors, and while you are making the best decisions for your product and company — realize that they are doing the same for theirs.

Be wary if you are a small outlier, and not core to the supplier’s business. The supplier may be looking to grow in your direction, which is good, but they may also be looking just to profit in the short term and abandon your line if a larger market doesn’t materialize. On the other hand, if your plans involve ramping up with high volume production, this involves a different and more involved level of communication with suppliers. Finally, make sure your supply chain can handle the expected volume when your product takes off.

4 | Vetting of Critical Components

test and verify

Sales brochures often do not communicate the technical details of a sub-component so make sure you have verifiable data before designing a component into your product. There may also be some aspect of the feature that is listed on a data sheet, make sure to spend the time verifying that the data sheet is correct. That is typically is just the start.

At Glassboard, we develop internal prototypes to run not only the entire system, but also sub-systems and their components through their paces, ensuring that it works in the way both we and our customers expect to use in. In the early prototypes we share with our clients, any undesirable behavior sets off flags that we need to understand better. Test and verify.

While we spend time a lot of time vetting the components technically, it is equally important make sure to vet the supply chain for both volume and quality. While the supplier may provide one good component, can they produce a million (or your projected volume)? The project’s success depends not only on the product, but also on the entire supply chain that supports it.

Your components also need to be vetted in the environment that they are going to be used in. In the wireless IoT world, it may be trivial to get one node working, but there needs to be some idea of what happens when the product is ramped up to the ten of thousands that are needed for your customers application.

5 | When to Include the Client

have a corrective action scoring worksheet

There are messy details in product design and development — many clients hire us to take care of those. If those items are defined in the functional requirements, and we can make a change without affecting those functional requirements, we will usually do so and not involve the client, but let them know if they are interested.

If the change affects the functional requirements, or it is going to affect the long-term usability of the product, we have to involve the client. We usually understand the problem and the options, but in the end the client is the one that makes the decision. In these cases we present the options and tradeoffs to the client as we see it so they can point us in the right direction.

6 | Have a Direction

even if it is going to change

We have to be going somewhere. The plan is the plan until the plan changes — we cannot wait around for the situation to “equalize” because in product design and development, it never does. If we do not have a direction, then work is not getting done.

We also try to have the documentation and rationale behind big product decisions we make. A rationale allows you to explain why you made a certain decision, with the available information at the time. When looking at this from the future, these rationales make it easier to identify the incorrect assumption, wrong thinking, or a factor that is no longer valid.

Risk mitigation happens so that fewer things go wrong, and when things so go wrong, recovery is possible. We think about this in the design process for products, thinking of potential failure modes. This thinking is also useful then thinking about our design process. Our recommendation is to be prepared when a supplier drops the ball.

Drew Westrick is the VP of Technology at Glassboard a hardware focused product development company.

--

--