The stretch between a prototype that works and a line that holds at volume is where most hardware startups lose months they didn't budget for. That gap is the work I do.
Over a decade in hardware manufacturing, I've built a repeatable way to get a program from a working prototype to a line that holds at scale. Five phases, run in order.
Understand before changing. I walk the line, follow the material, and talk to the operators — they know where the real problems are long before the dashboards do. Then I establish a real baseline across safety, quality, delivery, equipment, cost, and process stability.
When reality and the documentation don't match, I trust reality.
Separate the pile into workstreams: design, process, supplier, operator. Contain first to protect the line, then diagnose without production pressure. Prioritize by impact and leverage — not by ticket count.
One accountable owner per issue, support shared. I build the operating mechanisms so the work keeps moving whether or not I'm in the room. Ambiguity creates delays; clarity creates momentum.
A weekly cadence that surfaces blockers and assigns forward action every time. I report status, risks, and decisions — communicated at the altitude of the audience. Nothing disappears into meeting notes.
Prove the fix at production scale, not pilot scale. Standardize it, document it, and leave the system stronger than I found it. If the line depends on me after I'm gone, the job isn't finished.
On one vehicle program during launch, rework was quietly eating the ramp. Throughput was stuck, the schedule was slipping, and every function had a different theory about why.
I logged the failures before touching anything, separated design problems from process problems, and rebalanced the line — redistributing work across stations by cycle time and standing up dedicated rework where the data pointed.
The line went from firefighting to holding at volume. The fix didn't come from any one function. It came from getting the right people working the right list, in the right order.
On a consumer electronics program, failures started appearing across multiple builds at rates that threatened supply — and they looked random. Instead of chasing each one, I hunted for what they secretly shared, traced the correlation to a single supplier source, and contained it while the line kept running.
Root cause landed within days, not months — because the first move was finding the pattern, not firefighting the symptoms.
I'm Jonathan Pinkard. I've spent over a decade launching hardware programs and ramping factory lines across automotive, consumer electronics, and robotics.
My work sits where design, manufacturing, and the factory floor meet — launching lines, ramping new products, and finding the reason a program that looks fine on paper won't hold at scale. I've learned that most production problems aren't engineering problems. They're program problems: unclear ownership, decisions made too late, and no feedback loop between the people designing the product and the people building it.
I work independently now, with a small number of hardware teams heading into the hardest stretch of their program. Based in the San Francisco Bay Area — and at home on a factory floor anywhere.
NPI planning and execution. EVT/DVT/PVT builds and readiness. Getting a first line to hold at volume.
Throughput, yield, and rework reduction on an existing line that isn't hitting its numbers.
Design-for-manufacturability alignment between engineering and the floor, and clean transfer to your team.
Typical engagements run 3–6 months at 1–2 days a week, fractional or project-based. I take on a small number of teams at a time.
If you're heading into ramp, or a line isn't holding, let's talk. 30 minutes. Bring your ramp plan or your problem — you'll leave with my read on it either way, whether or not we work together.
Want to check me out first? My full background is on LinkedIn →