You Built Exactly What They Asked For. They Hate It.

Speaking from experience, this is one of the most demoralizing moments in the technical program work. You delivered on time. You delivered within budget. You built what the requirements document specified, line by line, with evidence. And the customer looked at what you built and told you it wasn't what they needed.

You're not wrong. They're not wrong. The requirements were wrong. And odds are that nobody caught it until you handed them something they couldn't use.

How This Happens

Requirements documents are written by humans, at a specific moment in time, based on what those humans understood about the problem at that moment. The understanding is almost always incomplete. The language is almost always imprecise. The assumptions are almost always unstated. None of that is intentional. It's just the nature of trying to describe a complex technical need in a document before the solution exists.

The problem is that most programs treat the requirements document as a finished product rather than a starting point. It gets written, reviewed, approved, and then handed to the development team as if the act of approval means the requirements are correct. They're not correct. They're the best available description of what was understood at the time. Those are different things.

When the development team executes faithfully against an incomplete understanding, they build a faithful representation of that incomplete understanding. Which is exactly what your customer is looking at when they tell you it's not what they needed.

The Translation Gap

Between what a customer says they need and what they actually need, there is almost always a gap.

Sometimes it's small: a terminology difference, an unstated assumption about operating environment, a constraint that was obvious to the customer and invisible to the developer. Those gaps produce surprises at delivery but usually survivable ones.

Sometimes it's large: the customer described the solution they imagined rather than the problem they were trying to solve, and the solution they imagined doesn't actually work. Those gaps produce programs that get cancelled, restarted, or quietly shelved.

We have worked on programs at both ends of that spectrum. The ones that ended well had someone whose job it was to close the translation gap early — to sit with the customer, understand the problem behind the requirement, surface the assumptions, and make sure the development team was building against the actual need rather than the documented approximation of it.

The ones that ended badly skipped that step. Usually because it wasn't in the contract, or because the schedule didn't allow for it, or because raising questions about the requirements felt like challenging the customer.

Why Nobody Raises the Flag

The pressure to just execute is real. In reality, you hear things like: “This is a go-fast program.” “We need this now.”

Raising questions about requirements feels like slowing things down. It can feel like telling the customer they don't know what they want — which is uncomfortable for everyone. In some program structures, it creates contract modification risk, which neither side wants to deal with.

So the requirements get accepted and never really questioned over time. Work begins. And the first time anyone really tests whether ‘requirements’ reflect ‘actual needs’ is at delivery — when it's too late and too expensive to fix.

The flag should have been raised at requirements review. Or at design review. Or at any of the checkpoints between the document and the delivered product where someone with the right knowledge and the right standing could have asked: does this actually solve the problem?

That question is not a threat to the program. It's the most important question the program needs answered. It’s also the most terrifying question that could be asked in practice for some reason…

Getting Ahead of It

The fix isn't a ‘better’ requirements template. It’s not more people looking at the problem. Neither of those help. The real solution involves a different kind of conversation at the front of the program.

Before requirements are locked, someone needs to be asking: what problem are we actually solving? What does success look like to the operator, not the program office? What assumptions are embedded in these requirements that we haven't tested? What would have to be true for this to work — and how confident are we that those things are true?

Those conversations are uncomfortable. They surface disagreement early, which feels like friction. What they actually are is load-bearing work that prevents the much larger friction of discovering at delivery that you built the wrong thing. It requires that someone, somewhere on the program have the answers. And maybe that is why the question is so threatening… no one wants to consider the answer may be ‘no one here has them’.

But that can be fixed. And it’s easier to do at the start. Because one of the most expensive mistakes you can make in technical development is a ‘faithfully executed, but entirely wrong’ requirement. Everything after that point costs more than it should have: rework, delay, relationship damage, crushed morale, lost customer confidence. It goes on and on. The gift no one wants, and one that keeps on giving.

None of it was necessary. The information to prevent it is always available. You just need someone willing to ask the right questions before the work starts. And then keep asking as the work progresses!

Someone has to be willing to be the person who asks. That's a specific skill and a specific kind of courage — and it's easier when it's someone's explicit job rather than an uncomfortable addition to everyone else's.

At Leitwolf, requirements translation — figuring out what the customer actually needs before the build starts — is one of the core things we do. If you've been burned by this before or want to make sure you won't be, let's talk.