.svg "bes-logo (1).svg")
At BES, our clientele is extremely varied and the assistance they require from an engineering consulting firm like us is just as diverse. Remarkably, there is a trait that can pop up in product owners of any type, from local individuals contemplating a career shift to entrepreneur to well-established international companies: a software background that colors their expectations of product development.
We love software at BES! So many of our designs integrate with some type of software, whether it be a complex database or a client facing app. However, there are some development methodologies that don’t translate directly from software to hardware, and that can cause frustration for the a product owner. For example, you’ve probably heard about “testing early and often”, a cornerstone of Agile development. In hardware, we love to test as much as possible too! But there are some inherent realities of physical products that can diverge from the signature two week sprints associated with Agile Methodology: Unlike an app, hardware features or updates can’t be near-instantaneously pushed to beta testers, and there are some hard costs associated with every release.
Leadtime.
Once you’ve completed a design that you’re anxious to test, it can take some time to actually build it. In the early stages of development (proof of concept and early revisions), perhaps you can put together the bones of a product with materials you have on hand very quickly (a couple hours). As you progress, however, it’s likely that you’ll start running into more serious lead times (like PCB building and assembly, material shipping, any assembly that you can’t do in house, your own internal testing, etc.) that affect your overall timetable. Of course, there are some great technologies that can assist here -- 3D printers have a huge impact on reducing schedule days to test out mechanical designs, development boards can get electrical projects up and running in record time, and embedded/software modules have been crucial in getting to testing faster. However, these aren’t always appropriate for later prototype revisions, especially as cost optimization becomes critical as you’re finalizing the product for volume manufacture. Additionally, there are sometimes options to pay a premium for a rush order for off the shelf (OTS) components, machining, or PCBA, but it depends on how much budget you have available for expedites, whether your vendors can fit you in, and available stock (give vendors a healthy heads up to expect your product on a certain calendar date to help mitigate these issues). Make sure you’re building these lead times into your development gantt charts so you won’t have any nasty surprises when you press order on a part, custom or standard!
Component Costs.
This one is pretty obvious -- every time you put together a new prototype you’ll be buying materials or OTS components to put together. However, prototypes tend to cost at least ten times more than their cost optimized volume counterparts because you aren’t able to take advantage of the same price breaks and the assembly process isn’t optimized. Consider testing different features or components separately at first, so you’re not investing in prototyping working feature sets over and over again (note: make sure you don’t ignore testing the entire system together as well so you’re not surprised by any unforeseen, adverse behaviors!). Reworks are your friend to test out alternative designs before committing to a new prototype run of the entire system!
Tooling.
A separate but related issue is tooling. We touched on it in lead times, but tooling has significant budget implications as well. Not only can tooling take precious schedule days to setup, but often it can be quite expensive (you should be thinking in the low thousands to hundreds of thousands of dollars depending on complexity). For this reason, sometimes it’s advisable to use representative methods and materials during development, so you can simulate the look, function, and feel of a product until you’re ready for finalization of it.
Certifications.
Know the required certifications for prototypes and products in your target distribution areas! Often, prototypes don’t require serious certifications if they are not commercially sold to users, they’ll be returned after testing, there are few enough distributed, and/or they don’t have serious safety concerns associated with them. Many products, on the other hand, will require some sort of certification or adherence to a standard to be legally sold (one handy trick to is to look at similar or competitive products to see what certifications they had to address to get on market). Some certifications are self-declared which can reduce the lead time and cost associated with them (though you may be required to produce such documentation upon request by the certifying body, associated governments, or customers). However, many involve weeks to months of lead time for testing and documentation, as well as thousands of dollars of budget. Most certifications require production level releases (or at least representative materials) to undergo the testing. Make sure you’re intentional about when you certify your product so you’re not stuck going through this process multiple times!
Distribution.
Whether you’re testing a prototype or releasing a product, you have to physically get your product in front of your (beta) customers. This also takes time and dollars to achieve, especially if you’re also considering the transportation of various elements of your product to and from multiple vendors (perhaps one manufacturer is injection molding your enclosure in China, another local operation is doing your PCBA, and these are being assembled and distributed by yet another group in Mexico closer to your largest target market). You’ll need to think about customs in various countries if you intend to distribute internationally (both for prototypes and finished products), and keep an eye on any troubles with transportation methods (lithium batteries, for example, have their own shipping restrictions that you should be aware of if they are a part of your bill of materials!)
What does all of this mean? You’ll want to make sure you’re considering the costs (both in time and capital) of hardware development before you set your expectations for development. Testing is still a critical part of the hardware process, but there needs to be a healthy balance of development and validation checkpoints. Consider all of these elements and build them into your budget and gantt charts. When you do have hardware ready to test -- test it thoroughly! Hardware development is already an expensive process, so don’t squander budget on frivolous revisions -- have a clear understanding of what you want each prototype to do, analyze its functionality during testing, and revise your development plan accordingly for future iterations.
