Better engineering helps. Better suppliers help. Better tooling and better factories help too.
But eventually, the way a company communicates, makes decisions and owns problems ends up inside the product.
You can have a strong mechanical engineer, a capable electronics team and access to some of the best suppliers in Shenzhen, and still get the product wrong. Not because the technical capabilities were missing, but because somebody knew the design was not ready and stayed quiet. Because a supplier issue sat in a spreadsheet for two weeks before anybody acted on it. Because everyone knew the target cost was unrealistic, but tooling was released anyway. Because a quality issue technically belonged to Supplier B, so Supplier A stopped caring.
Hardware has a funny way of turning company behaviour into physical consequences.
Poor communication becomes delay. Unclear ownership becomes rework. Bad incentives become bad supplier decisions. A problem nobody wants to discuss eventually becomes tooling steel, committed inventory, yield loss or a few thousand products that now need to be fixed.
That is why Making Better Products is not only an engineering problem.
You need a better company too.
Not “better” in the corporate-values-on-a-wall sense. Better at seeing reality, saying what needs to be said, solving problems instead of forwarding them, owning the complete manufacturing result and remembering whose business the product ultimately needs to work for.
In hardware, company culture eventually becomes product behaviour.
Every hardware NPI program generates enough documentation to bury a small team: CAD revisions, BOMs, schedules, DFM reports, tooling updates, quality data, inspection reports, meeting minutes and production pictures.
All of it is useful. None of it automatically makes the project transparent.
A dashboard can tell you that PVT reached 90% First Pass Yield. What it may not tell you is that an operator is manually adjusting the same component on every second unit to get there.
Both can technically be true.
Only one tells you whether you actually have a controlled manufacturing process.
For us, transparency means giving the people making decisions access to the reality behind the status report: project progress, technical issues, open risks, production data, design deliverables, supplier problems and what is actually happening on the factory floor.
In manufacturing, transparency has artifacts. FPY data, NOK records, golden samples, revision-controlled drawings, inspection reports, work instructions, engineering change records and traceability all make the underlying reality visible.
The point is not to generate more documentation.
The point is to make reality visible early enough to act on it.
This is why we operate an Open Door Factory policy at Supernova.
If we are building your product, come to Shenzhen. Meet the engineers, review the tooling, visit the relevant suppliers and stand next to the production line.
Not because watching an injection-moulding machine automatically makes someone a manufacturing expert. The value comes from putting the right people next to the real process.
You can spend three meetings discussing an assembly tolerance in CAD. Put the mechanical engineer next to the operator for ten minutes and sometimes the discussion becomes very simple.
The part may technically pass tolerance, but if the operator needs a special wrist movement to assemble it consistently, you do not have a robust assembly process.
The drawing may say PASS. Production is telling you something else.
That is useful information.
When we walk a production line, the good units only tell half the story. The NOK units often tell you much more.
Where do they go? Are they quarantined or simply pushed aside? Are they reworked? Are the failures recorded? Does the same defect keep appearing three builds later? Where is the golden sample? Is the operator following the released work instruction, or has the real process evolved into something nobody documented? Is the test fixture actually validating the requirement everyone agreed on?
Those details tell you whether you are looking at a controlled manufacturing process or experienced operators compensating for problems upstream.
The factory does not need to look perfect. It needs to be transparent enough for the right people to understand what is really happening.
Of course, Open Door does not mean Open Everything. Other customers' IP remains protected. NDAs matter. Confidential processes remain confidential.
But when it comes to your own product, nothing important about your manufacturing setup should need to be hidden from you.
That is transparency.
Not another green dashboard.
Hardware teams like progress.
Tooling released. Components ordered. Pilot build scheduled. Certification booked. Boxes checked.
But moving forward is only useful when the decisions underneath are actually ready to move forward too.
The design is almost frozen, so tooling gets released. The target cost is clearly becoming difficult, but everybody assumes sourcing will somehow find another few dollars later. PVT yield is below target, but mass-production components have already been ordered.
Nobody wants to be the person saying no go.
So the program keeps moving. It feels faster, until the unresolved decision comes back with a larger invoice attached.
This is why EVT, DVT and PVT gates matter. But the acronyms themselves do nothing. A gate is only useful if the team is genuinely willing to say the product is not ready to pass it.
Before tooling, changing a mechanical feature may be an engineering decision. After tooling, it may mean modifying steel. After certification, the same change may trigger another validation loop. After 50,000 components have been purchased, it becomes an inventory problem too.
The problem did not suddenly get worse. You just waited until it became expensive.
That is why direct communication matters in NPI.
If the design is not ready to freeze, say it. If the architecture cannot hit the target cost, say it. If DVT has not validated the requirement, say it. If PVT is not stable enough to ramp, say it. If the launch schedule no longer reflects reality, say it.
Direct communication is not about being confrontational. It is about refusing to let politeness become a project risk.
It also means setting accurate expectations with customers. Hardware development will produce bad news occasionally. Pretending otherwise does not make the project healthier; it just means the customer discovers reality later.
And later is almost always more expensive.
There is also a difference between communicating a problem and simply forwarding it.
“FPY is 82%” is information, but it is not yet very useful.
What failed? What does the Pareto look like? Which failure modes account for most of the missing yield? Are we looking at product design, incoming variation, tooling, fixture design, process control, test limits or operator method? What happens before the next build?
Bad news should come with enough context for the team to make a decision.
Otherwise, you are not really communicating the problem. You are just moving it to somebody else's inbox.
We have a line internally:
There are no problems, only solutions.
Obviously there are problems. This is hardware.
Tooling needs correction. Components go EOL. Suppliers miss specifications. Certification tests fail. DVT exposes reliability issues. PVT reveals process problems nobody saw coming.
The phrase does not mean pretending problems do not exist. It means finding the problem is not where our job ends.
Customers do not work with an NPI partner because they expect hardware development to be magically problem-free.
They work with one because when something goes wrong, somebody capable is expected to understand it and get the program moving again.
That distinction matters.
Take an 82% FPY result.
The number itself is useful for about thirty seconds. Then I want to see the Pareto.
If two failure modes explain most of the yield loss, start there.
Maybe the enclosure geometry needs another engineering change. Maybe the fixture allows too much variation. Maybe an upstream supplier process is drifting. Maybe the work instruction makes sense in a document but does not survive 500 repetitions on a real production line. Maybe the test limit itself is wrong.
Now we have something we can work with.
Manufacturing already has disciplines for this: Pareto analysis, 5 Why, 8D, CAPA and Root Cause Analysis. The terminology varies depending on the company and the problem, but the logic is remarkably consistent.
Contain the issue, understand the failure mode, find the root cause, define corrective action, assign an owner and verify that the correction actually worked.
What you do not want is to turn every engineering problem into more inspection.
You can add inspectors forever, but if the root cause remains inside the product or process, the defect will keep trying to come back.
More QC is not always more quality.
Sometimes it is just a more expensive way of living with the same problem.
There is rarely one magical solution. There are options, and every option has consequences for cost, lead time, performance, quality and risk.
Sometimes the technically cleanest solution destroys the launch schedule. Sometimes the fastest solution adds too much unit cost. Sometimes the correct decision is to delay ramp rather than release a process that is not stable.
Being solution-oriented means understanding those trade-offs, recommending a path and then owning the execution.
A root cause. Options. A recommendation. An owner.
Then fix it.
Most custom hardware products are not made by one factory.
“The factory” is convenient shorthand. Reality usually looks more like a PCBA supplier, an injection-moulding supplier, another shop doing surface finishing, specialist suppliers for displays, batteries, custom cables, packaging and machined parts, and then a final assembly operation where everything converges for testing and inspection.
That means where a defect appears and where it was created can be two very different places.
That distinction matters.
Take a molded enclosure drifting toward one side of tolerance.
The molding supplier measures it and calls it PASS.
Then it reaches final assembly. Operators need more force to close the product. Cycle time increases. Cosmetic marks start appearing. Rework goes up.
Assembly yield is now falling because of something created several processes upstream.
Blaming the assembly factory solves nothing. You need to work backwards.
Is the component really within the released specification? Has the moulding process drifted? Is the tolerance stack itself too aggressive? Did engineering leave enough manufacturing margin? Was a deviation accepted upstream without understanding its downstream effect?
This is supplier quality in the real world.
A PASS result at one supplier does not guarantee a good final product.
This is why somebody needs to own the interfaces.
Not simply schedule meetings between suppliers. Not just chase delivery dates.
Own the production result.
A serious NPI partner has to connect mechanical design, electronics, tooling, supplier quality, assembly, testing and final QC into one product system.
That means deviation management, incoming quality, engineering change control, tolerance stack-up, supplier corrective actions, process capability and cross-supplier problem solving.
You do not manage a supply chain by making sure every supplier can individually explain why their part technically passed.
You manage the interfaces between them.
Otherwise, you end up with five suppliers who can each explain why the problem is not technically theirs and one customer who still has a product that does not work.
Very collaborative.
Not particularly useful.
There is another side to being a better company that becomes much harder when there is a purchase order sitting on the table.
We should not sell customers things they do not need.
It sounds obvious. In practice, incentives have a way of making obvious things less obvious.
Sometimes the answer to a hardware problem is more engineering. Sometimes it is not.
Maybe an existing design block already solves most of the requirement and saves three months of unnecessary development. Maybe the impressive new feature belongs in Gen 2. Maybe the product needs more market validation before serious money gets committed to NPI. Maybe another supplier genuinely owns the better process for one part of the program.
Maybe we are simply not the right partner.
Fine.
Customer success needs to come first, because if the product and the business around it do not succeed, no amount of NRE invoiced along the way turns that into a successful partnership.
This matters particularly early in NPI.
A founder can arrive with a working prototype, a long feature list and a budget ready to spend. That does not automatically mean the responsible next step is tooling.
Maybe the market promise is still unclear. Maybe the target cost is incompatible with the architecture. Maybe the volume assumptions do not justify the proposed tooling strategy. Maybe the use case can be served with much less engineering.
Starting development is easy.
Knowing what not to develop is often more valuable.
Good engineering starts with the customer's actual need and works backwards into the technology, not the other way around.
The objective of the first discussion should therefore not be finding the shortest route to an RFQ. It should be establishing whether the product, business case and manufacturing setup make sense together.
The same principle applies once engineering begins.
An $8 component improvement may completely solve a reliability problem.
If the product sells for $2,000, the decision may be obvious. If the ex-factory target needs to stay below $40 for the channel economics to work, you have a very different problem.
Same engineering solution.
Completely different business answer.
This is why design-to-cost and value engineering require more than a BOM spreadsheet. Engineering needs to understand the commercial constraints: target cost, expected volume, channel margin, NRE budget, tooling investment, launch timing, product positioning and reliability requirements.
A technically excellent product that destroys the margin structure is not a successful product.
The same applies to production volume.
A 5,000-unit first order could mean two completely different things. Maybe 5,000 units is the lifetime volume. Or maybe it is the first step toward 500,000.
Those products should not necessarily be industrialized the same way.
The right tooling investment changes. Automation changes. Component sourcing changes. Test strategy changes. Supplier selection changes. Quality control changes. The manufacturing architecture itself may change.
You cannot expect an engineering team to optimize for constraints it is not allowed to see.
Give us the business constraints that affect the engineering decisions. We will give you the manufacturing reality behind them.
That is a much healthier partnership than both sides hiding information because they think opacity creates negotiating leverage.
Company culture can sound far removed from a production line.
It is not.
Transparency is the manufacturing team showing the real pilot result instead of polishing the dashboard before the customer sees it. Its artifacts are FPY data, NOK tracking, golden samples, inspection reports and traceability. The result is that problems become visible earlier.
Direct communication is the engineer raising the design risk before tooling instead of assuming somebody else will deal with it later. Its artifacts are honest design reviews, deviation approvals and EVT/DVT/PVT gate decisions. The result is that expensive mistakes get stopped earlier.
Being solution-oriented is arriving with root cause, options and a recommendation instead of forwarding the problem. Its artifacts are Pareto analysis, 8D, CAPA and corrective-action plans. The result is that problems actually disappear instead of being managed forever.
Ownership is fixing the supplier handoff rather than explaining whose fault the issue technically is. Its artifacts are supplier-quality controls, ECNs, tolerance reviews and cross-supplier problem solving. The result is that the complete product works, not just the individual parts.
Customer success means giving engineering the business constraints and recommending the solution that makes sense for the product, even when that means less engineering, a smaller PO or no project at all. Its artifacts are product requirements, target cost, design-to-cost, value engineering, volume assumptions and channel economics. The result is a product that can actually scale as a business.
Eventually, all of those behaviours become physical.
They become yield, cost, lead time, reliability, quality, time-to-market and margin.
Ultimately, they become the product somebody takes out of the box.
That is why Making Better Products is not only about engineering better products.
Better engineering obviously helps. So do better tools, better suppliers and better manufacturing processes. But behind all of them is a company making decisions.
And when reality inevitably stops matching the plan, the quality of those decisions matters enormously.
That is what Making Better Products by Being a Better Company means to us.
Not a nicer values page.
A way of operating.
And if you want to test the transparency part, come to Shenzhen.
Reach out to hello@sprnv.com.
Our doors are open.
.svg)
.svg)
.svg){kind=icon}
