The Client Brought a Solution. Find the Problem.

by

Discovery separates the business problem from the solution already attached to it.

When a client says, “We need a RAG system over our internal documents,” there is a real business need inside that request. The need may require RAG to address it. It may require RAG plus work the client has not yet identified. It may require something else entirely.

Until discovery separates the problem from the proposed solution, nobody knows.

A client request is evidence about a problem, not yet an engineering requirement. Discovery converts that evidence into requirements. Only then should engineering decide what belongs in scope.

The request deserves respect because the client knows things engineering does not. It reveals priorities, pain points, constraints, organizational history, and the client’s current theory about what should change. It also contains assumptions about causation and solution fit that discovery has not yet tested.

The technical leader’s job is to preserve the client’s objective while examining those assumptions. The principle applies to every request: a client develops a solution hypothesis, builds internal support, and arrives at the technical conversation one step beyond the question that most needs asking.

That question is not yet, “Can we build this?” It is: what is the client actually trying to accomplish?

The fastest route from a client request to an engineering backlog is not necessarily the shortest route to a useful system.

START WITH THE JOB, NOT THE TECHNOLOGY

Clayton Christensen’s jobs-to-be-done framework offers a useful way to make this distinction. Customers choose products and services to make progress toward an underlying objective. The requested technology is one clue about the need, not a complete description of it.

Harvard Business School professor Ranjay Gulati describes a related distinction between inside-out and outside-in thinking. Inside-out begins with what a firm sells. Outside-in begins with the customer’s problem and asks how available capabilities can create value there. Inside-out consulting asks: “How can we apply our AI capability to this client?” Outside-in asks: “What is preventing this client from reaching the desired business condition, and where would AI materially help?”

A consultancy should not begin discovery by asking where its capabilities can be deployed. It should begin by asking what progress the client needs to make.

SEPARATE THE REQUEST FROM THE REQUIREMENT

Making this practical requires separating five things that technical engagements often collapse into one.

A request is what the stakeholder asks to have built. “Build an AI support assistant.”

A business condition is the observable situation that caused the request. Support specialists spend too much time searching several systems, causing handling times to rise and questions to escalate unnecessarily.

An outcome is what must measurably become different. Reduce retrieval time and unnecessary escalations without increasing incorrect guidance.

A requirement states what the capability must make possible without dictating implementation. Authorized specialists must retrieve current, authoritative information within an agreed response time, within access boundaries, at defined quality thresholds.

A solution is the technical approach chosen to satisfy those requirements within the client’s constraints. It might be RAG, enterprise search, better information governance combined with retrieval, or something simpler.

The purpose of discovery is not to prove the client wrong. It is to determine whether the proposed solution fits the problem.

That creates a natural sequence:

CLIENT REQUEST
↓ BUSINESS CONDITION
↓ AFFECTED USERS
↓ CURRENT WORKFLOW
↓ CONSTRAINT OR FAILURE
↓ DESIRED OUTCOME
↓ SUCCESS MEASUREMENT
↓ ORGANIZATIONAL READINESS
↓ TECHNICAL CONSTRAINTS
↓ REQUIREMENTS
↓ SOLUTION OPTIONS
↓ ENGINEERING SCOPE

Senior technical leadership often means deliberately moving backward through that chain before engineering moves forward. In bespoke engineering and consulting, that judgment is part of what the client is paying for.

A VIABLE SOLUTION MUST FIT THE ORGANIZATION

Finding the right problem is only half of discovery. The proposed change must also fit the organization expected to use it.

Executive authorization can fund a system. It cannot manufacture organizational readiness for one.

MIT Sloan senior lecturer George Westerman makes this point directly: organizations capture value from AI when they change how they operate, not merely when they acquire better technology. Executive intent must cascade into governance, organizational readiness, changed workflows, technical capability, and measurable outcomes.

EXECUTIVE OBJECTIVE
↓ BUSINESS OUTCOME
↓ OPERATING CHANGE
↓ TEAM RESPONSIBILITIES
↓ USER WORKFLOW
↓ TECHNICAL REQUIREMENTS
↓ MEASUREMENT

When that chain breaks, engineering can deliver exactly what was requested while the business receives little of the intended value.

RAND documented this in a 2024 study based on interviews with 65 experienced AI practitioners. Among industry participants, 84% cited leadership-driven failures as a primary reason: projects aimed at the wrong problem, models optimized for metrics that did not represent business success, and systems that did not fit the surrounding workflow. RAND consequently recommends that technical teams understand the problem and domain context before focusing on the technology.

Problem definition is not administrative preparation for engineering. It is part of engineering success. If engineering accepts the proposed technology before establishing the business problem, the project can be technically sound and aimed at the wrong outcome from day one.

HCA Healthcare shows what it looks like to put that judgment upstream. HCA evaluates AI proposals through business, operational, clinical, financial, safety, privacy, and technical considerations before development begins, asking whether work can be digitized, automated, and improved by AI, and whether the result supports a strategic objective. HCA has effectively turned “should we build this?” into a governed decision rather than an assumption inherited from the request. Approval establishes authority to proceed. Discovery establishes what proceeding should mean.

RAG MAKES THE DISTINCTION VISIBLE

Few current technology requests expose the difference between request and requirement as clearly as RAG.

A client says: “We need retrieval-augmented generation across our internal documents.” Engineering can immediately discuss embedding models, vector databases, chunking strategies, and evaluation frameworks. Those are legitimate questions. They are simply not the first questions.

First ask why retrieval currently fails.

The client’s request for RAG is evidence that information retrieval is a problem worth examining. It is not evidence that retrieval architecture is the only thing preventing it from working.

