A request can present an intervention as if it were the problem itself. “We need more training” sounds urgent, but it names a remedy, not the result that would make the remedy worthwhile. Detect a Baked-In Solution separates the desired outcome from the proposed mechanism. This creates room to compare the favored idea with alternatives without dismissing it.
Listen for verbs such as “build,” “implement,” “hire,” “train,” or “introduce.” Then ask: if this intervention were unavailable, what improvement would still matter? What observation would tell us that the underlying need had been met? The answers may reveal a performance problem, a coordination problem, missing information, a goal conflict, or something else. The originally proposed solution can still win after that comparison.
Four short examples show the move:
Request: “We need more training.”
Possible underlying problem: People make a recurring error because instructions, incentives, or the tool itself do not support the task. Training is one candidate response; it is not yet the diagnosis.
Request: “We should build an AI assistant.”
Possible underlying problem: People cannot find a reliable answer quickly enough. Better navigation, clearer ownership, or a narrower automation may also serve that need.
Request: “We need a weekly status meeting.”
Possible underlying problem: Colleagues cannot see dependencies early enough to act. A meeting may help, but a shared decision log or clearer handoff might too.
Request: “We need to hire another salesperson.”
Possible underlying problem: Qualified leads are waiting too long, or current leads do not convert. Those two frames suggest very different checks.
A personal version is “I need a new productivity app.” The underlying need might be remembering commitments, protecting focus, or reducing the number of commitments accepted. None of those automatically requires a new app.
This pattern is useful when discussion immediately turns to implementation details, when people disagree about which tool to buy without agreeing what should improve, or when a plan is being defended mainly because it is already named in a project brief. Its failure mode is an automatic anti-solution stance. Sometimes the proposed intervention is well supported and timely. Recovering the need should clarify the case for it, not endlessly reopen a settled decision.
Remove Constraints questions boundaries such as “only this team”; this pattern questions a prescribed mechanism. Rethink the Goal goes a level higher and asks whether the stated outcome is itself the right target.
Related patterns
Identify the Problem Form · Find Alternative Paths
Source
Inspired by Thomas Wedell-Wedellsborg's What's Your Problem? This is an original Patternverse procedure, not reproduced book text or an official implementation.