TL;DR: The Marshmallow Challenge is a powerful lesson in prototyping before planning, but it teaches exploration within a predefined problem, not innovation as a whole. The customer, desired outcome, success metric and available partners have already been decided. Many organizations make the same mistake: they commit to these upstream assumptions and then judge teams only on execution. Real innovation begins by testing who to serve, what outcome matters and whether building alone is the right approach before resources and reputations become locked in.
The exercise is commonly associated with Tom Wujec because his 2010 TED talk made it widely known. Its origin predates that talk, and Peter Skillman is generally credited with originating it. Skillman says he began running what he called the Design Challenge with IDEO clients, later used it in university lectures and helped introduce it into corporate Design Thinking training through the IDEO University curriculum. He also notes that the exercise evolved with IDEO colleagues Dennis Boyle and Christine Kurjan and that he no longer remembers exactly how its first version arose. He presented it at TED in 2006. What is clear from his account is its original purpose: it was a tool for teaching the value of iteration and revealing how status, ego, vulnerability and interaction affect team performance.[1]
Wujec popularized the exercise and extended its meaning. His materials describe it as a way to help teams build rapid prototype solutions and learn about collaboration, creativity and innovation. They even invite organizations to use it to consider what would dramatically increase innovation and describe the early testing of hidden project assumptions as the mechanism that produces effective innovation.[2]
This evolution is understandable. The exercise demonstrates several behaviors that innovation needs: teams experiment, expose a hidden assumption, learn through interaction and adapt before time runs out. In that sense, it is partly an exercise in innovative thinking.
The problem begins when it is treated as a model of innovation as a whole. It demonstrates how to explore solutions after the challenge has been framed. It does not demonstrate how to discover whether the brief, customer, outcome, metric or decision to build should exist in the first place.
Give a team twenty sticks of spaghetti, one meter of tape, one meter of string and one marshmallow. Ask them to build the tallest freestanding structure in eighteen minutes, with the marshmallow on top.[1]
The Marshmallow Challenge produces a reliable contrast. Many adult teams spend most of their time discussing the ideal structure, allocate tasks and begin building once they believe they have a plan. They test the marshmallow only near the end, when its weight reveals that their imagined structure and the physical one are not the same.
Children and architects tend to do better. They put the marshmallow on early, build small structures, watch them fail and adapt while they still have time. They do not eliminate uncertainty through discussion. They interact with it.
This is why I continue to use the exercise. It makes the difference between planning and learning physically visible. Explore before you commit is a better response to solution uncertainty than plan first and execute later.
But innovation does not start when a team begins building a solution. It starts earlier, when the team investigates whose situation should improve, which outcome matters, what may cause that outcome and whether a solution should be built at all. The Marshmallow Challenge starts after those decisions have already been made.
Before anyone touches the spaghetti, the problem has been defined, the desired output has been specified, the resources have been allocated and the success metric has been fixed. The facilitator has decided that height matters, that every team must work with its own materials and that the teams are competitors. Participants may question how to build the tower. They are not allowed to question the frame around it.
That makes the Marshmallow Challenge an excellent exercise in iterative execution. It does not make it a complete innovation exercise.
The tower is an output, not an outcome
The winning structure must be tall and remain standing long enough to be measured. Nobody has to use it. Nobody needs to make progress because it exists. There is no customer who values height more than stability, portability, surface area or cost. Height matters because the facilitator can measure it with a tape, not because anyone has shown that it is valuable.
That distinction is easy to miss because the activity looks like innovation. Teams build, experiment, collaborate and work under uncertainty. Yet the uncertainty is contained inside a task whose purpose and boundaries are treated as facts.
Several questions remain outside the room:
Who is this structure for?
What are they trying to achieve?
Is height the outcome that matters, or merely the easiest output to measure?
What would make them adopt, use or pay for the result?
Which other actors must participate for the outcome to occur?
Would combining resources with another team create more value than competing with it?
These are not secondary questions to ask after the tower stands. They determine whether the tower is worth building at all.
Innovation contains three different uncertainties
Organizations often speak about uncertainty as though it were one problem. It is more useful to separate at least three kinds.
Discovery uncertainty concerns the opportunity. Who experiences the problem, in which context, how important is it, what progress are they seeking and which assumptions support our belief that an opportunity exists?
Solution uncertainty concerns the response. If the opportunity is real, which intervention could create the required outcome, what will people adopt and how must it fit into their existing behavior and system?
Execution uncertainty concerns delivery. Once the problem and solution are sufficiently understood, can the organization build, operate and scale the solution at the required quality, speed and cost within a business model that creates enough value for all the involved parties?
Each uncertainty requires a different capability. Discovery needs observation, problem framing and evidence about what matters. Solution development needs design, comparison and behavioral tests. Execution needs engineering, coordination and reliable delivery.
The Marshmallow Challenge operates mostly in the last two categories. The opportunity, user, metric and rules are fixed. What remains uncertain is which structure will work and whether the team can build it in time.
Children and architects do not win because they have discovered a better customer or a more important outcome. They win because they explore possible solutions within the given frame and expose structural failure earlier than teams that rely on planning.
That is a valuable capability. It is simply not the whole innovation job.
Most innovation projects are set up the same way
The limitation matters because many corporate innovation programs and startups reproduce the same structure without noticing it.
A team receives a budget, a deadline and a mandate to build an app, introduce an AI assistant, create a platform or enter a market. The mandate already contains assumptions about the customer, the problem and the appropriate response. A roadmap then converts those assumptions into milestones, and progress is measured through delivery: prototypes completed, features released, users acquired or pilots launched.
The team may work in sprints and test early versions. It may be highly agile inside the assignment. But agility does not make the original frame true.
Perhaps the selected users do not experience the problem strongly enough to change their behavior. Perhaps the metric being optimized is easy to count but weakly related to customer value. Perhaps the apparent customer cannot decide alone because procurement, operations, regulators or channel partners can prevent adoption. Perhaps an adjacent team, supplier or external partner has capabilities that make a joint model more credible than an internal build.
If these possibilities were excluded before the project began, the team is not discovering an opportunity. It is improving its execution of an inherited belief.
The organization then judges the team on how well it builds a tower whose purpose, user and rules it was never allowed to question.
Agile cannot rescue the wrong frame
Steve Blank distinguished a startup searching for a repeatable business model from an established organization executing one it already understands.[3] Eric Ries translated this search logic into Build-Measure-Learn.[4] Both challenged the assumption that detailed planning can remove uncertainty before contact with reality.
The Marshmallow Challenge demonstrates this argument well. Early prototypes reveal something that analysis alone cannot: the marshmallow changes the structure.
But faster iteration is only useful when the experiment addresses the uncertainty that matters. A team can build, measure and learn repeatedly while leaving the customer, outcome and business-model assumptions untouched. It becomes faster at learning inside the wrong frame.
Research on scientific decision-making by entrepreneurs shows why the framing step matters. In a large-scale replication and extension, entrepreneurs trained to articulate theories, make assumptions explicit and design tests around them were more likely to terminate weak projects earlier, make more focused pivots and perform better.[5] The improvement did not come from generating more ideas or running more activity. It came from connecting experiments to explicit beliefs and decisions.
Related work on theory-driven strategic decisions makes a similar distinction. Under uncertainty, the first task is not to select a plan of action but to develop a theory of value: an explicit explanation of why a particular action should produce a valuable outcome. That theory can then be challenged with evidence.[6]
The Marshmallow Challenge begins with the theory already embedded in its rules: tall towers are valuable, isolated teams are the unit of action and the winner is whoever produces the highest output in the given time. Participants test structures, not that theory.
Commitment changes how evidence is treated
This omission becomes expensive once a project gathers momentum.
Budgets, teams, roadmaps, executive sponsors and public promises do more than support delivery. They create attachment to the original decision. As commitment grows, evidence is no longer interpreted neutrally. A negative signal threatens previous investments, internal credibility and sometimes professional identity.
Research on escalation of commitment has documented this pattern across organizational decisions.[7] When a project becomes difficult to abandon, teams often respond to disappointing evidence by defending, reinterpreting or extending the commitment rather than revisiting its underlying assumptions.
The longer a team has been building its tower, the harder it becomes to ask whether height was ever the point.
This is why discovery must precede large commitments. Its purpose is not to prove that an idea will succeed. It is to expose the assumptions that could make the commitment irrational while changing direction is still relatively cheap.
Keep the exercise, but change the conclusion
I will continue to use the Marshmallow Challenge. It remains one of the clearest ways to show why teams should test the load-bearing assumption early, why a prototype can reveal more than a planning discussion and why iteration beats a single late attempt.
I will no longer present it as a model of innovation as a whole.
It teaches teams to explore before committing to a solution, but only after someone else has committed them to a customer, an outcome, a metric, a resource boundary and a competitive structure. Those upstream decisions often determine the fate of an innovation before execution quality becomes decisive.
Real innovation begins one step earlier. Before asking how to build the tower, a team must make the frame around it visible and testable: who is it for, what outcome matters, which evidence would justify building and whether the organization should build alone.
The tower was never the hardest part, understanding why you should build beforehand is.
One question for you: Have you seen a team start building before it understood what it was trying to learn? Reply with the moment you noticed it.
