Why projects fail before any code

The dominant cause of failed AI projects isn't bad models or buggy code — it's building the wrong thing: solving a problem the client didn't really have, automating a process that shouldn't exist, or shipping a technically-impressive demo nobody adopts. As a builder you now can build almost anything; the scarce, valuable skill is deciding what's worth building. That decision happens in discovery — and getting it right is where a consultant earns their fee.

The trap to avoid on both sides: a solution looking for a problem. "We want a chatbot / an AI agent / to use GPT" is a solution statement. Your job is to get underneath it to the actual business problem — and sometimes to conclude that AI isn't the answer at all (which builds more trust than selling a doomed build).

Discovery: get to the real problem

Discovery is structured conversation with the people who have the problem. Your goal is to surface the underlying business problem, its cost, and who feels it — before discussing any AI. A reusable question set:

• Problem & impact — "What's the painful, repetitive, or slow thing here? What does it cost you (time, money, errors, missed revenue)? How do you handle it today?"
• Who & frequency — "Who does this, how often, and how long does it take? What happens when it goes wrong?"
• Success — "If this were solved, what would change? How would you measure that it worked?"
• Constraints — "What data exists and where? What can't change? Any compliance/security limits (Track 6)?"
• Why now / why not before — "What have you already tried? Why hasn't it been solved?"

Notice none of these mention AI. You're mapping the job to be done and its value. Only once the problem and its cost are clear do you ask whether AI is the right tool.

Separate the problem from the solution

Clients arrive with solutions; you translate back to problems. This reframing is the heart of discovery:

Client says (solution)	Real problem to uncover
"We want a chatbot on our site"	Support is overwhelmed? Users can't find answers? Which questions, how often, what cost?
"We need an AI agent to automate this"	Which specific, repetitive task? What does doing it manually cost today?
"We want to use GPT for our data"	What decision or output do you need from that data that you can't get now?

For each, the reframe converts a shiny-object request into a measurable problem you can size and solve — or decline. Often the reframe reveals the best solution isn't the one they asked for (a better FAQ, a search box, a fixed process, or a small automation instead of an agent — the code-vs-no-code judgment from Track 4).

Feasibility: is this even an AI problem?

Before scoping a build, sanity-check feasibility across a few axes — this is where you save the client (and yourself) from a doomed project:

• Is it an AI problem at all? Deterministic rules, a database query, or a fixed workflow may solve it better, cheaper, and more reliably. AI shines on fuzzy, language/pattern, or judgment tasks — not on things a WHERE clause handles.
• Is the data/context there? RAG needs a real knowledge source; a classifier needs examples; an agent needs reliable tools/APIs. No data, no project (or a data project first).
• Is the error tolerance realistic? LLMs are probabilistic (Track 5). If the task demands 100% correctness with no human in the loop, reset expectations or add verification/HITL — or decline.
• Is the value worth the cost? Rough the ROI early (next topic) — a technically-feasible project with no business case shouldn't ship.

The honest feasibility call — including "AI isn't the right tool here" — is a trust-builder and a differentiator. Most vendors sell the build; a consultant who sometimes says "don't" earns the relationship.

Scope a narrow first slice

Once you've confirmed a real, feasible, valuable problem, resist the urge to boil the ocean. Scope a small vertical slice that delivers value and de-risks the rest — the MVP thinking from lean/agile applied to AI:

• Narrow the surface — one workflow, one user group, one document set — not "automate everything."
• Deliver end-to-end value — a thin but complete slice (real input → real output the user acts on) beats a broad half-built platform.
• De-risk the unknowns first — build the part most likely to fail (retrieval quality, a flaky integration) early, so you learn cheaply.
• Define done — the measurable success criteria from discovery, so "done" isn't a moving target.

A tightly-scoped first project that ships and works earns the next one; an ambitious one that stalls ends the engagement.

The paid-diagnostic wedge

For a consultancy, discovery is not free pre-sales — it's a productizable, paid engagement: an operational diagnostic that maps the client's processes, surfaces the highest-value automation/AI opportunities, and hands them a prioritized roadmap. It's valuable on its own (they keep the roadmap even if they build elsewhere), it qualifies serious clients, and it naturally converts into the build. Selling "let's find the right problem first" is both better consulting and a better business model than jumping to a fixed-price build on a half-understood ask.

Pitfalls

• Accepting the solution as the brief. "Build us a chatbot" is a solution — reframe to the problem or you'll build the wrong thing.
• Skipping feasibility. Committing before checking data availability, error tolerance, and whether it's even an AI problem leads to doomed builds.
• Never saying no. Selling a build you know won't deliver burns trust; an honest "don't" differentiates you.
• Boiling the ocean. A broad first scope stalls — ship a narrow, complete slice and expand.
• Undefined success. Without measurable criteria from discovery, the project can't be judged done or successful.

Recap

• Most AI projects fail at problem definition, not engineering — the scarce skill is deciding what to build.
• Discovery surfaces the business problem, its cost, and owner before any AI talk; clients bring solutions, you reframe to problems.
• Assess feasibility — is it an AI problem, is the data there, is error tolerance realistic, is it worth it — and be willing to say AI isn't the answer.
• Scope a narrow, complete, de-risked first slice with measurable success criteria — ship, then expand.
• Package discovery as a paid diagnostic — better consulting and a better business model than pricing a half-understood build.
• Worked examples map to the exercises: a discovery question set (Ex 1), problem/solution reframes (Ex 2), feasibility checks (Ex 3), scoping a first slice (Ex 4).