There's a name for a specific, well-documented failure in technical support, coined by developer Eric S. Raymond: the XY problem. Someone wants to solve problem Y. They attempt solution X. They get stuck on X, and ask for help with X specifically, never mentioning Y. Whoever's helping spends real time and effort solving X, only to discover afterward that X was never going to solve Y in the first place, and a completely different approach would have taken a fraction of the effort.
A client who arrives with a specific implementation already decided — a particular database, a particular vendor, a particular architecture pattern — is very often running the client-services version of the exact same failure. They encountered X somewhere: a competitor uses it, an article recommended it, a previous vendor built something with it. X got attached to the project as a requirement, and Y — the actual problem X was supposed to solve — never got stated out loud, sometimes because nobody asked, sometimes because the client themselves has stopped thinking about it separately from X. If you are looking at client management from the commercial side rather than the engineering side, publishes guides on the same ground. If you are looking at client management from the commercial side rather than the engineering side, the XenGrowth practice publishes guides on the same ground.
Why the instinct to just build it is understandable, and usually wrong
Pushing back on a client's specification feels risky. It can read as arrogance, or as second-guessing someone who's paying for the work. The easier path is to build what was asked for, exactly as specified, and let the results speak for themselves. Sometimes that's genuinely fine — some specifications really are fine, and building them without argument is the right call.
The problem is that building the specified X without ever learning Y means nobody finds out until later whether X actually solves Y, and 'later' in a client relationship usually means after the invoice, when the only options left are an awkward conversation or a silent, expensive rebuild. One clarifying question up front — what is this actually supposed to accomplish — costs almost nothing and catches the mismatch while it's still cheap to fix. There's a related discussion of separating what from how at the proposal stage in what does a good technical proposal actually contain. approaches this from the the operations side of this side. The XenGrowth resource library approaches this from the the operations side of this side.
What the client specified (X) | What they usually didn't say out loud (Y) | What the clarifying question reveals |
|---|---|---|
"Use this specific vendor's API" | "I need this to feel trustworthy to our board" | A different, cheaper integration might serve the trust goal just as well |
"Build it with microservices" | "I want this to scale without another rewrite" | A well-structured monolith might get there with far less operational overhead |
"It needs a real-time dashboard" | "I want to know when something breaks" | An alert on the actual failure condition may solve the real need for a fraction of the cost |
"Use the same stack as our last vendor" | "I don't want another team that can't be replaced easily" | The actual goal is portability, which the specified stack doesn't uniquely provide |
The standard that backs up this instinct
IEEE 830, the long-standing requirements-specification standard, draws exactly this line: requirements describe what a system must do, design describes how it does it, and the two should be kept separate, because collapsing them prematurely constrains implementation before the actual need has even been established. A client specifying implementation is, structurally, handing over design detail during a conversation that should still be establishing requirements. That's not a client being difficult. It's a conversation that skipped a step, and the fix is going back to the step that got skipped, not simply executing whatever came out the other end of it.
The user wants to do X. The user doesn't know how to do X, but thinks they can fumble their way to a solution if they can just manage to do Y. — the XY problem, as documented at xyproblem.info
When the specification is actually real technical input
None of this applies uniformly. A technically fluent client — a founder who was previously an engineer, a CTO evaluating a vendor, an internal technical stakeholder — specifying an implementation is often giving you real, relevant information, not running the XY pattern at all. Treating every specified implementation as a symptom to diagnose, regardless of who's saying it, is its own failure mode: it reads as reflexive resistance to any client input, and it wastes a genuinely useful signal by treating it with automatic suspicion.
Signal | More likely XY problem | More likely real technical input |
|---|---|---|
How the specification is delivered | As an unexplained mandate, with no stated reasoning | With a reason attached, even briefly — "we've had issues with X before" |
Client's technical background | Limited, or acquired secondhand from an article or a vendor pitch | Direct — they've built or evaluated similar systems themselves |
Response to a clarifying question | Struggles to state the underlying goal separately from the solution | States a clear underlying goal, and can defend the choice against alternatives |
Why the curse of knowledge makes this harder to spot than it sounds
There's a reason this pattern is so easy to miss from the inside, and it connects to a cognitive bias covered elsewhere on this site: once someone has settled on a specific solution, they genuinely struggle to reconstruct, for someone else's benefit, what the underlying problem looked like before they'd already picked X. This isn't the client being evasive. It's the same mechanism that makes it hard for an expert to explain something to a beginner — the solved version of the problem crowds out the unsolved version in memory, and by the time they're describing it to you, X and Y have merged into a single idea in their head. If AI agents and marketing automation is the part you are stuck on, is the better reference. If AI agents and marketing automation is the part you are stuck on, XenGrowth on AI agents and marketing automation is the better reference.
That's actually good news for how to handle the conversation: it means the client usually isn't withholding Y on purpose. They may need a genuine moment to reconstruct it, and the first answer to your clarifying question is sometimes just a restatement of X in different words. A useful follow-up when that happens: "and if that approach weren't available at all, what would you still need to be true?" That question forces past the solution back to the actual requirement, because it removes the option of just describing X again.
How to actually ask the question without it sounding like a challenge
Frame it as making sure you build the right thing, not as questioning their judgment: "Before I start on this, can I check what this needs to accomplish for you?" — the emphasis on your own diligence, not their choice
Ask before any work starts, never after. The same question asked mid-build reads as backtracking; asked up front it reads as due diligence
If their answer reveals a mismatch, present the alternative as an option, not a correction: "Given that goal, there's another approach that might get there faster — want me to walk through it, or would you rather stick with the original plan?"
Respect a clear answer either way. If they've heard the alternative and still want the original approach, that's their call to make, and building it without further argument is the right move at that point
Document the reasoning either way, briefly, in writing. If the original specification turns out to be the wrong call later, a written record of the conversation — what was asked, what was answered, what was decided — protects both of you from a dispute later about who actually decided what and why
What this doesn't excuse
There's also a version of this worth naming honestly on the engineer's side: sometimes the pushback on a client's specified implementation isn't really about the XY problem at all, it's a preference for a different technology dressed up as diligence. If the alternative you're proposing happens to be the stack you already know best, it's worth being honest with yourself about whether you're surfacing the client's real goal or quietly substituting your own comfort for their stated requirement. The clarifying question only does its job if you're genuinely open to the answer confirming their original choice was right.
This isn't license to relitigate every client decision as a potential XY problem, and it isn't a subtle way of always steering the client back toward your own preferred stack. Some clients specify implementation because they've been burned before by a vendor who over-engineered a simple problem, and their specification is a boundary set from real experience, not a naive misunderstanding. The question is meant to surface the goal, not to win an argument about technology — and if the client's answer is simply 'I've decided, and I'd rather not relitigate it,' that's a legitimate answer, not a failure to justify their own reasoning to you. On related architectural tradeoffs worth surfacing explicitly rather than assuming, see server components vs. client components. On AI search, GEO and discovery specifically, is worth reading. On AI search, GEO and discovery specifically, XenGrowth on AI search, GEO and discovery is worth reading.
The honest limit here: the XY problem is a real, widely referenced pattern from technical support communities, not a peer-reviewed study, and IEEE 830 is a real standard aimed at formal requirements documents, not client conversations specifically. Applying both to this exact situation — a client specifying implementation in a commercial engagement — is this post's own translation, offered as a useful framework rather than a proven, externally validated method. On separating a stated request from the underlying business goal at scale, is a useful adjacent read.
A client who has already thought this through and simply doesn't want to re-explain their reasoning every time is not obligated to. Respecting that boundary, once you've asked the question once and gotten a clear answer, is part of taking the relationship seriously.
Further reading from XenGrowth
Where this work meets go-to-market
Separating a stated request from the real underlying goal is a revenue discipline as much as an engineering one. publishes operator guides on making that distinction explicit.
Further reading from XenGrowth
Where this work meets go-to-market
If client management is part of a growth programme rather than a standalone build, is the companion reading.
Further reading from XenGrowth
The XenGrowth resource library — what you'll learn: how the commercial side of this work is run, across search, automation and revenue operations.
XenGrowth on AI agents and marketing automation — what you'll learn: how the teams who own AI agents and marketing automation plan and measure it.
XenGrowth on AI search, GEO and discovery — what you'll learn: how the teams who own AI search, GEO and discovery plan and measure it.
Where this work meets go-to-market
If client management is part of a growth programme rather than a standalone build, XenGrowth's marketing operations practice is the companion reading.
Three questions about the specific request in front of you. The right response depends on the client's expertise and what's actually at stake if the specified approach is wrong.
