The Question Behind the Question

Founders ask this because they fear two opposite failures. Write the spec themselves and they may specify something unbuildable, over-constrained, or three times more expensive than it needed to be. Hand it entirely to the engineering firm and they may pay for a product that meets the document and misses the market.

The honest answer is that neither party writes it alone. The customer owns what the product must do and for whom. The engineering team owns how that translates into numbers a test can check. The document that results is a joint artifact, and the projects that go badly are almost always the ones where somebody skipped their half.

What Belongs in the Document

A requirements specification for a physical product covers more ground than software people expect. At minimum:

  • Purpose and user. Who uses this, in what setting, with what training, and what job it replaces.
  • Functional requirements. What the product does, stated as behaviors rather than implementations.
  • Performance requirements. Numbers with units and tolerances: runtime, throughput, accuracy, force, temperature range, cycle life.
  • Physical constraints. Maximum envelope, weight, mounting interfaces, port locations, anything determined by where it has to fit.
  • Environment. Operating and storage temperature, humidity, ingress protection, shock and vibration, chemical exposure, UV.
  • Regulatory and standards. FCC, UL, FDA classification, CPSIA, ASTM or IEC standards that apply, and the target markets that drive them.
  • Cost and volume targets. Target landed unit cost at a stated annual volume. Without this, engineers optimize for something else.
  • Interfaces. Connectors, protocols, app, cloud, consumables, accessories.
  • Explicit non-goals. What version one deliberately does not do. This section prevents more scope creep than any other.

Most of this structure carries over from the software world, but the sections that matter most are the physical ones. A fuller template is in how to write a product requirements document.

How the Work Actually Splits

What only you can supply. The problem being solved, the user and the buying process, the competitive products you are measured against, the price the market will bear, the geographies you intend to sell in, the launch window and why it matters, and your tolerance for risk. Nobody can research their way to these on your behalf, and an engineering firm that claims otherwise is guessing.

What the engineering side supplies. Turning "it should last all day" into a battery capacity target given a measured duty cycle. Flagging that your 3 mm wall in that material will not survive the drop you described. Telling you that your accuracy target needs a sensor costing more than your entire target BOM. Identifying which standards apply and what certification will cost. Proposing two or three architectures and what each implies for tooling and lead time.

What you do together. Trading requirements against each other. Almost every specification contains an internal contradiction, usually between size, runtime, cost, and durability. The requirements phase is where those get resolved deliberately rather than by whichever engineer hits the conflict first at midnight.

Practically, the best pattern is a paid requirements phase of two to five weeks that produces the document as a deliverable. Expect to spend somewhere between $6,000 and $25,000 depending on complexity. It is the cheapest phase in the program and the one with the highest leverage on total cost. Firms that will do this as a standalone engagement are discussed in hiring a firm for one phase.

Writing a Requirement That Can Be Tested

The test for a good requirement is simple: could two engineers who have never met independently agree on whether the product passes? Compare these pairs.

Weak: the device should be waterproof. Testable: the device shall meet IPX7 per IEC 60529, verified by immersion at 1 m for 30 minutes with no ingress and full function afterward. The difference is not pedantry; the second version tells the mechanical engineer which sealing approach to price, and the standards involved are unpacked in IP ratings explained.

Weak: the battery should last a long time. Testable: the device shall operate for at least 14 hours at 77 F (25 C) on a full charge, at the duty cycle in Appendix A, measured across five units after a 300-cycle life test. Weak: the interface should be intuitive. Testable: eight of ten first-time users, given no instruction, shall complete pairing in under 90 seconds.

Every requirement gets an identifier, a priority, and a verification method: inspection, analysis, demonstration, or test. That last column is what later becomes your verification plan, and the distinction between proving you built it right and proving you built the right thing is covered in verification versus validation. For visual and experiential aspects that resist numbers, a separate design brief with reference imagery does the job better than prose.

When Requirements Change Mid-Project

They will. A competitor launches, a component goes end of life, a user test invalidates an assumption. The problem is not change, it is undocumented change, which is how a fixed-price project turns into an argument.

Baseline the document formally at the end of the requirements phase and put every subsequent change through a written change request that states the impact on cost, schedule, and other requirements. This costs an hour and saves weeks. The mechanics are the same as the engineering change order process used after release, and how disruptive changes are depends heavily on your contract structure, which is why fixed price versus time and materials is worth settling before you sign.

A Practical Starting Point

If you cannot yet afford a formal phase, write three pages yourself: what the product does, who buys it and why, and the ten numbers you believe matter with your best guess for each. Mark every guess as a guess. That produces a far cheaper first meeting than arriving with nothing or with fifty pages of unverified assumptions.

Turn Your Concept Into a Buildable Spec

Projects House runs requirements phases as standalone engagements, producing a baselined, testable specification you can take to any engineering firm, including ours. Send us what you have through our contact form and we will tell you what is missing.