Risk management in a product development project is not a compliance ritual. It is a short written list — ten rows is plenty — reviewed every couple of weeks, where each row has an owner, an action, and a date, and where reviewing it actually changes decisions. A problem is something that already happened. A risk is something that might happen and can still be prepared for. Look at any failed hardware program and you will usually find a risk everyone knew about, nobody wrote down, and therefore nobody owned.

Four families of risk

Technical risk

"We are not certain this will work." The sensor whose accuracy has not been proven in your application, the algorithm that has never run on real hardware, the mechanism that has to survive thousands of cycles. The correct treatment is to move the test earlier: build a partial prototype that isolates only the risky question, before an entire system is designed around it. That is the whole purpose of a feasibility study and of early rapid prototyping.

Supply chain risk

A component goes end-of-life, a supplier closes, a container sits at anchor, a tariff classification changes your landed cost. Treatment: approve alternate parts during design rather than when inventory runs out, check lifecycle status and lead times for every critical component before the layout is frozen, and avoid designing a single-source part into a load-bearing position. Depth in supply chain for a hardware startup and import duties and tariffs.

Regulatory and certification risk

A product that fails at a test lab a month before launch. In the US this usually means FCC emissions on a wireless device, a safety mark for anything mains-powered, CPSC and CPSIA requirements for children's products, or the FDA pathway for a medical device. The treatment is pre-compliance testing early rather than formal testing late — radiated emissions scans on an engineering build cost a fraction of a failed formal campaign plus a board respin. See EMC testing cost, product safety testing requirements, and for regulated devices FDA design controls. This article is general engineering guidance, not legal or regulatory advice; specific determinations belong with qualified counsel or a notified test lab.

Market risk

The product works and nobody buys it. Statistically the largest risk in most programs and the most neglected, because it is not technical and therefore feels like somebody else's job. Treatment: validate demand before you tool, using the methods in how to validate a product idea and landing page preorder tests, and run a paid pilot with a real customer before committing to volume. See also why new products fail.

Scoring: probability, impact, and the deadline that matters

Give every risk two numbers, probability and severity, and let the product set priority. But the more useful dimension is when it locks in. A risk caught during requirements costs a conversation. The identical risk caught after a mold is cut costs an order of magnitude more, and after units are in customers' hands it costs a recall. So rank by how much time remains before the decision is set in steel, not by severity alone. Anything that will be frozen by the next gate is urgent regardless of its score.

Four legitimate responses

  • Eliminate — change the design so the risk no longer exists. Best when available, and often cheaper than it looks during architecture.
  • Reduce — earlier testing, an approved second source, a larger design margin, a simpler mechanism.
  • Transfer — insurance, supplier warranty, or a contract clause. See product development contract terms.
  • Accept — a conscious decision to live with it, with a written fallback plan. Perfectly legitimate as long as it is explicit and dated rather than implied.

The tool: a ten-row table

You do not need software. A sheet with six columns — description, probability, severity, owner, action, due date — and at most ten rows. Past ten rows, nobody reads it, which defeats the purpose. Review it at every status meeting. Mark closed risks as closed rather than deleting them, so the reasoning behind each decision stays on the record. In regulated hardware this informal table becomes a controlled document with a defined methodology — the medical device version is described in ISO 14971 risk management, and the manufacturing analogue is a process FMEA.

The risk nobody writes down

In our experience, the single most common cause of stalled projects is undecided decisions: an open question nobody resolves, which the team designs around until it becomes a hard blocker. The only defense is an open-decisions list kept next to the risk register, where every open question has a named owner and a due date. A project where every open question has an owner moves. A project running on "we'll decide that later" does not. The same discipline drives product development project management and shows up again in the hidden costs of hardware development.

Put a risk register on your project

Projects House builds a live risk register and an open-decisions list into every US client program, reviewed at each status meeting and revisited at every gate. If your project has a risk you keep thinking about and never writing down, describe it through the contact form and we will tell you honestly how we would retire it. More on how we work in product development services.