Jay Feldis
Technical Program Management Consultant & Managing Partner
In the fast-paced world of technology and manufacturing, one of the biggest challenges hardware companies face is managing New Product Introduction (NPI) processes. A common misconception is that simply applying an Agile template used in software production to hardware production will solve all problems, but without thoughtful consideration, it’s a recipe for disaster. Whether it’s waiting weeks for a crucial part, revising designs after production has started, or dealing with field failures, these common pitfalls can lead to big delays, increased costs, and, ultimately, unhappy customers. This blog will dive into some of these common challenges, offering insight and strategies to avoid getting caught in a never-ending cycle of fixing and delaying.
What is different about Agile in a hardware context?
Launch Speed
There are aspects of hardware where Agile processes can be applied, but the main difference is the lead times involved in hardware. Once you make a design choice and execute it in hardware, you’re stuck with it for a long time. Even if you want to throw money at it, some things just take a lot of time, either because parts aren’t available or it takes time to tool or retool things. This requires another level of planning to effectively execute Agile processes. If you do it in a blanket way, as you might in a software project, you may end up costing yourself more time than you save if you do it at the wrong points in the project or on the wrong aspects of the project.
So, what attracts hardware people to use an Agile framework, nonetheless? Part of it is getting to market fast. Companies have learned that being first to market and just getting to market with your product, even if it’s not perfect, is key to winning in business because if you hold back and wait until it’s perfect before you put it out there, your competitors would’ve already grabbed your market share.
In the software space, however, especially in consumer-facing areas, there isn’t a tremendous risk of making errors in execution or product design choices. If you release an app that doesn’t work right or users hate it, you just kick off another sprint, and in two or four weeks, you’ve updated it and fixed it. There isn’t necessarily a really long lead time to fix a problem, whatever it is. This removes the need to do a lot of careful, upfront research and design. It pays to just go fast, keep what works, and throw out what doesn’t, and just keep iterating. It’s very conducive to iteration.
So, of course, people want to move that speed to hardware NPI. If there’s a piece of hardware involved, why not? It works for software, and a lot of times the people most requesting it are coming from software. They’re a software company, a software experience person who now has to add a piece of hardware, and they want to apply the same principle.
Product-market fit
Another aspect is the idea of the process of searching for product-market fit, and that if you can put a product out there, let users play with it, get feedback, and then adjust it quickly, is a lower-risk way to find product-market fit.
The challenge with hardware is that it’s not so easy if you make it a particular shape, size, or weight, or, for example, put the buttons in a specific place, and, then, it’s hard to change quickly. So you need to put more effort into figuring out the design early and not leaving it to a later stage to verify because changing it’s going to be painful.
Let’s take the example of a software company that wants to acquire a hardware doorbell product, for instance. Now you’ve got a piece of mechanical hardware that’s fairly specialized, and the app’s going to control it, but you still need to design the hardware, because once you put it in someone’s door, it’s pretty hard to fix. Once it’s in the world, you can’t really push a physical update to it. You can do things with the software to try to compensate, but pushing a hardware update is outrageously expensive.
In the hardware space, if you decide to change a feature or a way you do something when you’re in the very early design stage, it’s a meager cost, just paper and prototype modifications. But as you go along the process of building, testing, tooling, starting pilot manufacturing, and then ramping up manufacturing, your cost of a change escalates. Now you’re getting into throwing out parts you’ve already purchased, throwing out tooling you’ve already paid for, throwing out products you’ve already built, or recalling stuff from the field. So the cost of making a design change increases exponentially. As a result, a lot of thinking about how you would do Agile hardware is planning when in the process, you’re doing it.
Common Pitfalls
Timing is everything
So, like, let’s say you need a part for your hardware, right? Sometimes, due to supply chain issues, it can take ages, like a year or even 26 or 52 weeks, to get that part in more than sample quantities. So, you make a design decision, order a larger quantity of the part, and plan to start production 8 months or a year later. But then, if you change your design and don’t need that part anymore, you’ve basically thrown money down the drain. Plus, you have to start over and order the new part, which might take another year to arrive.
In my many years of experience in the industry, I have witnessed numerous competent teams grappling with the challenges of hardware launches. This piece highlights some frequent missteps that underscore the difficulties of applying a software-centric Agile approach to hardware technology processes.
Doing the Easy Parts First
There’s a tendency to want to do the easy or cool stuff first and put off the hard stuff. But it’s crucial to tackle the difficult and risky parts first. For example, if the gears are the trickiest part of the design, focus on getting them right before moving on to other aspects of the product. This approach will give you more confidence that you’ll meet your schedule and release a good product the first time.
Never-Ending Design Changes
Here’s where things go sideways. Some companies just can’t stop tweaking their design. They’re like, “Oh, we can make it better!” So, they redesigned it, only to find out the new part would take even longer to arrive, and then they postponed their product launch by six months. It’s a never-ending cycle of delays that can lead to never launching the product at all.
Field Failures
Now, let’s say you manage to deliver your product, but you’re still revising the design even after the product is shipping. This is more common with high-value items, where you’re shipping a few units at a time, and each one is super expensive.
What I’ve seen happen is that engineers keep tweaking the design after each unit is shipped. So, after a year, you have like 50 units out there, each costing $200,000, and each one is slightly different. Then, when problems start popping up, you’re left scratching your head, like, “Wait, what was in that one again?” And you have to figure out if it’s a widespread issue or just a one-off problem.
This leads to engineers spending all their time fixing field failures on unique versions of the product instead of designing new products and features. And because the design isn’t standardized, technicians can’t help with the repairs or updates; it all falls back on the engineers. So, they’re stuck fixing things instead of creating new things.
Getting Caught in a Loop
It’s easy to get caught in a loop of constantly fixing a less mature product that you’ve already shipped. Good project planning and documentation can help control that, as can limiting the frequency of changes. Instead of making each unit different, ship them in batches with the same version, and then manage them with version control.
Thinking about the product’s entire lifecycle and prioritizing the riskiest decisions early on can also help. For example, focus on prototyping and testing the riskiest market and technical aspects first. This way, you can eliminate high risks early on and avoid affecting the entire design later.
Missing Shipping Dates
Missing retail delivery dates can be a disaster. If you’re targeting the Christmas holiday, for example, you need to be on store shelves by September and online by October. Missing that deadline by even a month can be a dealbreaker. You have to plan your projects to ensure you’ll meet your deadlines because your marketing, advertising, and retail commitments all ramp up well in advance.
Identify risks and solve them early, and stage your design accordingly. This way, you’ll have a higher chance of launching your product on time and avoiding costly delays.
How to successfully use Agile methods in hardware NPI
Despite the potential pitfalls, the principles of Agile have the potential to transform hardware and enable teams to launch better products faster. The following strategies are the keys to successfully using Agile methods in hardware.
- Early Implementation: Implement Agile as early as possible in the program to minimize cost impacts and customer disturbances. This involves planning and structuring the program to determine where Agile processes can be applied most effectively.
- Rapid Iteration: Embrace the principle of rapid iteration. Instead of spending months or years perfecting a design, release an imperfect version, learn from user feedback, and improve the product accordingly. This approach involves creating a Minimum Viable Product (MVP) – the simplest, most basic version of the product – and then enhancing it over multiple product iterations over time.
- Rapid Prototyping — While simulations can be helpful, it’s only when you actually build and run the gear that you know if it works efficiently, is the right size, and has the necessary strength and reliability
- Phased Upgrades: Plan for phased upgrades over a multi-year timeline, adding performance and features in each new version. This approach can be applied to both hardware and software development.
- Product-Market Fit: Validate product-market fit as early as possible by testing the product with real users and gathering feedback on its usability and functionality. This can involve beta testing fast-prototype samples with a small group of users and making necessary adjustments based on their feedback before committing to large-scale production.
- Reduce Technical Risk: Identify and address the riskiest areas of the product early in the development cycle by using fast prototyping and development processes. For example, in hardware development, use fast prototyping methods like 3D printing to create a small sample of the product for testing and validation. This approach helps in reducing technical risk and confirming the design early in the development process.
By incorporating these strategies, teams can optimize their use of Agile methodologies, accelerate learning, reduce technical risks, validate product-market fit, and ultimately deliver a successful product to the market.
For example, I worked with a company that needed to create gears for a lock-type product highlighting the challenges faced by mechanical engineers with gears.
In this case, instead of relying solely on perfecting the design through theoretical simulations, the company took advantage of fast prototyping, using 3D printing or other rapid prototyping processes to quickly create a sample of the product. Although this method is expensive, costing 10 to 100 times more per unit, it allows for the creation of a few samples in just days or weeks. While the prototype may not work perfectly, it provides a valuable opportunity to measure and test the design. This confirmation early in the development process means that the size, strength, and mechanism of the design are known, allowing for the rest of the design to proceed with lower risk.
Ultimately, it’s about reducing technical risk upfront by identifying the riskiest areas of the product and proving them out quickly and early, using fast prototyping and development processes. This approach helps to confirm critical design elements early on, reducing overall risk and increasing the chances of successful product development.
In conclusion, effectively managing the lifecycle of a product, from design to production to shipping, is crucial for success. It’s important to identify risks early on, prioritize them, and solve them as quickly as possible. Additionally, good documentation, version control, and a focus on testing the riskiest parts of the product first can help avoid costly redesigns and delays. Ultimately, a well-planned and executed project will lead to a successful product launch, satisfied customers, and a happy engineering team.
