Why the 'Design for Manufacturing' Mindset Kills Companies

When we launched the Tesla Model S, the clear objective was to not just build the best electric car, but to build the best car overall, bar none. The design and shape of the car was beautiful. The car had unparalleled performance and customer experience. The product was a category-defining achievement that would establish the Tesla brand and cement its place in history.

Yet in many ways, the attitude of the company was to design a great product first and worry about the manufacturing later.

I still have very clear memories of a conversation with Elon in the Tesla design studio where he stated, “The design happens here, and then your job is to figure out how to build it. End of story.”

The result was a car that was incredibly difficult to build, a supply chain that was fragile, a slow ramp of production, and significant quality issues. It nearly bankrupted Tesla.

That’s why it’s worth acknowledging that Tesla was able to launch the car nonetheless because it had exceptional engineering, supply chain, quality, and manufacturing teams. All too often I hear people anchor on the surface-level observation of “Well, this worked for Tesla, so it will work here,” but the reality is far more nuanced. The company was made up of veterans of building things in multiple industries, so most knew the failure mode of this path. They took it upon themselves to push for rapid early subsystem testing, concurrent engineering and manufacturing virtual builds, and deep engagement with suppliers. Hidden behind the headline and chaos was the real work that allowed Tesla to launch this car.

The way a hardware company allocates resources is the best indicator of whether it will survive its ramp. There are two patterns of how teams allocate resources over time.

Pattern A — The standard curve. Small design team during the design phase. Manufacturing engineering staffs up later, when the product is "ready to industrialize." A modest pilot build followed by a steep staffing ramp during production launch. Yet, the curve doesn't actually go up cleanly, because the team is now discovering all the manufacturability issues that should have been caught a year earlier. Those issues require design changes. Design changes ripple through tooling, supplier qualifications, software, test fixtures. Each change pushes the ramp out by weeks or months. Resources spike in panic. Time-to-volume stretches. Working capital balloons because you've ordered material for a ramp that isn't happening.

Pattern B — The front-loaded curve. Larger team earlier. Product engineers, manufacturing engineers, suppliers, and process specialists working in parallel during the design phase. Multiple module-level prototypes and subsystem builds long before the product is "complete." Simulated builds on pilot lines that are intentionally rough with multiple iterations baked into the schedule. This curve takes longer to reach Start of Production. But once it reaches SOP, the ramp curve is much steeper. Total resources consumed are lower, total time to volume is shorter, and quality is dramatically better.

The thing founders often miss is your cash burn is the integral under the curve, not the height of it, and the post-SOP cash — materials, tooling, plant, warranty — is the most expensive cash you'll ever spend. A ramp that drags out for 18 months because you're redesigning during production consumes far more capital than a slightly longer pre-SOP phase. And in physical industries, quality kills companies: Field failures destroy customer trust, drive expensive recalls, blow up your warranty reserves, and starve you of the cash you need to keep ramping. Pattern B teams ship better products on day one because they iterated through the failure modes in subsystem builds, not in customers' hands.

There's a finding from Boothroyd-Dewhurst (the team that essentially codified the DFMA discipline in the 1980s) that you should etch into your wall:

Roughly 70–80% of a product's lifetime manufacturing cost is locked in during design.

Not during sourcing, not during process engineering, not during ramp.

Once a drawing is released and tooling is ordered, your degrees of freedom collapse. You can negotiate suppliers down 10%. You can squeeze cycle time 20%. You can chase yield improvements for years. None of it touches the structural cost decisions that were made when an engineer chose a geometry, a material, a tolerance, an interface.

This is also why the mindset of "Let's launch and improve costs later" is a lie. The cost of a product at maturity is largely determined before the first one ships. Bad designs don't get cheap. They get less expensive to manufacture badly, which is not the same thing.

Here is a heuristic I use to evaluate hardware engineering teams: Show me the bill of materials. If it has fewer parts than I expected for a product of that capability, the team is good. If it has more parts than I expected, the team is average — even if every part works. Average engineers solve problems by adding components. Great engineers solve problems by removing them.

