The most expensive documents in product development are the ones nobody wrote. A team starts CAD with a rough idea of what the customer wants, the design solidifies over four months, and then a real user picks it up and says the thing has to fit through a 30-inch doorway, or run for a full shift on one charge, or be operated wearing gloves. Every one of those sentences, learned at the wrong time, costs a design cycle. Learned before the first sketch, each is a line in a requirements document that costs nothing.
Requirements capture is the cheapest engineering you will ever do, and the rule of thumb holds up: a change costs roughly ten times more at each stage it moves downstream. A requirement corrected on paper costs an hour. The same correction after tooling costs a tool modification and six weeks.
What Customers Say Is Not a Requirement
Users describe solutions, not needs, because solutions are easier to articulate. "Put a bigger handle on it" is a solution. The need underneath might be that they carry it up stairs with wet hands, which could be solved by a handle, by a shoulder strap, by cutting three pounds, or by a texture change. Take the solution literally and you have thrown away three better options.
The discipline is simple and hard: for every statement a customer makes, ask why until you reach something about their situation rather than about your product. Then record the need, and record their proposed solution separately as evidence rather than as a specification. Framing the underlying job properly is the work described in defining the problem your product solves, and it should be settled before anyone opens CAD.
How to Gather the Input
Contextual interviews beat surveys
Ten to fifteen interviews with real users, conducted where they would use the product, will surface more usable requirements than a survey of five hundred. You are watching for what they do rather than what they say, and specifically for workarounds: the tape, the shim, the second person holding something, the step they skip. Every workaround is an unmet requirement in physical form. Structured guidance on running these sessions is covered in user research before you design the product.
Separate the buyer from the user
In B2B and in many consumer categories these are different people with conflicting requirements. A facilities manager buying floor equipment cares about total cost, service intervals, and whether it fits the storage closet. The operator cares about weight, noise, and whether the controls make sense at 6 a.m. Both sets go into the document, tagged by whose requirement they are, because you will have to trade one against the other.
Talk to the people after the sale
Service technicians, installers, and warranty staff on competing or adjacent products know the failure modes better than anyone, and distributors know what gets returned. These conversations produce serviceability and packaging requirements customers never think to mention. Competitor reviews are a free version of the same thing: read the one and two star reviews of the three closest products and cluster the complaints.
Turning Needs Into Verifiable Requirements
A requirement that cannot be tested is an opinion. Every line in the specification should have a parameter, a target value, a tolerance or limit, and a verification method.
| Customer statement | Requirement | Verification |
|---|---|---|
| It should feel solid | No visible deflection under 25 lbf (110 N) applied at the handle; housing survives 1 m drop on each face onto concrete | Load test; drop test per the applicable standard |
| Battery has to last | Minimum 8 hours continuous operation at 25 °C; capacity above 80% after 500 charge cycles | Run-down test; cycle test |
| Easy to clean | All exterior surfaces reachable with a cloth; no gaps under 5 mm; withstands 200 wipe cycles with isopropyl alcohol | Inspection; chemical compatibility test |
| Quiet enough for an office | Below 48 dBA at 1 m in normal operation | Sound level measurement per the relevant test method |
Give every requirement an identifier, an owner, a source, and a priority. Traceability from a number in the spec back to a real person who said something is what stops the document from being negotiated away in week twelve by whoever argues loudest.
Prioritize with Kano, not with wishes
The Kano model sorts requirements into three buckets. Must-be features generate no satisfaction when present and severe dissatisfaction when absent; nobody praises a product for not electrocuting them. Performance features scale with satisfaction, like run time or weight. Delighters produce disproportionate enthusiasm but are not missed if absent.
The failure pattern in first products is spending the budget on delighters while a must-be goes unmet. Fund every must-be first, pick two or three performance attributes where you intend to beat the incumbent, and allow yourself at most one delighter. A must-have, should-have, could-have, will-not-have classification on top of that gives the team a defensible way to cut scope when the schedule tightens.
Writing the Document
The output is a product requirements document that engineering, industrial design, and manufacturing can all work from: intended user and use environment, functional requirements, performance targets with numbers, physical constraints, regulatory requirements, cost targets at the unit and tooling level, reliability expectations, packaging constraints, and explicit non-goals. The structure is laid out in how to write a PRD for a physical product.
Two sections founders skip and later regret. The use environment: temperature range, humidity, dust, vibration, chemical exposure, who is nearby. And the non-goals, an explicit list of what this version will not do, which is what keeps the project from absorbing every good idea anyone has in month five.
If you are commissioning the work rather than doing it, a shorter version of the same thinking belongs in the idea brief you send a development firm, and it is the difference between a useful quote and a guess.
Validate the Requirements, Then Freeze Them
Requirements gathered from interviews are hypotheses. Test them cheaply before design starts: paper prototypes, foam models, a cardboard mockup at real size, or a competitor's product modified with tape. Put those in front of the same users and watch which requirements they actually care about. Formal usability testing of a physical product at this stage costs a few thousand dollars and routinely eliminates features that would have cost tens of thousands to build.
Then freeze. A requirements freeze is a decision, not a bureaucratic event: from this point changes go through a controlled change process with a stated cost and schedule impact. Teams that never freeze never ship. Where the freeze sits relative to everything else is mapped in the overall product development process.
Projects House starts every engagement by turning what a client knows about their customer into a specification an engineering team can build to and a test plan can verify. If you have an idea and a rough sense of who it is for, tell us about it through our contact form.