Enterprise document collections accumulate without governance. Current policies coexist with obsolete versions. Documents covering the same subject may disagree. Ownership is unclear. Access permissions evolve independently across repositories.

A RAG system can improve access to information. It cannot determine through architecture alone which conflicting policy is authoritative or which obsolete material should still influence an answer. A semantically relevant document is not automatically the correct document.

The better discovery question is: what must be true of the knowledge base before retrieval from it can be trusted? Sometimes the answer reveals prerequisite work: canonical documents identified, ownership established, permissions reconciled, obsolete material retired.

Then the retrieval architecture has a knowledge base worth trusting. This is not an argument against RAG. It is an argument for establishing the conditions under which RAG will solve the client’s problem.

Google Cloud’s own generative AI guidance reaches the same conclusion: define measurable business goals first, then determine whether the problem requires generative AI, another AI approach, or no AI at all. “Deploy a generative AI assistant” is an implementation milestone. “Reduce average support resolution time while maintaining agreed quality levels” is a business outcome.

SIGNAL IDUNA, a German insurer, illustrates the difference. Its agents searched thousands of documents covering hundreds of insurance tariffs to answer customer questions. The company built an AI knowledge assistant with Google Cloud, BCG, and Deloitte. Google reports the system reduced information-search and response-formulation time by approximately 30%, with the case-closure rate rising from 73% to approximately 98%. The meaningful outcome was never “SIGNAL IDUNA now has RAG.” It was faster retrieval and more cases resolved without escalation. Architecture mattered because it changed the business condition.

MIT Sloan professor Rama Ramakrishnan pushes the same reasoning below the application level: break workflows into individual tasks before selecting a technology, because a single process may contain information retrieval, deterministic validation, summarization, human judgment, and legacy work that should not exist. The right unit of discovery is often not the requested application. It is the work underneath it.

The same logic applies above the application level. A cloud migration request requires establishing what constraint migration is expected to remove. The GAO treats federal cloud adoption as a portfolio decision, with each application assessed for retention, retirement, replacement, modernization, or consolidation. Migration is therefore a disposition decision before it becomes an infrastructure decision. A system can be moved successfully without improving the condition that motivated the migration. Technology modernization should address the constraint, not merely modernize the nouns used to describe the architecture.

DISCOVERY IS A COMMERCIAL DISCIPLINE

A consultancy exists to win and deliver engineering engagements. Accepting the wrong interpretation of a client request transfers the disagreement downstream as scope instability, rework, missed expectations, and a functional system the client cannot connect to measurable value.

Discovery is also commercial and technical qualification. Sometimes it validates the original request. Sometimes it modifies the solution or changes sequencing. Sometimes it exposes a larger legitimate problem, such as a dashboard request revealing a missing data model. The engagement grows because the actual outcome requires more work, not because the consultancy manufactured an upsell.

That is the commercial question discovery should answer: what should this client actually be buying from us? The client may arrive asking for a feature and leave discovery understanding that they need a capability. Good discovery does not obstruct a sale. It improves what is being sold by replacing scope built on assumption with scope built on evidence.

THE SENIOR TECHNICAL LEADER IS NOT A RELAY

A relay transmits: “The client wants RAG.”

A senior technical leader translates: “The client needs authorized employees to retrieve current, authoritative information faster. Here is why retrieval fails today. Here are the quality and security boundaries. Here are the prerequisites. Here are the viable technical approaches and their tradeoffs. Here is how we will measure success.”

That translation requires competence on both sides: business objectives, user needs, commercial constraints, risk, and executive expectations on the client side; architecture, data, security, dependencies, and sequencing on the engineering side. The value comes from preserving the business intent while translating it into engineering terms.

Engineering should receive requirements that express what must become possible. The client should receive a proposed solution traceable back to the business condition that justified spending money on it. That traceability is what turns technical consultation into technical leadership.

TURN DISCOVERY INTO A REPEATABLE PRACTICE

Examine every client request through nine questions.

Business Condition. What is happening today that caused this request to exist? Workarounds and repeated escalations are especially useful evidence.

Impact. What does the condition cost in time, money, capacity, risk, or customer experience?

Users and Workflow. Who experiences the problem, and how does the work actually happen? The gap between documented and actual process often contains the most important finding.

Desired Outcome. What must become measurably different? Deployment is not the outcome.

Readiness. What must be true across people, process, data, governance, and technology for the outcome to occur? Missing prerequisites belong in scope and sequencing.

Constraints. What security, regulatory, financial, architectural, and operational boundaries apply?

Success Measurement. What evidence would demonstrate that the original business condition improved? Define it before implementation so deployment cannot become a substitute for success.

Requirements. Given the outcome, readiness, constraints, and success criteria, what must the resulting capability demonstrably make possible?

Solution Fit. Only now ask what engineering should build. Treat the client’s requested solution as an informed hypothesis to evaluate against everything discovery established.

Before discussing architecture, write the request at the top of the page. Then ask three questions:

What is happening today that caused this request to exist?

What becomes measurably different if we solve it?

What must be true inside the organization for the solution to produce that change?

Do not finalize scope until those questions produce three things: a clear statement of the current business condition, a measurable definition of what must change, and requirements and prerequisites that describe what the solution and organization must make possible.

A client request deserves respect because it contains knowledge, and investigation because it also contains assumptions. The technical leader’s job is to preserve the client’s objective while testing those assumptions before they harden into scope.

So when the next client arrives with a solution already in mind, do not begin by challenging it. Trace it backward. Find the condition that produced the request, define what must change, establish what must be true for that change to occur, and then determine whether the proposed solution fits.

A request is evidence. Discovery turns that evidence into requirements. Then engineering knows what is worth building.

Your New TPM is Navigating Uncharted Waters

Leave a Comment