Choosing a Circuit Design Partner for a New Product

The failure modes of a product development project are predictable enough to be listed: the schedule slips, the design has to be redone after the prototype, and the finished design cannot be manufactured at the cost the business case assumed. All three are usually attributed to the technology. In practice they are usually the result of choosing the wrong development partner, or of choosing one without checking the things that decide whether the design reaches production.

Technical Coverage

A product involves hardware, firmware and mechanics, and the three interact. A team that covers only one of them, and coordinates the others through subcontracts, has to resolve every interface problem across a company boundary.

The interface between hardware and firmware is the one where the cost of that arrangement shows up. A sensor that is read with the wrong timing, a power sequence that the software assumes but the hardware does not guarantee, a communication protocol implemented twice with different assumptions: these are routine problems that a single team resolves in a day and two teams resolve over a week of emails. Where the design must be split, the split should follow a clean interface, and the hardware and firmware should stay on the same side of it.

Mechanics are a different case. A separate mechanical partner is common and workable, provided that the interface is defined early: the board outline, the connector positions, the height constraints and the mounting scheme. The mistake is to leave the mechanical definition until the electronics are finished, which is when a change is most expensive.

Experience in the Right Domain

Experience is not a single quantity. A team experienced in consumer products knows how to remove cost from a design; a team experienced in industrial or medical products knows how to add margin and how to document what was done.

The requirements that follow from the domain are not transferable. An industrial product may need to operate over a wide temperature range, tolerate electrical noise and survive a long service life. A medical product adds documentation and traceability obligations. A consumer product may be judged almost entirely on cost and time to market. Before choosing a circuit design partner, ask for products from the same domain and examine them: what is on the board, how it is constructed, how it was tested, and whether the design looks like the product it is in.

Manufacturability Has to Be Designed In

A design that cannot be built is not a design. The most common failure in this area is a board that passes its design rule check and then meets a process limit at the factory: a ball grid array that cannot be fanned out with the layer count assumed, an impedance requirement that the stack-up cannot meet, a copper weight that conflicts with the minimum trace width, a pad geometry that does not suit the assembly process.

The answer is a DFM review during the design rather than after it. That review belongs to the development team, because the decisions it questions are made in the layout. A team that runs it will typically engage the fabrication and assembly partners while the stack-up and the fanout are still being decided, which is the point at which a change costs nothing.

The practical test is to ask how the team handles a device that is close to the process limit. An interesting answer describes an early conversation with the factory. A weak answer describes a design rule check at the end.

Project Management and the Review Gates

A development project that has no defined stages cannot be managed, and a partner that does not propose stages is not planning to be managed.

The sequence that works is standard: a requirements review that fixes what the product must do, a schematic review that confirms the architecture and the component choices, a layout review that confirms the physical realisation, then prototype verification and a small batch before production. Each stage should produce a document and a decision, and the customer should be a party to the decision, because the cost of changing direction rises at each one. Each of them is a design review in the formal sense: a document to be read, a reviewer who is allowed to disagree, and a decision that is recorded before the next stage begins.

These are the project milestones that a contract should name. Their value is not administrative: a review gate is where a misunderstanding is found while it is still cheap, and the gate that catches the most is the layout review, where the design, the manufacturing rules and the mechanical constraints meet.

How to Evaluate a Partner

Portfolios and presentations are not useful evidence, because every team has one. Four questions produce better information.

Ask about a project that went wrong, and what the team learned from it. Every experienced team has one, and the way it describes the failure and the corrective action says more about its process than any successful case.

Ask who will do the work, and what proportion of it is done in-house. A team that outsources the layout, the firmware and the mechanical design is a project manager rather than a developer.

Ask what is delivered at the end, and in what form. A complete delivery includes the schematics, the layout data, the bill of materials, the fabrication and assembly data, the firmware source, the test procedure and the documentation of the design decisions. A delivery that stops at a working prototype leaves the customer unable to build, service or improve the product.

Ask what happens after the prototype. The first production build is where design problems surface, and a partner who is available for it is worth more than a lower quotation.

Commercial and Legal Structure

The ownership of the design and of the firmware source has to be settled before the work starts, not after. So does the treatment of any third-party library, reference design or tool licence used in the work. Confidentiality is the other item: a partner working for several customers in the same market should be able to describe how the separation is maintained.

The cost structure is worth examining for the same reason. A quotation that covers the development and nothing else is not comparable with one that includes the prototype build, the test development and support for the first production run.

Where the development partner is part of the same organisation as the manufacturing and assembly operations, those last items stop being negotiations. Our process starts with the requirements and the data package review, the design work runs through design and layout, and the first build is handled by our turnkey PCB assembly team, which means the assumptions made in the design are the ones the factory works to.

FAQ

Should the development partner also build the product? Not necessarily, but they should be involved in the first build, because that is where design problems appear.

What is the most important review gate? The layout review, because it is where the design, the manufacturing rules and the mechanical constraints meet.

What is a warning sign in a proposal? A schedule with no review gates, or a schedule in which the prototype appears without any earlier decision point.