Throwing spaghetti at the wall to see what sticks is a common English idiom that refers to haphazardly testing multiple random ideas, strategies, or creative solutions to see which one yields results.

In UX and product development, the pattern appears when experimentation loses its connection to a clear problem, hypothesis, or strategy. Instead of deciding what we need to learn and designing an experiment around it, we simply try things.

ORIGIN

The origin of the phrase comes from a simple cooking test: Throw a single spaghetti at the wall and if it sticks, it’s done, but if it fell, it needed more time. The earliest known publication of this method is in the 1946 cookbook “You can cook if you can read”.

Culinary experts consider this a myth, as boiled pasta will stick to a wall regardless of whether it’s undercooked, perfectly cooked, or overcooked. The recommended approach to avoid guesswork is to follow exact boiling times for various cuts of pasta paired with traditional taste test to achieve perfect al dente bite. This method results in reliable outcomes and avoid unnecessary kitchen clean-ups.

Applied to work, it became a metaphor for trial-and-error problem solving – trying many approaches without a clear hypothesis or process, and waiting to see what works.

WHEN

You’ve encountered Spaghetti at the Wall when:

• Experiments don’t have hypotheses
  “We’ll see what happens” is both the research plan and success criterion.

• The roadmap becomes a collection of possibilities
  Lots of ideas with little strategy connecting them.

• Volume replaces direction
  If five ideas haven’t worked, perhaps number six will.

• Success is defined after the fact
  Something moved. Everyone gathers around the analytics to decide whether the movement was good.

• Trends become experiments
  Competitor added AI. We should probably throw some AI at the wall.

• You hear: “Let’s just try it and see what happens.”
  Sometimes perfectly reasonable. Considerably more suspicious the seventh time.

WHY

Throwing spaghetti feels productive because activity is extremely visible. Other reasons include the following:

• Action feels like progress
  Shipping something provides an immediate sense of momentum, even when the direction remains unclear.

• Modern tools make experimentation cheap
  Prototyping and AI-assisted development make it easier than ever to try things quickly.

• Possibilities are difficult to abandon
  Every idea carries the seductive possibility that this one might be the breakthrough.

• Experimentation gets misunderstood
  Trying something isn’t automatically an experiment. Experiments require questions, hypotheses, observations, and conclusions.

• Teams fear committing too early
  Keeping many options alive feels safer than deciding which direction deserves investment.

• Random success can be persuasive
  Something improves unexpectedly, so the team repeats the approach without understanding what caused the result.

HOW

In UX and product design, avoid a messy kitchen approach by following these steps:

• Form a hypothesis
  State what you believe will happen and why. It doesn’t need to be correct. That’s why you’re testing it.

• Define success before the experiment
  Decide what evidence would support, challenge, or reject the hypothesis before seeing the results.

• Vary ideas deliberately
  Explore genuinely different approaches rather than producing twelve cosmetic variations of the same assumption.

• Measure outcomes, not activity
  Measure learning or user value, not just the fact that it was shipped successfully.

• Close the loop
  Every experiment should produce a decision: continue, change direction, investigate further, or stop.

• Keep the strategy visible
  Individual experiments should connect to a larger understanding of the user problem and desired outcome.

PRO TIP

Use research insights to define a UX strategy. Without strategy, everything becomes an unguided and hard to measure experiment.

EXAMPLES

• Launching several features without understanding which user problem they’re intended to solve.
• Running A/B tests without a clear hypothesis or success criterion.
• Adding multiple configuration options simply to “see what users prefer.”
• Shipping a trending feature because competitors have it and watching the analytics afterward for justification.
• Creating five prototypes without defining what differences you’re actually trying to evaluate.
• Repeatedly changing onboarding while measuring adoption without understanding why users abandon it.
• Trying several unrelated ideas simultaneously and then being unable to determine which one caused the change.
• Continuing to iterate because something might eventually work rather than deciding what the team has actually learned.

CONCLUSION

Throwing Spaghetti at the Wall isn’t an argument against experimentation. Product design requires exploration. We prototype because we don’t know. We test because our assumptions may be wrong. We try alternatives because the first idea isn’t automatically the best one.

The problem begins when trying things becomes a substitute for deciding what we’re trying to learn. As a result, you’re generating activity and hoping retrospectively to discover meaning in it. We need intentional direction otherwise it becomes noise.

In the end, something sticking isn’t enough. You need to know why it stuck.