Right on Paper, Wrong in Users' Hands

The two-sided requirements failure that hardware teams rarely name

There is a gap that opens up in almost every hardware program at some point, and most teams only notice it when they are already in trouble.

It happens between what the customer actually needs and what the engineering team is building toward. Not because anyone ignored the customer. Not because the engineers made a mistake. It happens because the starting point was incomplete, and something had to fill the space.

When customer requirements are too thin

Customer success criteria are supposed to answer one question: what does success look like from the user's perspective? Not how the system achieves it. Not which technology solves it. Just what the experience needs to be, at what level of performance, under what conditions.

When that answer is vague, incomplete, or simply not written down, engineers don't stop working. They create context from the point of view of a technical solution. They define what they can measure, what they can build, what the system can do. The requirements document gets filled in. The product gets built to spec.

And then it reaches users and something is wrong, but nobody can point to a single requirement that was missed.

That is the failure. Not a technical error. A framing error made at the very beginning, when the customer story was not complete enough to constrain the engineering story.

The failure that runs the other way

There is a second failure mode that gets far less attention, and it is equally damaging.

When a product manager moves beyond defining the customer experience and starts prescribing specific solutions, particular technologies, or design architectures, the engineering team loses something important: the room to actually solve the problem.

Engineers follow the brief. They build what they are told. The product is technically correct. It does exactly what the requirements say. But the requirements were written around a solution instead of around a need, and so the product arrives in users' hands misaligned in a different way. Still right on paper. Still wrong in practice.

What the right balance actually looks like

Customer requirements and engineering requirements are two different documents. They have different authors, different audiences, and different jobs.

Customer requirements describe the experience. They are grounded in research, not assumptions. They tell the technical team what success looks like from the outside: what the user needs to feel, accomplish, or understand, and at what level of performance. They do not say how.

Engineering requirements translate that into a technical specification. They describe what the system shall do, under what conditions, and to what measurable standard. They are derived from the customer requirements, not invented independently of them.

When the first document is complete and clear, the second one has solid ground to build on. When the first is thin, engineers fill the rest of the space from a technical frame. When the first is overreaching, engineers follow instructions into a dead end.

The handoff is where products are made or lost

The tension between product and engineering is not a problem to solve. It is a signal that the boundary is working. Product owns the what. Engineering owns the how. The handoff between them — the moment where a well-defined customer need becomes a well-structured technical requirement — is one of the most consequential moments in a hardware program.

It deserves more attention than most teams give it.

The programs that get it right do not get it right because they have better engineers or better product managers. They get it right because someone made sure the customer story was complete before the technical story started.

That document has one job. It should do that job fully, and stop there.