The customer keeps asking for one thing and everything else you hear says they need something different. What do you do with that in discovery?

The contradiction is data, not an error

A requirements list that disagrees with the business outcome is one of the most useful things discovery produces, and the instinct to fix it immediately is what wastes it. Somebody wrote that requirement for a reason, and until you know the reason you cannot tell whether you are looking at a document nobody has revisited or the only line in it that the buyer genuinely cannot move.

There are three explanations and they lead to different behaviour. The requirement may be stale — inherited from the system being replaced, or copied from the last procurement — in which case naming it costs nothing and earns credibility. It may be a proxy for a driver nobody will state, so the real subject is a failed audit, an incoming executive, or a team whose remit depends on the answer being a particular technology. Or it may be a political commitment already made upward, in which case it is immovable for reasons that have nothing to do with architecture and everything to do with the fact that someone's judgement is attached to it.

Test it against something already decided

Asking the customer whether the requirement is real produces an unreliable answer, because the person you are asking either wrote it or reports to whoever did. What works instead is to ask about decisions that have already been taken and let the answers disagree with each other.

What you ask about	What the answer tells you
The last thing they bought in this area, and who signed it	Whether the stated constraint survived a real purchase or only appears in documents
What was in the approved business case, in its own words	Which outcome the money is attached to, which is rarely the requirement's wording
What was attempted before and why it stopped	Whether the requirement is a scar from a previous failure, which makes it durable
Which internal team would have to change how it works	Where the resistance lives, and whether the requirement is protecting it
What happens if the date slips two quarters	Whether the forcing function is the one you were told about

The pattern is that each question is about something that has already happened. Past decisions are checkable and specific, whereas a stated preference is free and will be restated at you for as long as you keep asking about it.

Raising it without making anyone wrong

The sentence that fails is any version of "I think you have the wrong requirement". It asks the customer to concede in front of colleagues, and it puts you in a position where being right is expensive. The move that works is to attach the requirement to their own stated metric and let the arithmetic create the doubt.

"Requirement 4.2 specifies the overnight batch window, and I want to check something rather than assume. Your business case is built on cutting acknowledgement time to the same working day. If the enrichment step waits for the batch, the earliest a claim received at two in the afternoon can be acknowledged is the following morning. Is the batch window a constraint from somewhere — a downstream system, a reconciliation obligation — or is it there because that is how the current platform works? The answer changes the design, and it may change the price in your favour."

Two things are doing the work there. You are asking about the origin of the constraint rather than its merit, which lets the author of the requirement supply the explanation instead of defending it. And you have named a consequence in their units, so the conflict is now between their requirement and their own business case rather than between their document and your opinion.

When you comply anyway

Sometimes the requirement is stale, you know it, and you should still design to it. A scored RFP will penalise deviation, an executive may have committed to the constraint publicly, and an internal team may hold a veto you cannot beat from outside. In those cases the answer is to comply with the requirement as written, price it honestly, and put the alternative alongside it as a clearly marked recommendation with its own number and its own delivery time. That way the compliant answer scores, and the recommendation exists in the document for the moment — usually after award, occasionally during clarifications — when someone internally decides the constraint is worth revisiting.

What you must not do is comply silently. A solution that meets the requirement and misses the outcome is discovered at acceptance, and by then the record shows that you were told the requirement and delivered it, which is contractually comfortable and commercially fatal.

Being right about the architecture and wrong about the buyer

The failure mode specific to strong engineers is winning this argument. You establish that the batch window is unnecessary, you demonstrate it convincingly, and in doing so you tell the head of operations that the constraint he has defended for two years was never real. He is on the evaluation panel. Nothing in the scoring rubric measures whether you were correct.

So the discipline is to make the contradiction visible without making it personal, and to let the customer resolve it. Write both readings into the recap: the requirement as stated with its consequence, the alternative with its consequence, and a question rather than a conclusion. If the requirement turns out to be immovable you have lost nothing, and if it moves it moves because someone inside the organisation decided it should, which is the only way it ever actually moves.

The requirement you were given and the outcome the money was approved for are two different pieces of evidence, and when they disagree your job is to make the disagreement visible and priced, not to decide which one wins.