Adam Savage once said that the only difference between screwing around and science is writing it down. He said it on MythBusters, clipboard in hand, deadpan. The audience laughed. Hardware founders should print it out and tape it above their desks.
Because the same principle applies to engineering, and it applies to your company.
A prototype is just organized screwing around. It doesn't have to be repeatable, auditable, or transferable to anyone else. It just has to work once, well enough to prove a point. That's fine for a garage experiment. It's not fine for a company.
The moment you want to manufacture at scale, bring on a contract manufacturer, hire a second engineer, or raise a round, you cross a line. On one side of that line: things you built by feel. On the other: things you can hand to another person and have them reproduce exactly. The only thing separating those two sides is documentation.
This isn't a paperwork argument. It's an operations argument. Companies that document well move faster, not slower; they catch mistakes earlier, not later; and they hand things off cleanly instead of creating institutional knowledge that lives only in one engineer's head.
Here's the documentation your hardware team actually needs.
Bill of Materials
The BOM is the foundation. Every physical product is, at its core, a list of parts: what they are, where they come from, how many you need, and what they cost. Without a managed BOM, you're guessing at your own product.
A well-maintained bill of materials isn't just a spreadsheet. It's a living record that connects your design to your supply chain. As your product evolves, your BOM needs to evolve with it, versioned and controlled, not updated by whoever happened to touch the file last. Good BOM management software makes this automatic; a shared Google Sheet makes it a slow disaster.
Worth noting: the BOM your engineers design against (the eBOM) and the BOM your factory builds from (the mBOM) are related but different documents. Conflating them is one of the most common, and most expensive, mistakes early-stage hardware teams make.
Engineering Change Orders
If the BOM is the foundation, the engineering change order (ECO) is the system that keeps it from crumbling.
Parts get discontinued. Tolerances get revised. A supplier falls through. A customer reports a field failure. Every one of those events should trigger a formal change process: what's changing, why it's changing, who approved it, and what downstream effects it has on manufacturing, documentation, and inventory.
Most early-stage hardware teams skip ECOs entirely. They make the change, update the BOM, and move on. This works until it doesn't, and when it stops working, it's genuinely painful: a production run built to the wrong spec, a CM quoting against an obsolete file, a compliance audit with no change history to present.
The ECO isn't bureaucracy for its own sake. It's the audit trail that proves your product is what you say it is.
Component and Part Specifications
Every component in your BOM should have a corresponding spec: the datasheet, the approved manufacturers list, the acceptable substitutes, and the critical parameters your engineers care about. This document is what protects you when a part goes end-of-life and your sourcing team needs to qualify a replacement without involving an engineer for three days.
Assembly Instructions
Tribal knowledge doesn't scale. If the only person who knows how to build your product is the person who designed it, you have a bottleneck, not a process. Assembly instructions — with step-by-step procedures, annotated diagrams, and torque specs — are what turn a one-of-a-kind build into a repeatable one.
This documentation pays off the moment you hand anything to a CM, a new hire, or a field technician.
Manufacturing Drawings and DFM Notes
Your CAD model is not a manufacturing document. Manufacturing drawings define tolerances, surface finishes, GD&T callouts, and material requirements in a format your factory can actually work from. Design for Manufacturability (DFM) notes capture the design intent your drawings don't: which features are flexible, where the real constraints are, and what trade-offs were made during design. Keeping these next to your BOM — rather than buried in someone's email thread with the CM — is what makes re-engagement fast.
Testing Documentation
A product isn't done when it works once. It's done when it passes a defined test, repeatably, with a written record. Test plans, acceptance criteria, and test results create the evidence chain that your product is safe, functional, and consistent across production runs. In regulated industries like medtech and defense, this isn't optional; it's the minimum bar for selling the product at all.
Installation and End-User Instructions
The product experience doesn't end at the factory gate. Customers need to install, configure, and troubleshoot. Good installation documentation reduces support burden, reduces returns, and signals to buyers that your company is professional. It's also a legal liability issue in some categories.
Compliance and Regulatory Documentation
Depending on your market, this means CE marking records, FCC authorization, FDA technical files, ITAR classification, or RoHS compliance declarations. Compliance documentation isn't generated once; it's maintained as the product changes. Which brings you back to the ECO. Everything is connected.
Revision History
Every document your team produces should have a version number and a change log. This sounds obvious and gets skipped constantly. Revision control is what lets you answer the question: what was the product on the date of this customer complaint? Without it, you're guessing.
The Tools Question
Most hardware teams under 30 people manage some version of this documentation stack in a combination of spreadsheets, shared drives, and Slack threads. It works, until someone leaves, a part changes, or a customer asks a hard question.
The right PLM tool doesn't just store these documents; it connects them. A change to a component flows through to the BOM. An approved ECO creates a revision record automatically. Your CM gets the current file, not the one from three months ago.
That's the difference between documentation as a burden and documentation as infrastructure.
Build the infrastructure. Write it down.
oroForge is PLM software built for hardware startups. If your team is managing BOMs in spreadsheets and change orders in Slack, see how it works at oroforge.com.