TAG Weekly Roundup #11

Editor's Note

Google's "Monkeys and Pedestals" mental model reveals why smart teams build the wrong things: they tackle easy problems first instead of identifying the hardest constraints. 

The mental model forces a simple question—can you actually solve the core challenge, or are you just building impressive solutions to avoid the difficult bits? 

Software projects fail at alarming rates, but rarely for the reasons teams expect. 

Recent Forbes research reveals that most failures stem from poor requirements gathering and disconnects between technical and business teams e.g. building complex features without proving core value. Sound familiar? 

You're building pedestals while ignoring whether anyone can actually train the monkey.

The Mental Model Explained

Annie Duke's research for Behavioral Scientist highlights a mental model from Google's X division, led by Astro Teller: "Monkeys and Pedestals.

Imagine training a monkey to juggle flaming torches whilst standing on a pedestal in a public park. 

Two components: 

• Building the pedestal (easy) and 

• Training the monkey (the genuine constraint).

Teller's insight: tackle the hardest part first. Don't build pedestals if you can't train the monkey.

Real-World Application: X's Hyperloop Decision

When X evaluated hyperloop technology:

• The Pedestal (easy bit): Building track infrastructure—straightforward engineering

• The Monkey (hard constraint): Passenger safety, loading systems, braking at speed

• The Problem: You'd need to build the entire system before knowing if core challenges were solvable

• The Decision: They walked away immediately

This Isn't Just MVP Thinking

An MVP and Monkeys and Pedestals solve different problems.

MVP helps you build efficiently once you know what to build. Monkeys and Pedestals helps you decide whether to build at all. Additionally, whilst MVP builds the minimum to test, Monkeys and Pedestals identifies the hardest constraint first.

Kill Criteria: Your Early Warning System

X's framework includes "kill criteria"—predetermined signals that trigger project termination. The best criteria combine state and time - "If we haven't achieved X by date Y, we quit."

Applied to software development: "If user adoption doesn't reach 20% by month three, we pivot." Or: "If core API response time exceeds 200ms after six weeks of optimisation, we redesign."

The power lies in making these decisions when thinking rationally, not during emotional moments when sunk costs cloud judgment.

Common Sense Rarely Applied

This framework represents basic common sense - identify the hardest constraint, test it first, know when to quit. Yet teams repeatedly build complex features whilst ignoring fundamental business validation.

Why don't we apply common sense? Because admitting a project should die feels like failure rather than smart resource allocation.

Whether you're a BA, Product Manager, or running programmes, this framework cuts through the noise - Are we solving the right problem, or just building impressive solutions nobody needs?

Sources: Annie Duke - Behavioral Scientist | Forbes Technology Council

Till next week.