Inherent simplicity in a design is not aesthetic — it is the most powerful manufacturing lever you have. Every part you don't have is a part you don't tool, source, qualify, inventory, inspect, assemble, or ship as a spare. Every interface you don't have is a tolerance stack you don't accumulate, a fastener you don't torque, a leak path you don't seal.

My partner at Eclipse, Charly Mwangi, likes to say the "best part is no part". Here is a five-step approach that I learned from him and others during painful days at Tesla:

1. Make the requirements less dumb. Every requirement comes from a person, and people are wrong. Push back hard.
2. Delete the part or process. If you don't have to add things back later, you didn't delete enough.
3. Simplify and optimize. But only after step two — there is no point optimizing a thing that shouldn't exist.
4. Accelerate cycle time. But only after step three.
5. Automate. Last. Always last.

Most teams invert this. They start at step five — designing a beautiful automated line for a part that should have been deleted. By the time they realize the part wasn't necessary, they've spent $20M on tooling and a year of program time.

A great engineer ships, and ships in volume. That's the goal. Not elegance, not novelty, not a cool render, but volume. If you talk to engineers and they're proud of the part count, run.

The Wrong Reaction: "Just Use Off-the-Shelf"

When founders hear "Design for manufacturing matters," some of them overcorrect. They start designing within the envelope of what their contract manufacturer is comfortable with: Standard components, conservative tolerances, well-trodden processes. Nothing that pushes the boundary.

This is also wrong, and for industrial-scale companies it is fatal.

If you are not pushing the boundary somewhere — in materials, in geometry, in process, in integration — you have no defensible product. You are just shipping someone else's reference design.

The companies that win in physical industries are the ones that figured out how to manufacture something nobody else could manufacture, at a cost nobody else could match. Tesla wasn't a great car company because it used standard automotive parts. Cerebras is not setting performance records because they used existing semiconductor packaging approaches. 

The right framing is not "Don't push manufacturing." It is “Know exactly where you're pushing it, and have the people who can innovate on the manufacturing process embedded from day one.”

This is the move most teams miss. They hire incredible product engineers. They wait two years to hire a manufacturing leader. By then, the design is fixed and the manufacturing innovation has to happen around the design instead of with it. The person who could have invented a better process is now reduced to making the existing process work.

If your product has three places where you're pushing manufacturing physics — let's say a novel weld, a precision optical alignment, and a thermal interface — then on Day One you should have someone whose entire job is to invent the manufacturing process for each of those things, sitting at the same table, on the same whiteboard, with the same KPIs as the engineer designing them. Not in the next building. Not in a different functional org.

This approach is what enabled Cerebras to be the first to deliver on the long-held dream of wafer-scale-integration, and eventually, grow into the public company it is today.

I get asked: "What does this concretely mean? What does the team actually do?" Here are some specifics that separate the teams that get this right from the teams that pretend to:

Co-located, co-staffed teams from concept. The product engineer, the manufacturing engineer, the test engineer, and a process specialist for whatever the hardest manufacturing step is all sit together. They share a schedule and are one team.

Simulated builds before real builds. Before any production tooling is cut, the team walks through every assembly step on paper, in simulation, and on rough fixtures. Every interface, every fastener, every torque, every test point. The goal is to find every "Wait, how does this even get assembled?" question while it still costs nothing to fix.

Module and subsystem builds early — and often. Don't wait to integrate the whole product before you find out the welded joint fails at temperature, or the cable harness can't be installed without a dual-jointed technician. Build the hard subsystems first, by themselves, and beat them up.

Suppliers in the room during design. Not for "supplier feedback" at PDR. In the room. Looking at the screen. Telling you "the radius you drew there is going to cost us a custom tool, but if you make it 0.5mm bigger we can run it on a standard one." That conversation is worth tens of millions of dollars. It can only happen before the design freezes.

Multiple iterations baked into the schedule. No design works on the first shot. Anyone who tells you their design will be right the first time is either lying or has never built anything at volume.

The question is not "Will we iterate?" but "How many iterations did we plan for, and how fast can we cycle?"

Get out of CAD. Get hands on hardware.

There is a particular kind of engineering culture that loves living in CAD. The renders are beautiful, the models are clean, and the version history is satisfying. The team has elaborate review meetings where they spin parts around in 3D. Months go by and the design is not done, there is always one more refinement.

