Every founder we meet has a prototype story: the board that worked on the bench and died in the field, the enclosure that looked perfect in CAD and rattled in the hand, the app that shipped six weeks before the hardware it was supposed to talk to.
Almost nobody has a requirements story. Which is odd, because the requirements document is the first prototype you build, it costs a few hundred euros of your own time, and it is the only prototype you can iterate on twenty times in an afternoon without waiting for a courier from Shenzhen.
A written spec is a simulation of your product, run cheaply, before anything is committed to steel. In 2026 it has a second job as well: it is where you encode the regulation, the security posture and the end of the product’s life, all of which now arrive far earlier than most first-time teams expect.
Ambiguity in software is a bug; in hardware it is a change order
In software, a vague requirement produces a wrong build, and the wrong build gets thrown away on Thursday. The cost of the misunderstanding is a few days of somebody’s attention.
Hardware does not offer you that. A vague requirement propagates outward into things that harden at different speeds and are expensive to un-harden. The PCB stackup locks when the RF module needs a specific ground reference. The enclosure locks once the tool steel has been cut. Packaging locks around a print run with a minimum quantity, and certification locks the day the test lab takes your sample and gives you a booking slot two months out.
By the time somebody says “wait, we assumed the battery was user-replaceable,” the answer is no longer a code change. It is a new tool, a new EMC test campaign, a new artwork revision, a new safety file, and a conversation with a factory that has already quoted a price based on a design you have now changed. Each of those is a negotiation with a different party, on a different continent, on a different calendar.
This is why hardware teams talk about requirements with an intensity that looks obsessive to people from web backgrounds. The supplier chain is long, the parties are many, and the only artefact that travels intact from your kitchen table to a contract manufacturer in Dongguan is a written sentence. The demo, the shared understanding, the “you know what I mean”: all of it gets lost in transit.
A requirement is a promise you can lose an argument about
The failure we see most often has nothing to do with a missing requirement. It is a sentence that sounds like a requirement, feels like agreement in the room, and cannot be tested.
Bad:
The device should have good battery life and charge quickly.
Everyone in the meeting nods. The electronics engineer hears three days. The founder means two weeks. The factory quotes a cell that supports neither. Nobody is lying; there was simply nothing there to disagree with.
Better:
PWR-004 — The device shall operate for a minimum of 14 days on a single charge at 20 °C ambient, logging one sensor sample per minute and completing one BLE sync per 24 hours. Verification: 10 units from DVT build, full discharge per test procedure TP-014. Acceptance: ≥ 14 days on 10/10 units, mean ≥ 16 days.
PWR-005 — When connected to a 5 V / 1.5 A USB-C source, the device shall reach 80 % state of charge within 45 minutes.
The second version is longer and less pleasant to write. It is also the version that survives contact with a supplier, because it contains the three things a requirement needs: a subject that acts, a measurable condition, and a stated way of finding out whether you got it. Everything else is a wish.
If you want a shortcut to writing sentences like this, borrow the EARS notation that Alistair Mavin and his colleagues developed at Rolls-Royce and published in 2009. Five patterns cover almost everything a connected device does: ubiquitous, event-driven (when), state-driven (while), optional (where) and unwanted behaviour (if/then). They force the trigger and the state out into the open where you can see them.
One more discipline: separate what the product must do from how it will do it. “The device shall detect door open and close events with ≤ 500 ms latency” is a requirement. “The device shall use a reed switch” is a design decision that has smuggled itself into the spec, and it will block your engineers from proposing a Hall sensor or an accelerometer that is cheaper, more robust, or in stock. Write the constraint, not the solution, unless the solution really is the constraint, in which case say why.
The cost line belongs in the document
Target cost is a requirement, and it belongs on page one next to the user problem. Write down the retail price you intend to charge, the channel margin you will have to concede, and the resulting bill-of-materials ceiling, then break that ceiling into a budget by subsystem, the same way an aerospace team budgets mass. Radio and MCU get this much, mechanics get this much, battery and charging get this much, packaging gets this much. When somebody proposes a feature, they now have to say which envelope it comes out of. That single table kills more scope creep than any amount of prioritisation ritual.
Alongside it, write down the factory assumptions you are betting on, because they are requirements in disguise: expected annual volume, minimum order quantity you can stomach, first-order quantity, whether you are assuming a Chinese or European supply base and what that implies for lead time and tariff exposure, and which processes you are prepared to pay for (two-shot moulding? in-mould decoration? a custom rubber compound?). A team that has not decided whether it is building 2,000 units or 200,000 has not decided what its product is.
Regulation is not a phase at the end
For anything with a radio sold in the EU, the cybersecurity provisions of the Radio Equipment Directive have applied since 1 August 2025, with the EN 18031 series as the harmonised route. They bite at the level of ordinary product decisions. A device that lets a user skip setting a password during onboarding can lose presumption of conformity, at which point you are booking a notified body instead of self-declaring, with the cost and the calendar that implies. That is an architectural decision about your onboarding flow, made in the PRD, or made painfully later.
Layered on top is the Cyber Resilience Act, in force since 10 December 2024. Its incident and vulnerability reporting duties start on 11 September 2026, and the main obligations apply from 11 December 2027, which is roughly when a product being specified today will actually be in the channel. The CRA expects a declared support period (at least five years, or the product’s expected lifetime if that is shorter) during which you provide free security updates, a documented vulnerability handling process, and a machine-readable software bill of materials. If your firmware team cannot currently produce an SBOM, that is a requirement, today, not a 2027 problem.
And if your product has a portable battery, Article 11 of the EU Batteries Regulation (2023/1542) applies from 18 February 2027: batteries must be readily removable and replaceable by the end user, without heat or solvents, using commonly available non-proprietary tools. Exemptions exist for continuous power for safety and for certain wet-environment and medical products, and the Commission intends them narrowly. This is a mechanical architecture requirement. You cannot bolt it on after the tool is cut.
Certifications are requirements, and they should appear in your document from the first draft with target dates, not as a line item called “compliance” somewhere near “packaging.” Write down the target markets, the directives and regulations that follow from them, whether you are self-declaring or need a notified body, and which of those answers depends on a design choice you are about to make.
Firmware, updates, and the day you turn it off
Two requirements that first-time teams almost always omit, and that customers now notice: how the product updates itself, and what happens when you stop.
Updates are easy to write down and easy to underestimate. Specify signed images, A/B partitioning or a verified rollback path, a staged rollout policy, behaviour on power loss mid-update, and what the device does when it has been in a drawer for two years and wakes up eleven firmware versions behind. Decide the memory budget for dual-bank flash in the spec, because you will not find it on the BOM later.
Sunset is the uncomfortable one. In January 2026, Belkin ended support for most of its Wemo range: the app, cloud access and voice integrations for 27 products went dark on 31 January, with a partial refund offered only to devices still under warranty. The four models that kept working were the ones that spoke HomeKit or Thread and did not need Belkin’s cloud to function. Local control is a requirement, and it is the difference between a discontinued product and a brick.
Regulators have noticed too. In November 2024 the US FTC reviewed 184 connected products and found that 163 of them, 89 per cent, did not disclose how long software updates would be provided; for two-thirds, the information could not be found by searching the internet at all. Write your support commitment into the PRD as a dated promise: “security updates until at least [year], core local functionality available without cloud connectivity indefinitely.” Then design so that you can keep it.
Connectivity is a ten-year decision
Choosing Matter, BLE, Wi-Fi, Thread or a cellular LPWAN is not an implementation detail your firmware lead sorts out later. It determines your certification path, your ecosystem partners, your per-unit cost, your app architecture and your product’s lifespan.
If you are going into the smart home, Matter is now broad enough that “we’ll add it later” is a weaker argument than it was: version 1.5, released in November 2025, added cameras with WebRTC streaming, a unified closures model covering shades, gates and garage doors, soil sensors, and TCP support for large payloads including firmware images. Certification is a schedule item and a cost, so it goes in the document.
If you are going cellular, note that in most of Europe 3G is already gone and 2G is going: KPN in the Netherlands plans its 2G shutdown for December 2027, Deutsche Telekom for mid-2028, Finnish operators around 2029. A device designed today on a 2G-capable module has its own obsolescence built in, in some markets. LTE-M and NB-IoT are the sane defaults. Write down which bands, which regions, whose eSIM profile, and what the device does when coverage is absent for a week; “cellular” on its own is not a requirement.
Two products that died of unwritten assumptions
The Coolest Cooler raised more than $13 million from 62,642 backers in 2014 for a cooler with a built-in blender and Bluetooth speaker. It shut down in December 2019 with over 20,000 backers never receiving one. The proximate causes were many (strikes, recalls, a factory change, tariffs), but the structural one was there from day one: the product cost more to manufacture and ship than people had paid for it. That is a target-cost requirement that was never written, tested, or enforced against the feature list.
The Zano drone raised £2,335,119 against a £125,000 goal in early 2015 on the promise of a pocket-sized autonomous selfie drone. Roughly 600 units were ever built; four reached Kickstarter backers. The investigation Kickstarter commissioned from journalist Mark Harris concluded the team mounted a genuine effort but lacked the experience and resources to build what had been described, and found convincing evidence that demonstration footage had been faked. A specification that nobody had checked for feasibility became a marketing promise, and the promise became a company.
Neither team was lazy. Both wrote down what they wanted rather than what they could verify, and the gap between those two things is what sank them.
Living document, not monument
The last mistake is to treat the PRD as a thing you finish. Freeze it and it becomes fiction within a month; leave it open forever and it becomes a wiki nobody reads.
What works, in our experience at RMBG, is a document that is versioned, dated, owned by exactly one person, and frozen selectively rather than globally. Requirements that feed a tooling decision get frozen when the tool is ordered. Requirements that feed firmware stay open longer. Every change after a freeze gets a line in a change log with a name, a date and a reason, because six months later somebody will ask why the IP rating dropped from IP67 to IP54 and the answer needs to exist.
Tooling matters less than people think at your stage. A markdown file in the repository with stable requirement IDs beats an unloved seat of a requirements management platform. Move to Jama, Polarion, Valispace or similar only once you have to demonstrate traceability from requirement to test to defect to an auditor.
On AI: use it, but know what it is good at. The mechanical quality pass is where it earns its keep, flagging passive voice, vague adjectives, missing conditions, requirements with no verification method, inconsistent terminology across a hundred-page document. It also proposes decent test cases from a well-written requirement. What it cannot do is know what your product actually needs; drafts generated from generic context reliably omit the domain-specific requirements that matter, and it will happily invent a plausible-sounding standard number. Treat AI output as a first draft to be reviewed, never as an artefact to be shipped, and check every regulatory citation against the actual source.
Write the document, and argue about it while arguing is still free. It is the only prototype that costs nothing to throw away.
Sources
- Developing a Product Requirements Document for Hardware Startups — Bolt
- Cyber Resilience Act — European Commission, Shaping Europe’s Digital Future
- The Cyber Resilience Act explained
- Cybersecurity standards under the Radio Equipment Directive — CEN-CENELEC
- Radio Equipment Directive cybersecurity compliance — SCHUTZWERK
- EN 18031 for RED Cybersecurity: 2026 Compliance Guide — Iterasec
- European Commission publishes guidance on EU Batteries Regulation removability requirements — Cooley
- Belkin ending support for most Wemo smart home accessories — 9to5Mac
- FTC finds smart product makers silent on software support periods — The Register
- Matter 1.5 introduces cameras, closures and enhanced energy management — Connectivity Standards Alliance
- 2G and 3G sunset dates by operator — Onomondo
- Coolest Cooler shuts down, leaving 20,000 backers without their Kickstarter reward — GeekWire
- Torquing Group and the Zano drone — Wikipedia
- Easy Approach to Requirements Syntax (EARS) — Wikipedia
- AI in requirements management — Jama Software