Strategy · 14 min read · October 16, 2026
Before You Build the Plan, Test What Could Break It
Why senior leaders should challenge their most consequential assumptions before committing time, money, and organizational capacity.

Imagine your task is to get a monkey to juggle while standing on a pedestal.
What would you do first?
I recently posed this question to a leadership team. Several people went straight to the pedestal. They could picture how to build it, what materials they would need, and how quickly they could get it done. Others hesitated. They were not sure where they would even find a monkey.
I reassured them that getting a monkey was possible.
I was born and raised in India, where trained monkeys performing in public places were once a familiar sight, though thankfully far less so today. That may be why finding a monkey seemed less improbable to me than to others in the room.
What one person sees as the obvious obstacle may barely register for another. That is one reason I value different perspectives in strategic conversations, particularly before a team becomes attached to a plan.
Then someone leaned forward and said, with real energy, something like: “Then let’s find out whether we can actually teach the monkey to juggle!”
That is where the strategic thinking began.
What this article explores
Effective strategic planning starts by identifying what must be true for a strategy to succeed. Senior leaders can reduce execution risk by testing the most consequential, uncertain assumptions before investing heavily in implementation. Using the monkey-and-pedestal metaphor, this essay outlines four practical steps: test the strategy’s logic, identify critical assumptions, design meaningful experiments with agreed decision criteria, and sequence implementation around what the organization needs to learn.
Why we are drawn to building pedestals
I first encountered the monkey-and-pedestal metaphor in Annie Duke’s book Quit: The Power of Knowing When to Walk Away. Duke draws on the work of Astro Teller, who leads X, Alphabet’s innovation laboratory, often called the moonshot factory.
Teller’s premise is simple. You want a monkey to perform an extraordinarily difficult task while standing on a pedestal. In his original version, the monkey recites Shakespeare; with the leadership team, I used juggling.
You need two things: a trained monkey and a pedestal.
Building the pedestal is relatively straightforward. You know how to do it. You can estimate the materials, assign responsibility, agree on milestones, and demonstrate progress.
Teaching the monkey to perform is the part you do not yet know how to accomplish.
Yet many organizations begin with the pedestal.
It is understandable. Leaders and teams want to make progress. They face legitimate expectations from boards, colleagues, employees, funders, and the people who depend on their services. Showing tangible movement helps maintain confidence. It also gives people something concrete to organize around.
The project has a charter, a governance structure, a steering committee, a communications plan, and a dashboard. People are working hard, reporting milestones, and meeting deadlines. None of that necessarily establishes whether the central idea is achievable.
The pedestal is coming along beautifully. Nobody yet knows whether the monkey can juggle.
Consider Toronto’s Eglinton Crosstown LRT, a project familiar to anyone who has spent years navigating construction along Eglinton Avenue.
The line finally began carrying passengers on February 8, 2026, about six years later than originally planned and more than $1 billion over budget.
The tunnels, stations, and tracks were substantial, visible achievements. Yet the project also had to demonstrate that its infrastructure, vehicles, signalling, and operating systems could function reliably together. Testing and commissioning revealed problems that had to be resolved before passengers could use the system.
The Crosstown’s history is complicated. Contractual arrangements, construction challenges, quality issues, and the handover between organizations all played a part. It would be unfair to attribute the delays and cost overruns to one sequencing decision.
Still, the project offers a useful illustration of the distinction between completing visible components and demonstrating that an integrated system can deliver what was promised.
The same challenge appears on a much smaller scale in organizations every day.
A new operating model is designed before anyone has established whether the required decisions can actually be made across departments. A digital transformation program invests in technology before testing whether the necessary data can be trusted. A leadership development initiative is launched without examining whether participants will have the opportunity, support, or authority to practise what they learn.
Each has a pedestal and a monkey. The question is whether leaders know which is which. I have written elsewhere about middle managers and strategy execution, and about what happens when the people closest to the work can see a flawed assumption but lack the authority to act on it.
1. Test the logic of your strategy before planning the work
Start with a question that sounds almost too simple:
A.G. Lafley, Roger Martin, Jan Rivkin, and Nicolaj Siggelkow describe this approach in their Harvard Business Review article, “Bringing Science to the Art of Strategy,” drawn from strategy work at Procter & Gamble. Their argument is that strategy becomes more rigorous when leaders treat possibilities as hypotheses to be tested, rather than turning preferred choices straight into detailed plans.
Suppose a healthcare organization has decided to launch a shared data platform to support AI adoption.
The plan might begin with selecting a technology partner, establishing governance, recruiting a project team, and announcing implementation milestones. All of these are reasonable.
But what must be true for the strategy to deliver its intended value?
Perhaps the data required by different departments must be sufficiently reliable and compatible to be brought together. Perhaps clinicians and managers must trust the outputs. Perhaps the AI tools need to fit into existing workflows closely enough that people will actually use them. Perhaps the organization needs capabilities it does not yet have.
Some of those conditions may already be well established. Others may be hopeful assumptions disguised as implementation tasks.
Writing them down changes the conversation. Instead of asking only what needs to be done, the team starts asking what it needs to learn.
Before turning your next strategic priority into a workplan, ask the team to finish this sentence:
“For this to work, we are assuming that…”
Keep going until the important assumptions are visible.
2. Find the assumption that could make everything else irrelevant
Once the assumptions are on the table, the next challenge is deciding which one deserves attention first.
The familiar game of Jenga offers a useful parallel. Some blocks can be removed without affecting the tower. Others are supporting so much weight that removing them brings the structure down.
Strategic assumptions differ in much the same way.
Two questions help identify the ones that matter most:
- If this assumption is false, does our strategy fail, or would we merely need to adjust the plan?
- How confident are we that it is true, and what evidence supports that confidence?
The assumptions with the greatest consequences deserve the closest scrutiny. Among them, those supported by the weakest evidence are usually the ones worth testing first.
For the AI example, perhaps the greatest uncertainty is not whether the technology exists. It may be whether the people expected to use it can incorporate it into their daily work without increasing their workload or compromising their professional judgment.
If that condition fails, an impressive technical implementation may produce little of the intended benefit.
A negative result would not necessarily mean abandoning AI adoption. It might mean reconsidering the tool, redesigning the workflow, or changing the intended use. What matters is learning this before the organization has invested heavily in an implementation approach that assumes adoption will follow.
Another useful exercise is to ask the team to imagine that it is a year from now and the initiative has disappointed everyone. What happened?
Perhaps adoption was low. Perhaps a critical partner did not cooperate. Perhaps the expected savings depended on changing a process that nobody had authority to change.
Imagining failure has already happened can surface risks that are easier to name before the organization has publicly committed to a particular path.
Hear also from the people who will carry the strategy into the work. A senior executive may see a technical challenge as the greatest uncertainty, while a middle manager recognizes that the initiative depends on capacity that has already been committed elsewhere.
The purpose is to find the uncertainty that most deserves testing, rather than simply the concern mentioned most loudly or most often.
3. Design the smallest meaningful test, and agree on what the result will mean
Once the team has identified its most consequential assumption, there is a temptation to launch a large pilot.
But a pilot can become another pedestal if it is designed mainly to demonstrate activity.
A useful test answers a specific question.
For the AI initiative, perhaps the question is whether a particular clinical or administrative team can use the proposed tool consistently within its existing workflow.
Rather than committing to an organization-wide rollout, the team might test it in one setting, with a defined group of users and a limited learning period.
Before beginning, agree on what would count as encouraging evidence, what would require redesign, and what would justify stopping.
Annie Duke describes this kind of advance commitment through kill criteria. I prefer to think of it as agreeing on an off-ramp before the journey becomes expensive.
Off-ramps take three decisions:
- Name the signal. What observable result would suggest that a critical assumption is not holding?
- Set the date. When will the team examine the evidence and make a decision?
- Agree on the response. Under what conditions will the team proceed, redesign, run another test, or stop?
For example:
“If fewer than half of the pilot team are using the AI tool weekly by the end of eight weeks, we will pause expansion, examine the reasons, and decide whether the design needs to change.”
The threshold is illustrative, not a universal standard. A meaningful threshold needs to reflect the actual purpose, risks, and context of the initiative.
It is also worth clarifying who has the authority to act on that decision. An agreed off-ramp offers little protection if the team running the test cannot recommend a change without jeopardizing relationships, reputation, or commitments made elsewhere. Senior leaders need to make it legitimate to bring back disappointing evidence, particularly when they themselves sponsored the original idea.
The important principle is to decide how you will interpret the results while you can still discuss them without defending months of effort. It is much harder to have that conversation once public promises, committed budgets, established positions, and careers are tied to the initiative.
A disappointing test can be a valuable result. It may prevent the organization from investing further in an approach that needs to change.
4. Sequence the work around what you need to learn
Once the critical assumptions are clearer, the team can sequence the work around what it needs to learn first.
Ask what the team needs to do to test it, and what work can reasonably wait until the result is known.
Governance, project charters, dashboards, procurement, communication, and detailed implementation planning may all be essential. Their value depends partly on timing.
There is little benefit in building an elaborate implementation apparatus for something that may prove infeasible.
Sometimes, of course, a piece of preparatory work has to come first. A privacy agreement may be needed before data can be tested. A clinical pilot may require ethics approval, safeguards, or operational permissions. A minimum governance structure may be necessary to protect patients, employees, or the organization.
The answer is to do enough of that work to enable a responsible test, without automatically committing to everything that would be needed for full implementation.
A team that learns early can direct its resources toward approaches with a stronger basis for success. A team that postpones the difficult questions may accumulate commitments before discovering that its assumptions were weak.
For leaders who want to apply this thinking to a current priority, I have a free interactive resource, Translating Strategy to Impact. It walks through the logic of a strategic idea before moving into execution planning.
What finding the monkey first makes possible
The benefits extend beyond avoiding failed projects.
It improves the quality of strategic thinking. Teams become more precise about what they know, what they believe, and what they need to learn. Disagreement becomes more productive when people can examine an assumption rather than defend or reject an entire proposal.
It reduces unnecessary work. Once the team knows what must be tested first, it has a legitimate reason to defer other workstreams. That matters in organizations where every new initiative competes for the same limited attention, capability, and capacity.
It protects resources. Discovering a serious problem after a small test is usually preferable to discovering it after a substantial implementation investment. The test still costs something, but it can prevent much greater expenditure.
It makes stopping or changing direction easier. The longer an initiative continues, the harder it can become to reconsider. Time, money, reputation, and relationships become attached to the original decision. Agreeing on evidence and decision points early gives leaders a more credible basis for changing course.
This approach has limits. Not every strategic uncertainty can be resolved through a small, inexpensive experiment. Some systems can only be properly tested once major components are integrated. Others involve obligations, long time horizons, or dependencies that cannot be reproduced in a pilot.
The principle still applies: identify the uncertainty as early as possible, learn what you reasonably can, and be explicit about what remains unproven. An early test may reduce risk without eliminating it.
The better question to ask before you begin
I keep coming back to that moment in the leadership team conversation. The person who leaned forward and suggested testing whether the monkey could juggle had not suddenly acquired a sophisticated new strategic planning technique. They had recognized that the team was about to organize itself around the part of the problem it already knew how to solve.
That is an easy pattern to fall into, particularly for capable leaders who have built their careers by making things happen. There is real satisfaction in seeing work advance. A new structure takes shape. Milestones are achieved. People begin delivering against the plan.
Before your next planning meeting moves into milestones, owners, and timelines, I would invite you to ask four questions:
- What is our monkey?
- What are we building right now that will only matter if the monkey can juggle?
- What is the smallest meaningful test we could run in the next 30 days?
- What result would make us reconsider, redesign, or stop?
The first question may change the rest of the meeting. It may also prevent your team from spending months delivering work that depended on an assumption nobody had tested.
For leaders already asking more of their people than they would like, that is a consequential difference. If your team is carrying a strategy it has not yet tested, this is exactly the kind of conversation I facilitate through executive and leadership team coaching.
Frequently asked questions
What does it mean to test strategic assumptions?
Testing strategic assumptions means identifying the conditions that must be true for a strategy to succeed and gathering evidence about them before committing substantial resources. Leaders prioritize assumptions that could seriously undermine the strategy if proven false.
What is the monkey-and-pedestal framework?
The monkey-and-pedestal metaphor, associated with Astro Teller and discussed by Annie Duke, distinguishes the difficult, uncertain part of an initiative from the relatively straightforward work. Leaders are encouraged to investigate the difficult uncertainty before investing heavily in the easier components.
How can leaders identify critical strategic assumptions?
Start by asking, “What would have to be true for this strategy to succeed?” Then examine each assumption for its consequences if false, the strength of available evidence, and whether it can be tested before major investment.
What are kill criteria in strategic planning?
Kill criteria are predefined conditions that indicate when an initiative should be stopped, redesigned, or reconsidered. They typically establish an observable signal, a review date, and the decision that will follow if the expected outcome is not achieved.
How can executives reduce strategy implementation risk?
Executives can identify critical uncertainties early, test them through proportionate experiments, establish decision criteria before testing, involve the people responsible for implementation, and sequence investment around what needs to be learned.
References
Duke, A. (2022). Quit: The power of knowing when to walk away. Portfolio.
Lafley, A. G., Martin, R. L., Rivkin, J. W., & Siggelkow, N. (2012). Bringing science to the art of strategy. Harvard Business Review, 90(9), 56–66.