How to Fail at AI Strategy

Hamel Husain, Independent consultant, Greg Ceccarelli17:03 · Apr 2025 · 6,484 views
Thumbnail for How to Fail at AI Strategy Watch on YouTube
TL;DR
  1. 1

    AI strategies fail when executives and practitioners work in silos and use different language for the same customer problems.

  2. 2

    A vague diagnosis, an enormous plan, and untested projects can keep an organization busy without producing useful AI systems.

  3. 3

    Teams should connect evaluation to business outcomes, inspect their data, and involve domain experts and users instead of trusting tools or intuition alone.

Summary

Hamel Husain and Greg Ceccarelli present an inverted guide to AI strategy. Their examples describe how to create failure by separating executives from practitioners, promising customers that AI will do everything, buying expensive infrastructure without cost analysis, and building systems that nobody can explain. They recommend vague goals, huge documents, jargon, perpetual beta, and projects assigned to people without relevant experience. The talk also attacks tool-first problem solving. Replacing a vector database, changing an agent framework, or collecting every available evaluation metric does not show that a system works. Husain and Ceccarelli argue that teams need to examine real data, ask whether metrics match business outcomes, and include domain experts and users. Their examples are deliberately comic, but the underlying warning is direct: technical language and impressive dashboards can hide the absence of a useful product or a clear understanding of the work.

Key ideas
02:11

Silos make AI strategy disconnect from the people who do the work

The first failure mode is to divide the company and keep information inside teams. The speakers tell the audience to attend AI conferences but never bring the lessons back to colleagues. Their parody of the value stick replaces willingness to pay with wishful thinking, price with unnecessary infrastructure spending, and value with the explanation "because AI." They recommend expensive GPUs without cost-benefit analysis and systems so tangled that executives cannot understand them. The result is a disconnect between what customers might pay for, what systems cost, and what the organization can actually build.

04:51

A vague diagnosis and an endless plan can look like strategy

To fail at strategy, the speakers suggest highlighting random passages in last year's annual report and declaring them problems without speaking to the people doing the work. The guiding policy should be a statement such as "become the global AI leader in everything," with no definition of "everything." The action plan can include unrelated projects, such as an AI SEO tool, a generative art plug-in for NFTs of a CEO's cat, and an AI drone lunch service. They also recommend perpetual beta, a huge GitHub backlog, and a 4,000-page document posted across Slack.

06:39

Jargon keeps domain experts away from AI projects

The speakers recommend communicating in language that sounds technical while making the work hard to understand. Greg gives an intentionally overloaded example involving multimodal agentic Transformer systems, few-shot learning, chain-of-thought reasoning, and hyperparameters. Husain describes a mental health client that called prompt writing "building agents." That wording made it harder for mental health experts to join the discussion. They give similar examples: call adding context "RAG" and describe harmful instructions as "prompt injections." The language can make ordinary work appear out of reach to the people who understand customers.

09:16

Untested deployment and poor staffing turn projects into incidents

For mobilization, the speakers invent a "zoning to lose" framework. One recommendation is to assign AI work to people with little relevant experience, such as offshore quality-assurance teams that lack business context. Another is to launch untested, bug-filled chatbots directly to customers from an incubation group. The advice is to skip beta testing and quality assurance. They also suggest pulling the best engineers away from revenue-producing products. In the talk's deliberately extreme version, the organization moves from disorganization to a career-ending public relations problem.

10:43

Tool-first problem solving hides the original process problem

Once the organization is disorganized, the speakers advise focusing on tools instead of processes. If a retrieval system returns the wrong documents, buy a more expensive vector database. If an agent fails, choose a new framework or vendor and fine-tune without measurement. This treats each problem as something a tool can remove without examining the workflow, data, or design. The speakers compare the approach to alchemy with more electricity. Their point is that changing technology does not explain why the system failed or establish that the replacement will work.

12:12

A dashboard full of generic metrics can create false confidence

The talk attacks the idea that evaluation belongs entirely to vendors. The failure recipe is to use every off-the-shelf metric, regardless of whether it matches business outcomes or real failure modes. Teams should keep collecting numbers until one trends upward, then claim success. Husain names cosine similarity, BLEU, and ROUGE as metrics that can be optimized while ignoring user experience. The speakers also recommend accepting evaluation-framework defaults without asking what success means for the business. A large dashboard can therefore make results harder to interpret rather than easier.

13:45

Data inspection and domain knowledge cannot be delegated away

The final failure mode is refusing to look at data. Leaders are told to trust AI output without checking it and to treat data inspection as an engineering problem. The speakers mock the idea that developers can handle everything even when they have not spoken to customers for years. They also warn against preventing anyone else from inspecting data. A simple spreadsheet or Airtable may be enough for annotation and review, but an executive can instead buy a complex platform that only engineers can use. This blocks domain experts and can take months before the system is usable.

"The point just like Moses here parting the red sea is to create impenetrable silos and incentivize secrecy between your teams."02:58
Who should watch
  • Executives who are setting AI priorities and need to see how vague goals, inflated promises, and disconnected planning create waste.
  • AI practitioners who struggle to explain technical work to business and domain experts in terms those colleagues can use.
  • Teams building retrieval or agent systems that rely on generic metrics, vendor changes, or uninspected data instead of user and business evidence.