[We asked an AI what it thought the pitfalls of electronic product development were. This is the fourth in a series of articles provoked by the AI’s response.]
The time between creating a prototype and starting a production run is longer than most people imagine, but there isn’t really a lot to say about it. It’s all very standard project management stuff; you make sure your people are all still working towards the same end and talking to each other, just as you have throughout the design process. As you get nearer the point of starting production, however, things begin to change.
Before we start on what can go wrong when getting ready for production, a warning: the AI-generated outline that we are working from raises points that apply more obviously to large production runs (and indeed large companies) than to the smaller runs we have more experience with. We have mentioned before that scale matters, and this is an excellent example. We will go into more detail for each point as we get to them, but be aware that the right solution to a problem at large scale may itself be a problem at small scale!
The three problems that were highlighted are:
- Insufficient Pilot Runs: skipping pilot production runs can lead to issues not being detected until too late, resulting in costly rework.
- Poor Documentation and Change Management: last minute tweaks without clear documentation can cause confusion.
- Not Accounting for Regulatory Compliance: certifications like CE or FCC compliance are often an afterthought, which can force design changes.
Starting with the first point, pilot runs are a must. You don’t turn your hardware production line on full blast the moment you have non-prototype hardware to build. We always recommend making about ten boards to start with. That gives you enough for your hardware engineers to test out and ensure they work, a few for your software engineers to develop on, and some spare for those inevitable occasions when someone connects the power the wrong way round. If there are any hardware changes needed at this stage, which may well happen, you can “respin” the design instead of having to modify the entire production run.
The AI’s recommendation was to run multiple pilots with full QA processes. This is sensible advice if you will be building tens of thousands of units. If you are building a hundred, it is overkill. You need to do enough testing to be sure that your product is both correctly designed and correctly manufactured, and you should absolutely follow up on any suspicions your designers have, but very often even a second pilot run is unnecessary. Heavyweight QA processes that are essential for large production runs will be disproportionately expensive on smaller runs, not to mention stifling the creativity often needed to diagnose and fix any problems found. As with all things, there is a balance to be struck.
The second of the inevitable three points raised was about the chaos that poor documentation and change management can cause. That is an issue from the very first moment of a project! The main reason to raise it at this specific stage is that final corrections to a PCB can be “small changes” that get easily overlooked. Regarding almost anything as too small a change to matter opens the way to madness. You should document and apply version control to these changes just as you have through every step of development (you have been documenting and using version control through every step of development, haven’t you?). That way the instructions delivered to the manufacturer will be the right ones, for the right version of the board.
Even for prototype units — perhaps even especially for prototype units — it is important to keep track of what changes have been made to each individual board. It can be done as simply as writing on a tag tied to the board, but it is vital. When issues arise, you can waste a great deal of time checking whether a lack of modifications to the board are the culprit if you don’t have such things properly recorded.
The final issue raised is one that many clients aren’t very familiar with: regulatory compliance. We bring up the regulations that a product will have to comply with and the tests it will have to pass as part of scoping a project, and there will always be some, but it is very easy to forget about such things until testing time is upon you. It is at the pre-production phase with candidate final boards that compliance testing finally bites.
Experienced developers will have kept the relevant compliance tests in mind throughout the design process. At the very least your product will have to pass EMC tests, which ensure that it doesn’t radiate electromagnetic “noise” unduly. To do this, the circuit board will have been carefully designed with the copper tracks in exactly the right positions to avoid potential issues. Surprises can still show up, even for experienced hardware engineers; on one occasion a heatsink turned out to have exactly the wrong shape and caused an unexpected noise spike!
Passing compliance tests can look like black magic (strange geometric shapes are scribed on the circuit boards!) but in reality they take planning. If your product will need particular regulatory certifications, plan for it from the start. Sometimes this will mean getting expert advice while you are still scoping the project. You can use the boards made in your pilot runs for informal testing, to give you more confidence that your final product will pass the required tests. Regardless, you should make allowance for the time this will take in your project plan. It is desperately easy to undervalue testing, but compliance testing is not optional.
These then are three of the pitfalls that can surprise you as you ramp up towards production. There are many others, some of which have been raised in earlier articles; making sure you can obtain all the necessary components, for example, or not learning and applying the PCB design rules your manufacturer uses. Perhaps the most important thing to bear in mind is that things can go wrong at this stage; starting a production run is not a simple thing.