Your Hardware Company Doesn't Have a PLM Problem. It Has a Headcount Problem.

Article 1 of 3: Buying engineering tools for the company you're becoming

Last month I talked to a corporate tooling lead at a drone manufacturer. Sharp guy — ERP and automation background, recently hired to modernize the software stack. His company is scaling from 250 people to 600 in under two years.

When I asked about his products, he almost apologized for them.

"Our BOMs are like 100 lines. We're not building anything complex. So I don't want to over-buy — no Teamcenter, no Enovia."

I hear a version of this constantly, and I want to unpack why it's the wrong frame — because it leads good buyers to under-buy in exactly the dimension that's about to hurt them.

Product complexity vs. organizational complexity

The PLM industry has trained everyone to size their tooling to their product. Complex product, big PLM. Simple product, spreadsheets and a shared drive. It's an intuitive heuristic, and it worked fine for thirty years.

But it measures the wrong variable.

The cost of coordination in a hardware company doesn't scale with BOM lines. It scales with the number of people who can change something multiplied by the number of people affected when they do. A 100-line BOM touched by 15 engineers across mechanical, electrical, and firmware generates more reconciliation work than a 5,000-line BOM maintained by three people who sit next to each other.

At 250 people, that drone company runs on spreadsheets and it mostly works — because the coordination graph is still small enough to fit in a few senior engineers' heads. Someone changes a mounting hole, and the person who needs to know sits ten feet away.

At 600 people, that graph doesn't fit in anyone's head. The senior engineers who used to be the coordination layer are now managers, or they've been diluted by 350 new hires who don't know that changing this connector footprint breaks that enclosure. The spreadsheet doesn't fail loudly. It fails through a slow accumulation of "wait, which rev is this?" and prototypes that come back wrong for reasons nobody can reconstruct.

The product stayed simple. The organization didn't.

Why this misdiagnosis matters

If you believe your problem is product complexity, you shop for a vault: somewhere to store CAD files, manage revisions, run approval workflows. You size it small because your product is small, and you optimize for cost per seat.

If you understand your problem is organizational, you shop for a coordination layer: something that knows what changed, who it affects, and tells them — before the design review, before the prototype run, before the new hire ships a board that doesn't fit the enclosure.

These are different purchases. A vault stores decisions. A coordination layer propagates them.

The failure mode of the first frame is that you buy (or keep) something that faithfully stores every revision while your engineers spend four-hour design reviews manually reconstructing what changed and why. The data was never lost. The design intent was — it lived in the heads of people who now spend their days interviewing candidates.

The 250-to-600 test

Here's the question I'd ask instead of "how complex is our product": when we double headcount, what happens to the time between "someone changes something" and "everyone affected knows"?

If the answer is "it depends on whether the right people happen to talk," you have a scaling problem regardless of how simple your BOM is. Every new hire makes the graph bigger and the hallway-knowledge network relatively smaller.

Spreadsheets don't have a change-propagation mechanism. Neither, honestly, do most legacy PLMs — they have approval workflows, which tell you a change was authorized, not what it breaks downstream. Propagation is the thing you're actually buying when you modernize this part of the stack. Everything else is storage.

What to do with this

If you're the person choosing tools at a scaling hardware company, resist sizing the decision to today's BOM. Size it to next year's org chart. Ask vendors — including us — not "can you store our data" but "when a mechanical engineer moves a hole, how does the firmware engineer find out, and how long does it take?"

The companies that get this right treat change propagation as infrastructure, the same way software teams treat CI/CD. The ones that get it wrong discover the problem at 600 people, when the fix requires migrating two years of spreadsheet archaeology.

Next in this series: why the "safe" answer to this problem — the 40-year-old incumbent PLM — has quietly become the risky one, and how to think about domain depth versus adaptability when the ground is shifting this fast.

---

I'm Serge Kadjo, founder of ProductFlo — a coordination layer that connects mechanical, electrical, and firmware engineering so changes propagate instead of getting lost. I've spent 10+ years building hardware, from consumer robotics to medical wearables, and I write about the intersection of AI and hardware engineering.