There’s a common misperception among operations folks and engineers that they should spend their quality dollars on improving the mass production process. After all, the design is locked by then and those units will end up in customer hands, right?

A more efficient approach is to spend your resources finding and fixing issues in the development process. Each dollar spent to fix design issues in development will pay itself back in droves by preventing bad units from ever being made, or needing to be screened, in production. In this piece, we’ll dive into common misconceptions about confronting issues sooner rather than later, and we’ll make a case for why catching issues early will save you panic, pain and money down the line.

“I should wait until my product is more mature to address process issues.”

Many engineers want to make sure a product is past DVT before really starting to work out the kinks in the process. Say you’re making a consumer product that can’t be shipped with scratches. In your first build, the parts will be prototypes so they’ll arrive at your assembly line scratched. In your second build, you’ll waive scratches so that you have parts to input (they’re just engineering samples anyway, right?). Eventually, it’s PVT, then Ramp, and you haven’t yet been able to validate that your own manufacturing line doesn’t scratch parts.  And of course it does. At that point, you’ll try to figure out how to prevent the scratches. But by then, you’ll be throwing out a lot of defective units.

Say you’re making 10,000 units a day -- a 1% failure rate seems small, but that means 100 units a day are being thrown out. What if you made a fixture change now, in the first build, that would prevent all those scratches? You just saved 100 units a day at $200 each -- $20,000 dollars each day over 2 months of ramp.

“I can just screen out the bad units in production.”

It’s way more efficient to find the root cause to fix the issue than it is to try to screen out bad units at the end of the line. Treat the disease, not the symptoms. Each dollar to fix the issue in development is far cheaper than money spent in production to screen out units, particularly as you amass a bone pile of defective units that will have to be repaired or scrapped.

How to get ahead of your issues — and how Instrumental can help

A few days into EVT, and your issue pareto distribution might look like this.  Is it better to knock the #1 down to zero, or to try to fix multiple issues at once? The best practice is unclear. That #1 1 kHz frequency response issue with the speaker might be related to issue #3, speaker rub and buzz.  The fixes might be the same -- so it's potentially more efficient.  However, if the root causes are different, then splitting resources may result in a DVT that still has speaker issues.

A few days into EVT, and your issue pareto distribution might look like this.  Is it better to knock the #1 down to zero, or to try to fix multiple issues at once? The best practice is unclear. That #1 1 kHz frequency response issue with the speaker might be related to issue #3, speaker rub and buzz.  The fixes might be the same -- so it's potentially more efficient.  However, if the root causes are different, then splitting resources may result in a DVT that still has speaker issues.

In development, you may have a specific issue that affects 80% of units. Today, you may have to decide between spending your limited on-site time at the factory on squashing that one issue versus trying to split resources across the 80% issue as well as multiple smaller issues. There’s no clear right answer — both are not optimal.

Yet by choosing to address more issues in the first few builds, you can nip both the big and small issues early. It’s common to have to make tooling modifications after EVT to fix a big issue, and sometimes these can cost upwards of $25,000. If your big issue requires this, it may be that your small issues might too. By catching multiple issues early, you can fix them in one fell swoop, and for half the price. If given a choice, all reasonable engineers would love to find and fix their issues early, once and for all. Instrumental can help by amplifying your usefulness during your time in the factory, and enabling you to continue to investigate issues remotely, even after you’ve gone home.

We had a customer with power connectors soldered to the product’s main PCB. In drop testing, a high percentage of the connectors fell off, meaning the unit would no longer turn on. Normally, you’d have to tear down those units to find the root cause of the issue. This company didn’t want to do that because they needed the units for additional testing. So they disassembled one and saw what appeared to be a soldering issue. They were prepared to spend money, raw materials and days on fixing the soldering process.

The team consulted their Instrumental data record to virtually disassemble both passing and failing units. They saw the solder issue occurred at the same rate on both. It was a red herring.

But before that, this team consulted their Instrumental data record, where they were able to use images of the units being built up on their assembly line to virtually disassemble both passing and failing units — without access to the physical units. They saw the solder issue occurred at the same rate on both. It was a red herring.  

The team was able to quickly eliminate that theory and soon figured out the issue was a misplaced pin. Coming to that conclusion took less than an hour. With our new system, such root cause analysis can take as little as five minutes.

A Stitch In Time Saves Nine

The lesson here, we hope, is that effort invested in development product quality is pain saved in production. We believe there’s huge value in catching flaws early. Doing so means you won’t waste time on fixing them when they’re a full-blown catastrophe. It also allows you to focus on the critical path to shipping your first units to customers. Instrumental serves as your eyes on the line. Pinpoint the issue when it’s a 10-unit issue, not months later when it’s a 100-unit per day issue.