Meanwhile, the company has built nothing.

The teams that ship are the teams that get parts in their hands as soon as humanly possible; even if those parts are wrong, even if they're crude, even if they're embarrassingly far from the final design. Because the moment you hold the thing, you learn ten things you would never have learned in CAD. The fastener clears the wall by 1mm, fine in CAD, impossible to actually torque with a real wrench. The seal looks great in section view, yet terrible when a real human has to install it. The bracket is structurally adequate, yet hits the harness when you actually route it.

The job of the design team is not to produce drawings. It is to produce a product. Drawings are a step; they are not the goal.

I tell founders: I don't want to see your CAD model. I want to see your subsystem build, see what's broken. I want to see the parts that didn't fit and the version history of the part that's been redesigned six times. That's a team that is going to make it.

When I went to visit Arc Boats when we were considering leading the Series A, it was clear they understood this approach. The number of fast iterations and tests they were performing was truly eye-watering. At that moment I knew they would succeed. A team whose proudest artifact is their CAD model is a team that has not yet started.

Stage Gate processes get a bad rap in startup circles because they're associated with corporate slowness. That's a misuse of the tool. A well-designed stage gate is not about bureaucracy. It is about forcing each gate to certify that manufacturing reality has been integrated into the design at that level of maturity.

A version that actually works for hardware:

Gate 0 — Concept. Does the architecture make manufacturing sense? Have we identified the 3–5 places where we are pushing manufacturing physics? Do we have an owner for each? Exit criteria: a manufacturing risk register that names each frontier and an iteration plan for each.

Gate 1 — Subsystem feasibility. Have we built and broken the hardest subsystems standalone? Exit criteria: prototypes of each high-risk module, with test data, not slides.

Gate 2 — Integration. Does the integrated product assemble cleanly? Have we done a simulated build with no missing parts, no impossible operations? Are key suppliers committed and in the loop? Has initial manufacturing process capability on critical nodes been achieved? Exit criteria: a successful pilot build off of representative tooling, not soft tooling.

Gate 3 — Pilot. Are we hitting yield, cycle-time, and quality targets at pilot scale, with the same equipment and same operators we'll have at SOP? Exit criteria: a real number for first-pass yield. Not a forecast. An actual number from real builds.

Gate 4 — SOP. Are we ramping on a curve that the business case can absorb? Are we still finding design issues, or are we finding process issues? (The first means you're not ready. The second means you are.)

The discipline here is that every gate is owned jointly by design and manufacturing. There is no "design gate" and "manufacturing gate." A design that can't pass a manufacturing review is not done. A manufacturing process that can't accommodate the design is not done. Either side can stop the gate.

If your stage gates are checkboxes that the design team fills out and then hands to manufacturing, congratulations, you have invented Pattern A — single-functional ownership of the gate is exactly what produces the single-functional staffing curve. You will spend the next two years fighting for your life.

I want to close on the point that gets misread the most often, because it matters.

Founders sometimes hear all this and conclude that I'm asking them to slow down — to add gates, add reviews, add processes, to be more careful, to do less in parallel. That is exactly the opposite of what works.

The discipline is not about slowing down design. It is about pulling manufacturing forward.

How can I build a hard subsystem this quarter instead of next year? How can I get a real part in a real test fixture by next month? How can I have a supplier on-site three weeks from now instead of after the design review? How can I run a simulated build before the design is done, just to find the obvious problems? How can I cut a piece of soft tooling for the worst part now, even if the rest of the product isn't ready?

The right speed metric is not "weeks to design release." It is "weeks to first hardware learning." The team that gets to its first painful, real, hands-on lesson the fastest is the team that wins. The team that defends its CAD model the longest is the team that dies.

If I had to summarize the entire Industrial Scaling Playbook in one sentence, it would be this: The job is not to design and then build. The job is to design by building, faster than anyone else.

That’s why Design for Manufacturability, as a concept, should be dead. In its place is harder, more humbling, more chaotic, and far more powerful: A single engineering culture that treats the product and the way it gets made as the same problem, attacked at the same time, by the same people, from day one.

The companies that figure this out get to ship. The ones that don't get to write very expensive post-mortems.