Pitfalls That Reliably Kill AI Initiatives

These patterns recur across industries and company sizes. Recognising one early is worth more than any technique in this course.

Expecting too much, and expecting too little

Both are fatal, and they often appear in the same organisation.

Too much looks like: expecting AI to solve a problem nobody has defined; expecting a pilot to scale without engineering; expecting a model to be correct rather than accurate; expecting AI to fix a process that is broken for entirely human reasons.

Too little looks like: dismissing AI because an early demo was unimpressive; assuming "that's only for tech companies"; letting a bad first experience close the topic for years; declining to automate genuinely repetitive judgement work because "our business is too specialised" — which is occasionally true and usually not.

The specific pitfalls

1. Hiring engineers with no problem defined. A capable data scientist with no data infrastructure and no specified problem will spend a year building things nobody uses, then leave. Define the problem first.

2. Expecting the model to be the product. Covered in module 2, and it remains the most common structural failure: a model with no path to the point of decision.

3. Starting with the hardest problem. It is the most valuable, which is why it is tempting, and it is where you have the least chance of succeeding while you have the least experience.

4. No baseline. Without knowing what humans or a simple rule achieve, nobody can say whether the project worked, and the conversation becomes political.

5. Ignoring the people whose work changes. Lesson: trust is a deliverable. A system the affected team does not believe in will be worked around.

6. Treating a vendor demo as evidence. The demo is the good weather.

7. Nobody owns it after launch. Models drift. Unowned models rot quietly, and the failure is usually discovered by a customer.

8. Scaling faster than validation. The most dangerous of all, because it converts a technical limitation into a financial one.

Zillow, the American property company, ran a business called Zillow Offers: it used an algorithmic valuation to make fast cash offers on homes, bought them, and resold them. The model — estimating a property's price from its characteristics — is the textbook machine learning problem from module 1, and Zillow had more housing data than almost anyone.

In November 2021 Zillow shut the business down. It laid off roughly a quarter of its workforce, took a $304 million write-down on inventory, and total losses exceeded $500 million. Chief executive Rich Barton attributed the failure to the model's inability to predict home prices accurately enough.

The detail that makes this a management lesson rather than a technical one is the timing. Up to 2020 Zillow bought a fairly steady number of homes each quarter. Then in 2021 it roughly doubled purchases from the first quarter to the second, and doubled again into the third. The scale-up happened into a volatile market, on the strength of a model whose error had not been proven at that volume under those conditions.

Three transferable lessons:

Prediction error becomes financial exposure at scale. A valuation model that is off by a few percent is an academic curiosity when you buy ten houses and a catastrophe when you buy thousands. Small per-unit errors multiply by volume, and they do not average out when the error is biased — systematically overpaying is not cancelled by buying more.

A model validated in stable conditions is not validated for unstable ones. The training data described one market. The market moved. This is model drift from module 2, arriving at the worst possible moment and at maximum exposure.

Ask "what is our exposure if this model is systematically wrong?" before scaling, not after. Not "is it accurate", but: if it is biased in one direction, how much do we lose, and how quickly would we notice? For most internal projects the answer is small and reversible. Where a model's output commits real money on every prediction, the answer needs to be worked out in advance.

Zillow was not naive, under-resourced or short of data. That is precisely why the case is worth knowing: this failure mode does not require incompetence, only speed.

Warning signs

Symptoms that an initiative is drifting, in roughly the order they appear:

Nobody can state the input and output in one sentence.
The success metric has never been written down, or changes between meetings.
The project has been "nearly ready to deploy" for more than two months.
The technical team and the business team meet only at steering committees.
The people whose work will change have not been consulted.
Discussion is about which model to use rather than what decision will change.
A pilot succeeded and rollout has stalled with no named blocker.

❓ Knowledge Check

Zillow Offers doubled home purchases twice in 2021 before shutting down with over $500 million in losses. What is the transferable management lesson?

📚 Flashcards1 / 5

Term

Expecting too much

Click to flip

Definition

Undefined problems, pilots assumed to scale without engineering, models expected to be correct rather than accurate, and AI expected to fix processes broken for human reasons.

Click to flip back

💡Key Takeaway

The recurring killers are organisational, not technical: hiring before defining the problem, mistaking a model for a product, starting with the hardest case, having no baseline, ignoring the people affected, and leaving nothing owned after launch. The most expensive is scaling faster than validation — as Zillow's $500 million shows, small prediction errors become large financial ones at volume, and a model proven in calm conditions is not proven in turbulent ones.