Unraveling the Phases of Electronic Product Development

Look around! Unless you’re reading a printed version of this article in solitude on a mountain or beach, chances are you’re surrounded by products. Whether it’s hardware products like Microwave, Mobile Phones, Smart Watches, or Software Products like Medium App or Chrome where you’re reading this article, a lot of effort is put into making these products. Let’s explore the cycle that begins with gathering requirements and culminates in deployment and continuous support, revealing what it takes to make these products available to users. Note: Engineering is an iterative process, and chances are each step or sub step discussed below will go through multiple iterations, finding, fixing, optimizing product making it hopefully better throughout the journey.

Requirement Gathering

One of the most crucial steps in any product development is identifying the correct sets of requirements. Requirements dictate what the end product will look like. Each requirement costs time, effort, and complexity, hence keeping requirements simple is an essential part of requirement gathering, but missing requirements would result in product usage being compromised. Hence, it is a delicate balance of making sure just the right amount of requirements are being managed. Adding requirements at the later part of the project though possible will result in further complications like changing the architecture and additional development time.

The requirements will come from multiple sources. Three main factors contributing to requirements are Product Reach, Industry Standards and Business requirements.

Product Reach

Product reach simply means the number and persona diversity of the end user who are going to use the product. The broader the reach, the thorough the requirements needs to be. If every user of the product is a competitive engineer, the likelihood of mistakes is lower compared to a diverse user base with varied technical skills, age groups, and ethnicities. In case where the personas and number of users are smaller, requirements can focus more on solving the problem whereas, if the diversity and number of users are broader, focus needs to be shifted on User Experience, inclusivity and intuitiveness of the product.

Based on reach, product being developed can roughly be bifurcated into 3 categories.

1. Consumer Product — This is the most challenging category since it contains the highest range of reach. Requirements needs to be collected by analyzing the market gap between the current offerings and user needs, identifying the problem to be solved and then making it accessible to end user. It is difficult to directly talk to end user, although you might be able to talk to a very small subset to capture the requirements and feedback. Indirect form of user engagement might be used like extracting data from online forums and comment.
2. Business Product — In case of business products, it is comparatively easier to gather requirements as the diversity of users are significantly small. Also, the end user is generally directly accessible which makes communication barrier far smaller. For business products, it’s essential to discern whether the user’s mentioned requirement is a genuine use case or merely a ‘nice-to-have'.
3. Sub System Product — Sub System Products are the ones which are not directly used by end user but are part of another bigger system. e.g. compressor which goes into a refrigerator. The end user for this is practically just the design team who are going to use this in their refrigerator. For this category, the focus is purely on technical specifications and meeting the requirements rather than ease of use.

Industry Requirements

Industry requirements are set by criticality factor of the end application and also the environment in which the system will be used and also the variations in them. These requirements are much more technical. They can originate from compliance and certifications needs such as if the end product is related to Aerospace, it needs to meet FAA compliance and testing. If it is a medical product, the guidelines will be set by another body. Whereas if it is a consumer product utilizing USB, USB communication compliance must be met to ensure it works with any set of certified hardware.

Some requirements also originate from variation in usage environment. A flight engine needs to work whether it’s -40 C or 80 C outside. It also needs to work at different pressure levels. Also, it needs to recover even if lightning strike hits it.

Regardless of the source, all requirements must be captured, prioritized, and assigned a budgetary value. Priority of requirement could decided based on whether the feature is “Must Have”, “Good to Have” to “Not Required”. Assigning budgetary cost to features might be difficult at this stage since it’d depend on product design and architecture, thus it could be assigned a temporary guesstimate which keeps getting revised.

It’s a good practice to make a requirement traceability matrix for all the requirements. This tracks the requirement throughout the development process as to which module encapsulate the requirement finally to be tested making the probability of missing the requirement lower.

Business Requirements

Business requirements consists of costing model, customer support, product logistics, product distribution, development budget, branding, marketing. Business requirements are essential marking the success of the product.

They also ensure de-risking supply chain, taxes structure, upfront investment and recollection.

Consumer product can generally be made cheaper if the number of users are large so that economy of masses comes into play.

System Architecture

