If you are looking at a product development and manufacturing team that can seamlessly take your idea to market successfully, look no further. Meet our team today!
Top costly mistakes to avoid when designing electronic hardware products
To successfully launch a new electronic or electrical device into one or more target markets, several crucial pointers must be considered during the New Production Introduction (NPI) project. Failing to do so may lead to the device not meeting key end user requirements, key regulatory requirements and even a limited commercial launch.
The following is a non-exhaustive list of activities that should be carefully considered during the initial phase of most NPI projects for electronic and electrical devices. Thoroughly addressing these activities can help mitigate the risk of failure during the product launch.
1. Determining necessity of the product
As a product owner and an entrepreneur, it is important for you and/or your team to conduct market research to assess the demand for your electronic device in the intended geographical markets. This will help determine if there is a genuine need for the product.
If there is no ‘need’ for this new product, it will likely not sell or succeed with most targeted end users. Resist the urge to design a new electronic device product with multiple features that are ‘trendy’ on social media and look good or “cool” and focus on the need for the product without charging ahead to a final solution.
When creating an electronic product requirements specification, ensure all items listed are useful, and will increase your return on this investment. It is essential to assess whether the features requested by a particular individual are in demand by a broader audience or just a few individuals. If a feature is deemed necessary for the product's core functionality, it is worth investing resources and time. Additionally, exploring the possibility of adapting your electronic device for use in different industries can increase its potential for future sales.
2. Preparing a proper detailed product requirements specification
A good product requirements specification should cover and elaborate on the main requirements: Product purpose, Block Diagram, main hardware, firmware and/or mechanical features, environmental condition, specific end use cases, critical target costs, sustainability, serviceability, and manufacturing requirements. Inconsistent or incomplete information regarding commercial aspects, design, functionality, and regulatory compliance/certification can result in misinterpretation by the design team, leading to revisions and delays throughout each step of the NPI process.
3. Properly estimating New Product Development Costs and Timelines
A common mistake made during the development of new electronic products is the failure to account for the expenses associated with the NPI process. Creating and manufacturing prototypes is an example of one such expense. And this can be an exorbitant expense due to the production of a small number of units, as costs fluctuate depending on the price and availability of crucial components, sub-assemblies, and other non-electronic materials such as enclosures, insulators, wiring, internal mechanical parts, and so on.
In most NPI projects, more than one prototype build will be needed. The first build (Alpha Prototype) usually requires changes for many reasons, such as less than 100% functionality, and cost optimization to a target. The overall form factor of an alpha prototype may need multiple connector location adjustments, change to the overall product aesthetic look, changes based on customer feedback, additional HMI indication updates, etc. and may require changes to the product enclosure. Critical parts or sub-assemblies may become obsolete or have no stock or have a very long lead time over the time from concept to first prototype build.
To avoid these issues, we at NeuronicWorks strongly suggests creating a High-Level Design, identifying active (not obsolete or NRND) critical parts (especially popular IC chips) and sub-assemblies and pre-ordering if availability is an issue. A highly complex electronic product will likely take two to three iterations to get it to the Pilot production stage.
4. Timely communication between all stakeholders
There should be regular NPI project communications between the product development key stakeholders: Marketing (representing the end customer), Product Management (representing the OEM executives), Engineering (representing the OEM design group), Quality Assurance (representing project requirements and regulatory compliance) and Manufacturing (representing purchasing, and production groups). Each group should review the successive designs, test reports, Minimum Viable Product (MVP) features, sub-assembly and system BOMs against the NPI project targets and activity milestone dates.
In case of a significant non-conformance that could result in the loss of critical features, an excessive timeline to complete the prototype stage product, or parts and sub-assembly supply chain issues, all NPI project stakeholders must review and accept any decisions made regarding the project's MVP features.
5. Reviewing the required Regulatory Compliance/Certification regulations/standards at the earliest NPI design project stage.
The product owner and their team must determine the end application, geographic regions, regulatory compliance/certification requirements, and relevant industry standards that will be utilized in the initial and subsequent release of sales literature and manuals. If this information is not readily available, a good starting point for review by certification compliance consultants would be to verify the sales literature and certification records of similar products that have already been released in key markets. It is essential to identify the regulatory compliance and certification regulations and standards that directly apply to the EE product, including product safety, emissions, and RF radio operation.
These standards, regulations, and guidelines should be made available in the latest release and preferably in digital copy format, and in English language to the Product Manager, Engineering team (including Electronic, Electrical, Mechanical, and FW development), and QA technical staff for reference and use during the earliest possible design stage, typically the Alpha Prototype phase. The standards, regulations, and guidelines will influence the sub-assembly design, PCBA design and parts selection, as well as the overall EE product system design, such as enclosure design and selection, internal mounting, insulator, wiring, and field terminal design.
6. Failure to Design for Manufacturing/Testing/Servicing (DfX)
Designers often underestimate the complexity of manufacturing a PCBA board and complete EEE equipment, including wiring, enclosures, terminal blocks, PSUs, and other components. For new EE products, the costs associated with setting up production lines, purchasing materials, obtaining proper tooling, training assembly staff with proper work instructions, designing test workstations, and developing a good QC checklist can be just as expensive, if not more so, than the NRE development costs. It is much wiser to design a product with manufacturing constraints in mind after reviewing the first prototypes. Even a small change in mechanical or PCBA design can significantly reduce assembly times and require fewer parts using fewer tools. Additionally, by implementing a proper PCBA design with multiple test pads, it becomes easier to create an automated test fixture, thereby enabling easier troubleshooting for returned EE equipment.
7. Insufficient resources/timelines for proper Bench and Verification Testing
Product testing is one of the most important engineering activities in the electronic device NPI process. It is important to test the critical functionality of the product across a range of inputs, outputs, and environments. Any issues that develop during testing should be recorded and addressed in product issue / workflow database, such as JIRA. This documentation should provide sufficient information to ensure that all project stakeholders understand the issue. Failure to address these issues will lead to problems during full production release. If the NPI product does not function at a high-quality level (i.e., functionality, reliability, ease of use, etc.) that meets your target customers' criteria, it will be difficult to drive sales.
After the prototypes are manufactured, the first step is product bring-up. This activity involves slowly and carefully powering each circuit element, then testing for basic functionality, and determine if low-level firmware drivers (if applicable) can control these circuits.
The next step is verification testing, which involves checking if all hardware circuits are functioning within the designed parameters as per the latest requirements document. This testing should be conducted across all supply voltage ranges, temperatures, humidity levels, and component tolerances. It is also important to test alternate components mentioned in the product BOM to ensure that they function properly as well. This testing will provide some component supply chain options for your CM purchasing team, which is particularly important in today's world.
Most electronic product use embedded firmware source code to define functionality. The firmware design is broken down into features that are released, tested and debugged in sprints, and have regular releases in a project database, such as JIRA for testing in the product prototypes. it is essential to understand and identify all the necessary certification requirements from the very beginning. Important features such as firmware version roll-back and Over The Air (OTA) updates should be tested prior to release. Every code change is risky, so testing of firmware code changes along with ensuring that core functionality is not affected should be done and signed off before release to your QA validation team.
8. Overall system integration review & testing using different design groups to fulfill NPI design project requirements
Not having a proper NPI product system integration test plan that has not been reviewed by overall product major stakeholders, (Systems design, Product Manager, etc.) will lead to unexpected errors, requiring review, redesign, and additional prototype builds. This is especially true when there are several players involved in the design and development. For example, when the hardware design is performed by one group, firmware source code by another group, mechanical/industrial design by another group and QA validation by a different group.
Assigning the right dedicated team to a NPI Project with all product design disciplines like hardware design, firmware source code development and mechanical/industrial design in one location/company with scheduled group reviews and a strong QA validation system integrity test plan will help mitigate these unforeseen ‘bugs’ before the final prototypes and documentation is delivered to the client.
9. Oversight of Pilot pre-production build manufacturing quantities
If the pre-production (Pilot) build is omitted, it can lead to cost overruns for purchasing, receiving, assembly, testing, and packaging. It can also result in delivery date problems, particularly if there are problems with key component/sub-assembly suppliers, poor staff training, or inadequate tools and instruments for large-scale volume production. Scheduling and conducting a Pilot build manufacturing run at a reasonable quantity (near or at typical mass build quantity) will highlight issues with purchasing, receiving, warehousing, assembly, test, and inspection steps. The Contract Manufacturer (CM) stakeholders and the engineering design group should record and review these issues as needed. The individuals responsible for mitigating these problems should assign solutions and present them to the NPI product stakeholders within a short period. If accepted, they should be implemented promptly to prevent future problems.
This topic has also been addressed in two other articles on our blog and you can read them here: Common costly mistakes to avoid in product development Part 1 and Part 2.
All Blogs