Compared to software, developing hardware is a whole different story. Correcting mistakes takes much longer and could cost way more. One mistake can set you back several months while in software development some issues can be deferred or handled with in-market updates. To put shortly, with hardware you have to plan the details and manage the risks here and now. In this article, I highlight some common risks in hardware development you usually face and how you can avoid them.
Hardware product development can be divided into three main phases:
In the concepting phase, product requirements are fixed and the product is turned from an idea to architecture and design principles.
The development phase is where the majority of the R&D happens. And this is the part where the cash burn will jump to a whole different level. Concepting is cheap, R&D is expensive.
When product is ready, production ramp-up and deliveries to customers can start. This phase includes also customer care, production fine-tuning and maintenance. The phase includes another unique pain point of HW business – inventory. You have to tie enormous amounts of cash into components before you can actually start shipping.
Delays in R&D and sales start
This is the most common problem that product developers face. The work just takes longer than expected or changes are needed during the project. There’s a direct impact on the business case, since the production and sales start will be delayed. This means simply extra R&D costs and obviously delayed cash inflow from sales. Here are couple of the most typical pitfalls you could spot before you run into them.
Risk 1: Surprises in product-market fit
The worst thing of all is to develop the wrong product. In quick user tests people want to be polite and give positive answers on your idea. The key is to find out if they’re really interested on your product to pay money for it. Not testing the product features and commercial potential properly in concepting can cause real trouble in product development phase.
Here’s what typically happens:
- You’ve kicked off the R&D phase but you find something new that should be in the product and you start asking changes. You feel it’s absolutely necessary to change requirements while the R&D is already running.
- Something you considered important turns out not to be such a gem. You end up wasting time with unnecessary work and hassle.
- Real market potential is not clear. You don’t have proper proof of traction to get funding and resources for your product development.
It doesn’t make sense to start the product development before you’re sure about the product requirements and fit to the market. Once you kick-off the development, the costs start to accumulate and later changes become more and more costly and they drift the schedule.
The cure is simple: keep testing and truly freeze the requirements. Build simple early prototypes and let the users test them in real life. Great new tool to find out the commercial potential for the product is a crowd funding campaign. If your idea attracts lot of interest, there’s probably enough market pull.
Risk 2: Product requirements are not locked
It is easy to let things slip forward: ”That sounds complicated, let’s decide later in the R&D phase.” If you keep having these kinds of discussions, your concept work is not done properly. The product requirements are related to four basic parameters: content, costs, quality, and schedule. Make sure you really lock and freeze these things before going to R&D. Some usual ways how you might slide into this without noticing this:
- Some feature or product decisions keep slipping until there’s no chance to decide anything anymore. The feature is there and you can’t change it.
- It’s fun to talk about features but quality and price targets are easy to be left on lower attention. This affects to what components and materials will be used, how supply chain is built and what kind of product testing is done.
- You can and should take risks in R&D, otherwise nothing new would ever be made. But don’t take totally new technology directly to product development with super tight schedule. Learn it offline before committing it to the product. For example, if the product needs to be waterproof, spend more time in concepting to clear out how it is made, do not leave that to R&D phase.
- The schedule is dependent on the other requirements. Speeding up hits the other parameters for sure, and might show up in product quality as there’s not enough testing time. Even if you save money with shorter time-to-market, you may face sudden expenses in later phases of the process.
If the product requirements are not clear, it will generate changes during the product development. Eventually it delays the sales start and increases total cost. Again: Planning and concepting is cheap, product development is pricey.
Risk 3: Product requirements are changed
At some point in the project you face an urge to change something. Add a feature, drop something or get things done earlier. Even if it seems small, these changes always come at cost in some way or another. It could be additional workload, extra costs, shorter testing time, lower quality or eventually delays in sales start.
When changing requirements, prepare to face challenges like this:
- Changes always cause unnecessary hassle. That’s the spot when something could go wrong.
- The change usually gets implemented in a non-optimal way. Things have to be rushed together.
- Cutting the schedule has an impact on the reliability of the time-to-market. Changes may cause an unpredictable amount of work in the ramp-up phase.
- Change in the R&D phase to the spec causes problem with your inventory: you might have loads of old version of the HW in the incoming pipeline and you know that it’s going to waste.
- Keep in mind that you’re not going to get mandatory certifications (CE, FCC etc.) before you have the final product at hand.
If compromises are necessary, find out in detail how they will affect the whole process. Trust the specialists’ insight when you make decisions. It is a mistake to assume that the process could continue without changes to the original plan. The decision to change product requirements should be agreed with all parties involved in the process to ensure delivery commitment from the team.
Check more in story part 2, where I will cover risks in the production phase.
If you need help with your hardware development, check out our product development and UnSeen Labs serices and see how out experienced team can help you.
Esa Alanen
This article has been first published as a guest blog in Hardware Startup Finland.