Hardware Products have multiple aspects to them. Product designs encompass Electronic Design, Mechanical Design, Firmware, and Software, each of which can be further subdivided. At this stage, decisions are taken on the major blocks and systems which will be used in each area. This will depend on multiple factor like team’s past experience in the sector, cost, availability, modularity constraints etc. There could be several ways of realizing each requirement. It’s a good idea to test multiple of these quickly at this stage to find best suitable alternative. Development Kits, Clay Models, Open Source Examples should be used to get the feel of the final product.

The output of this stage should be blocks diagrams for Electronics/Software/Mechanical designs also ensuring they are cross compatible between domains. Make sure to check if all the requirements from Requirement Traceability is captured.

Module Designs

This stage is realization of each blocks captured in the block diagram. Each domain will have different steps and flows. Major ones of these are captured below. Note: Even though the domains are noted seperately, the design process of successful products are highly integrated. Each team ensures their constraints are communicated to other designs. Not just design teams, the same apply with logistics, procurement, finance to ensure success of the product. If you design a product and part can not be procured due to cross country regulations, or the product could not be shipped due to size, the process iteration becomes costly.

Electronic Design

The Electronic Design consists of various blocks starting from Power, Sensor, Decision, Actuation, Communication. All of these needs to be realized.

1. Hand Sketch — A rough idea of what each block is going to look like.
2. Design document — explanation of parts and consideration of design. Also contains design calculations if any.
3. Part Selection — Studying various datasheet parameters and alternative to decide on all of the major parts required. Along with technical parameter, de-risking the parts for supply chain, cost, availability is just as important.
4. Prototyping — Quick breadboarding/ barrow boarding new circuits with development kits to ensure and de-risk design before moving to actual manufacturing.
5. Schematic Design — Convert the hand sketch into design on CAD
6. PCB Design — Convert schematic to Printed Circuit Board which can be manufactured
7. 3D Model Design — Add 3D model to PCB Design to move it to Mechanical Design
8. System wiring diagram — How the PCB connects to external world or system

The output of this stage are

1. Electronic Schematic
2. PCB Design File
3. PCB manufacturing files (Gerber and pick and place file)
4. Netlist
5. Bill of material
6. 3D model
7. System wiring diagram
8. Design document

Mechanical Design

Depending on complexity, mechanical system could be static with no moving parts, merely having enclosure or it could have moving parts integrated with electronics. Mechanical system might even consist of moving parts with engine etc.

1. Manufacturing methodology — identifying major parts, which of those needs to be procured, which needs to have custom design
2. Design Calculations — For system with moving parts, various forces, moving systems needs to be designed and calculated. For enclosure, calculations might be smaller being restricted to material stiffness and other similar parameters
3. Custom part CAD — Parts which are custom designed needs to be drafted in CAD. The part can have different manufacturing method, starting from 3D printing, Sheet Metal, CNC, Injection Molding etc. Depending on the requirement, one or more of these could be selected
4. Prototypes — Prototyping mechanical designs are more complicated than Electronics or Software System. High risk items could be manufactured and tested using 3D printing, cardboard folding, clay models to evaluate the feel of physical bodies
5. Assembly Drawing — Assembly model or assembly drawing are system level assembly information for the team which depicts assembly of system either using animations, explode view etc.

The output of this stage would be

1. Design Document
2. Manufacturing Drawing
3. Assembly Drawing
4. Bill of Material

Firmware Development

The system containing one or more microcontroller needs to have firmware developed for them

1. Microcontroller Mapping — After controller selection, resources like I/O, ADC, Timer, Communication module etc. needs to be mapped to functionality and hardware interfaces
2. Modules — Implementation of modular code, which can be individually tested

The output of this stage would be

1. Firmware Source Code
2. Compiled Binaries
3. Design Document

Software Development

Depending on the product, the system might contain a software to interface with the device. These software might be a user interface or app to interact with device, a background service which monitors and analyses data sent by device or an active loop which controls the device based on certain parameter. For IoT devices, the interfaces could be multiple, and each one is a separate activity e.g. Alexa Interface, Web Interface, App etc. communicating with single device

1. Listing User Stories — for user facing software, user story are use cases or feature as seen from the perspective of user
2. Flow Chart — Making the logic flow of individual blocks
3. Implementation — Converting the logic to code which can be executed

