How to Write Product Requirements That Survive the First Prototype

A user need describes an outcome in context. A requirement translates that need into a measurable condition. A design feature is one possible way to meet it. Keep those three levels separate. If the need is confirm that a container is closed, the requirement might define the detection state, response time, false indication rate, and operating conditions. A colored light, latch geometry, sound, or app notification can then compete as solutions.

This separation matters during prototyping because a failed feature does not automatically invalidate the need. It also prevents a popular mechanism from becoming an unquestioned requirement. Record the source of each need: observation, interview, complaint, regulation, business constraint, or engineering analysis. A requirement with no rationale is difficult to prioritize when cost or risk forces a tradeoff.

A practical pattern is: the product shall perform an observable behavior, under named conditions, to a target and tolerance, verified by a stated method. For example, the enclosure shall remain closed after ten drops from one meter onto plywood at room temperature, with no exposed sharp edge and with the primary function still available, verified by the documented drop procedure and post-test inspection. The example still needs product-specific review, but it can be debated and tested.

Avoid combining several independent outcomes in one sentence. Separate drop survival, water resistance, appearance, and function so a partial failure is visible. Avoid terms such as appropriate, adequate, user-friendly, high quality, or industry standard unless the brief defines them. If a number is not known, write target TBD, name the evidence needed, and assign an owner. A labeled unknown is safer than invented precision.

A target without conditions can mislead. Battery runtime changes with load, temperature, radio use, display brightness, and battery age. Sound changes with distance and room. Strength changes with material, geometry, process, and conditioning. Write the normal range, edge conditions, and excluded conditions. Where foreseeable misuse matters, create a separate safety requirement rather than pretending normal operation covers it.

A tolerance states acceptable variation. It can be dimensional, temporal, force-based, thermal, visual, or statistical. Do not copy a tolerance from a different process without checking whether it is necessary and achievable. Tight tolerances raise cost and can hide a design that should be less sensitive to variation. Ask what user outcome fails outside the tolerance and whether the design can be made more forgiving.

Every requirement needs a proposed verification path: inspection, analysis, demonstration, or test. Inspection can confirm a label or dimension. Analysis can support a load or cost estimate when its inputs are controlled. Demonstration can show an operational sequence. Test measures performance under defined conditions. Complex products often need more than one method, and consequential results need qualified reviewers and controlled procedures.

Write the method before the prototype so the artifact is designed to answer the question. Define equipment, fixture, sample, setup, repetitions, measurements, acceptance threshold, data record, and what makes a result inconclusive. If the first prototype cannot represent the relevant material or process, say so. Passing a visual mockup cannot verify production strength; passing one printed part cannot establish a lifetime claim.

Use more than a must-have label. Record severity if the requirement fails, user value, evidence confidence, design sensitivity, and cost impact. A requirement connected to injury risk deserves attention even if it is invisible in a demo. A high-value requirement with low evidence should shape the next prototype. A costly preference with weak user value is a candidate to relax or remove.

Keep regulatory and standards questions visible but do not convert a screening tool into a compliance conclusion. The CPSC Business Education Library and applicable standards organizations can help identify investigation paths. A qualified specialist must interpret requirements for the exact category, users, claims, and markets. Track those questions alongside product requirements so the concept cannot advance by ignoring them.

Give each requirement a stable identifier. Link it to the need, risk, source, design element, verification record, and decision. When a target changes, keep the prior value, date, author, and rationale. This small amount of traceability answers critical questions later: which evidence supported this dimension, which test is invalid after the material change, and which user outcome is affected by a cost reduction.

Review dependencies after every major concept change. Replacing a fastener can affect assembly time, service, sealing, safety, tooling, and end-of-life disassembly. Changing intended use can change the regulatory path. Updating an AI-generated specification without updating its evidence links creates polished drift. The requirements table should be the controlled index to current truth, not a static appendix.

Identifier and title; user need and rationale; requirement sentence; normal and edge conditions; target and tolerance; priority; risk if unmet; verification method; acceptance rule; evidence state; owner; source; linked prototype; linked test record; open questions; and change history. Keep the table short enough to review, while linking to the detailed method and evidence rather than embedding every artifact.

Before releasing a prototype request, ask: can a builder tell what matters, can a tester tell what to measure, can a reviewer tell what remains unknown, and can a decision maker see the consequence of failure? If any answer is no, revise the requirement. Then use ConjureAnything to explore a concept against those constraints, not to replace the engineering work that follows.