A product requirements document (PRD) for a physical product is a written definition of what the product must do, for whom, under what conditions, at what cost, and how each of those claims will be verified. It is not a description of how the product will be built — that is engineering's job. A good hardware PRD is short enough that people actually read it, specific enough that two engineers reading it independently would build compatible things, and testable enough that at the end of the project you can point at each line and say pass or fail. Writing one takes days. Skipping it costs months.

What a PRD actually is

Software teams write PRDs about features and user stories. Hardware teams need something stricter, because you cannot patch a mold. A physical-product PRD is the contract between the person who wants the product and the people building it, covering functional behavior, physical constraints, environment, regulatory scope, cost targets, and lifecycle expectations.

It is deliberately technology-neutral. "The device must run eight hours of continuous use on one charge" is a requirement. "The device must use a 5,000 mAh lithium polymer cell" is a design decision that belongs downstream, where the engineer can trade it against size, cost, and safety — the kind of decision an engineer should own. Requirements written as solutions quietly remove the engineering team's ability to find a better one.

The sections to include

1. Purpose and user

One paragraph on the problem, who has it, and how they currently solve it. If you cannot write this without hedging, the product is not ready for engineering yet — run a feasibility study first.

2. Functional requirements

What the product does, stated as numbered, individually testable statements. Each one gets a value and a unit. "Fast" and "quiet" and "durable" are not requirements; a cycle time in seconds, a sound level in decibels at a stated distance, and a cycle count before failure are.

3. Physical and mechanical constraints

Maximum dimensions and weight, mounting or carrying method, materials that are required or forbidden, ingress protection expectations, colors and finish direction, and any interface that must fit existing hardware.

4. Operating environment

Temperature and humidity range, indoor or outdoor, exposure to water, dust, chemicals, UV, or vibration, and how the product will be transported. This section drives more engineering decisions than any other and is the one most often left blank.

5. Power and connectivity

Battery or mains, runtime, charging method, standby behavior, and which wireless protocols are needed — along with what happens when connectivity is unavailable, which is a functional requirement, not an edge case.

6. Interface and user experience

Controls, indicators, display, sounds, app behavior, and setup flow. Note explicitly whether an app is required for basic operation or only for advanced features.

7. Regulatory and safety scope

Which markets, and therefore which requirements apply: FCC authorization for anything intentionally radiating, a safety certification for mains-powered products, CPSC rules for children's products, an FDA pathway if it is a medical device. See product safety testing requirements for how this scoping works. Regulatory scope changes the architecture, so it belongs in the PRD, not in a later phase.

8. Cost and volume targets

Target landed unit cost at a stated annual volume, acceptable tooling investment, and target retail price. These constrain the design as hard as any physical dimension, and they determine which manufacturing processes are even candidates.

9. Verification method per requirement

The section that separates a real PRD from a wish list. Against every requirement, state how it will be proven: measurement, laboratory test, inspection, calculation, or analysis. Requirements with no verification method are opinions.

10. Explicit non-goals

What this product deliberately does not do, and what is deferred to a later version. Writing this down is the single most effective defense against scope creep.

Make every requirement testable

Apply four filters to each line:

  • Measurable? A number and a unit, or a defined pass condition.
  • Single? One requirement per line. Sentences containing "and" usually hide two requirements with different owners.
  • Necessary? Mark each as must-have, should-have, or nice-to-have. If everything is a must-have, nothing is, and the first schedule pressure will resolve the priority for you badly.
  • Neutral? Does it state a need rather than prescribe a solution?

Why teams skip it, and what it costs

The usual reason is that requirements feel like paperwork while CAD feels like progress. The cost shows up later and compounds. A requirement discovered during design costs a conversation. The same requirement discovered after the enclosure is designed costs a redesign. Discovered after tooling, it costs a mold change and weeks of lead time. Discovered after certification testing, it can cost the entire test campaign. This escalating curve is why undefined scope appears in nearly every honest account of why new products fail, and it drives most of what people experience as unpredictable product development cost.

Keeping it alive

A PRD is a living document with version control, not a file written once and forgotten. Requirements will change — markets move, components go obsolete, testing reveals reality. What matters is that changes are deliberate, dated, and reviewed for knock-on effects rather than absorbed silently by whoever noticed. Once the design is released to manufacturing, that discipline formalizes into an engineering change order process, and the PRD becomes the baseline that the bill of materials and test plans are traced back to. Day to day, the PRD is also the anchor for project management: it defines what "done" means, and it is the reference for the whole product development process.

A practical way to start

Write a first draft in a few pages, even a rough one. Then walk it through with an engineer, a manufacturing contact, and someone who will actually use the product. Each of them will find requirements you did not know you had. Expect the second draft to be substantially different from the first — that difference is the value the document just delivered, and it was cheaper to discover on paper than in steel.

Need help turning a product concept into a specification an engineering team can build from? Get in touch through our contact form and we will work through the requirements with you before any design work begins.