What a hardware PRD is for
A PRD turns a product idea into requirements that engineers and suppliers can design, quote and test against. In hardware it carries more weight than in software, because requirements drive tooling, components and certification, and those are expensive to change once committed.
It sits between two other documents:
- The market requirements document (MRD) explains the market, the customer and the business case.
- The PRD defines what the product must do to meet that case.
- Engineering specifications describe how: architecture, components, mechanical design and test methods. An ODM often writes these from your PRD.
What to include
| Section | What to state |
|---|---|
| Users and use | Who uses it, where, how often, and the main use cases |
| Functions | Features, with must-have and nice-to-have clearly separated |
| Performance | Measurable targets with conditions: battery life, range, accuracy, response time |
| Physical | Size and weight limits, materials, colors and finishes, buttons and indicators |
| Environment | Operating and storage temperature, humidity, drop, water and dust protection |
| Power | Battery limits, charging method and charging time |
| Connectivity and software | Radios, app, cloud, firmware updates, and who owns each part |
| Markets and compliance | Countries of sale and the certifications they imply |
| Reliability | Expected lifetime, duty cycle, warranty assumptions |
| Packaging and accessories | What ships in the box |
| Cost, volume and timing | Target unit cost, launch quantity, annual volume, launch date |
| Acceptance | How each key requirement will be verified |
How to write a requirement a supplier can quote
A useful requirement is measurable, has its test condition attached and says how much it matters.
- Weak: “Long battery life.”
- Useful: “At least 7 days between charges with the usage profile in appendix A, at 25°C, measured on DVT units. Must-have.”
- Weak: “Waterproof.”
- Useful: “IP67 per IEC 60529: dust-tight, and protected against temporary immersion, tested at 1 m for 30 minutes. Not intended for swimming. Must-have.”
Many performance requirements depend on how the product is used, so write the usage profile down: how many hours a day it is on, how often it connects, how often buttons, motors or displays are used, and in what conditions. The same profile then drives battery sizing, reliability testing and the claims you can make on the box, and it stops every engineer assuming a different “typical user”.
When a requirement is not yet known, say so and give the range under consideration. A supplier can quote a range or propose options; it cannot quote around a guess it does not know is a guess.
Common gaps
- No target cost or volume. Suppliers then design to their own assumptions, and quotes come back impossible to compare.
- Everything is a must-have. Without priorities, every trade-off turns into a negotiation.
- Markets left open. Certification for the US, EU, UK and other markets affects design, testing and budget, so “global” is not an answer.
- Software ownership unstated. Who writes and maintains firmware, the app and the cloud service changes which supplier you need.
- No version control. Each revision should carry a version number and date, and suppliers should quote against a named version. A change after quotation means a re-quote; a change after design freeze means a formal engineering change.
PRD, RFQ and ODM platforms
The PRD is the core of an RFQ package. When an ODM offers an existing platform, the PRD is also how you separate what the platform already does from what must change, which is where NRE and schedule risk come from. A short gap list against the platform often tells the supplier more than a long generic specification.
For a structured way to prepare the brief that goes with it, see how to prepare a hardware supplier brief, and use the OEM/ODM readiness review to check what is still missing.
Where Zefinity helps
PRD review and product definition are part of Zefinity’s Develop service, which prepares a product for manufacturing before suppliers are engaged.
Frequently asked questions
What is the difference between a PRD and a specification?
A PRD says what the product must do and under what conditions. An engineering specification says how: architecture, components, mechanical design and test methods. In OEM/ODM work, you usually own the PRD and the supplier writes or proposes much of the engineering specification in response to it, which is why the PRD has to be precise.
How long should a hardware PRD be?
Long enough to state every requirement that affects cost, design or testing, and no longer. A short PRD with measurable requirements, priorities and test conditions is more useful than a long one full of description. Many teams keep the core requirements in a table and move usage profiles, market details and drawings into appendices.
Should a PRD be shared with suppliers before an NDA is signed?
Share a summary first. Early conversations can usually run on a short brief that explains the product category, key requirements, markets and volumes without detailed drawings. Send the full PRD, CAD and BOM once a supplier is shortlisted and has signed an appropriate confidentiality agreement, which for manufacturers in China is often an NNN agreement.