The output of this stage would be

1. User Stories
2. Source Code
3. Design Document
4. Deployment Files

Module Verification

Module Verification step consist of validating each stage of design, be it schematic blocks, mechanical parts, software services, firmware blocks etc. Some blocks might be validated using simulations, some using electrical tests while few can not be verified before manufacturing.

Validation is a super important phase of quality product development. Making sure the parts are tested and have complete coverage. In order to test and verify the product, test points needs to be introduced in the design itself. Making a test plan ideally starts from requirement gathering phase, test plans are broken into verification plans, manufacturing plans, integration test plans.

Validation stage also incorporates ensuring you have proper instruments to perform the intended test. Some tests might be very specific needing specialized instruments which are not easily available.

I plan to expand on these activities further explained in future article.

Procurement

All BoM now for the PCB, System Wiring, Mechanical Design needs to be procured from various sources. For scaled operations, procurement team also deals for finding cheapest options for the material, validating quality before bulk purchases, dealing with taxes and clearances and receiving and binning the parts for the project.

Module Manufacturing

All the material is sent for various process whether internal or external shops. These shops include PCB Manufacturing, PCB assembly, CNC shops, Electrical wirings, 3D Printing, Sheet Metal, injection molding etc.

Specialized manufacturing operations would need specialized tools, during design phase, efforts should be put on how the designs would be realized.

For software modules, this stage represents hosting individual modules on various services.

Artifact Testing

Individual module created needs to be tested for manufacturing defects. Artifact testing is smaller subset of validation tests and ensures the product is free from manufacturing defects.

Electrical parts needs to have module testers to ensure manufacturing, BoM quality and make sure they need the decided specifications.

Mechanical manufactured material might be tested for dimensional accuracies, motions and forces.

Software and Firmware Modules are tested for edge cases. Software

Testing ensures product quality which is being delivered.

Assembly

All individual components are now put together as part of system. PCBs are wired together. Firmware is flashed wherever necessary. Enclosures are fixed around the units. Each artifact might be serialized for product tracking.

All Electrical, Mechanical, Software components all come together to work in unison, performing the tasks (or parts of) which were intended for them.

Depending on the product, the system might need calibration phase, or end user customization. E.g. of this could be a same part being sold in multiple configuration, where individual models are activated based on purchases.

Integration Test

Post assembly, each unit needs to pass through integration testing phase, making sure each unit manufactured performs to the standards set for them.

Again, the test design phase starts from requirement phase, not just here. Integration Test Equipment might need to be procured and developed which is a humongous activity in itself. Holding these activities till product design is completed is a horrible idea and will result in delays and cost overruns.

The end product is now inventoried. Entered into database with manufacturing details.

Deployment

Deployment phase consists from packaging, shipment, deployment in field, manual creation, product education.

For a consumer product, they are stored in warehouse. A tutorial or a guide on using the product needs to be created. Forums/FAQ are might be hosted.

For business product or sub system products, they’re generally installed in the end location by design firm or by end customer based on the complexity of installation.

Post deployment, tests might be performed to ensure acceptance of the product.

Support

On field, the products will have failures, users might break something. Support activity monitors the product, repairing them, finding replacements, maintaining the software and firmware. Chances are, there will be multiple versions of your product in field, support team also tracks performance data of each version, passing the information back to different teams working on it earlier for them to improve the process and design decisions for future products.

Conclusion

Hardware product development is highly integrated and complicated flow. The activities consist of unison of personals and teams ranging from Engineers, Finance, Logistics, Procurement, Compliance, Manufacturing. Each team as important as the next to ensure the success of the product. Even after awesome design, challenges might arise in manufacturing, testing or even end user usage which needs to be dealt with with agility.

I’m personally working on a hobby project navigating through each step myself, identifying good practices and learnings through each phase and implementing in newer projects.

I hope this article series will delve deeper into each phase, sharing insights and case studies. I’ve pipelined several articles focusing on Product Testing, Design for Excellence, Requirement Gathering, Embedded Design, 3D Modelling and PCB design in upcoming months. Hopefully, they’d bring education to the niche audience for the article and make their products better and avoiding the reinvention of wheel.