Three Times Lucky

What Three Times Lucky Actually Is

Three Times Lucky is a repetition-based decision filter. The premise is straightforward: before committing to any meaningful choice — hiring someone, launching a campaign, adopting a new tool, entering a partnership — you deliberately run through the same evaluation three separate times, each under different conditions or on a different day. The goal is to separate signal from noise in your own judgment. I stopped treating it as a novelty after my third or fourth cycle where the outcome clearly diverged from what I had decided on day one. The method itself is not complicated. What trips people up is the execution, specifically how you structure those three passes so they actually give you information instead of just repeating the same bias three times.

Why the Name Matters for Implementation

The "Three Times Lucky" label comes from a folk idea that luck follows a pattern, but the practical framework has nothing to do with superstition. It is about creating temporal distance between evaluation moments so that emotional fatigue, recency bias, and sunk-cost pressure lose their grip. When you force yourself to revisit a decision after a real interval — not five minutes, not the same meeting — your brain processes the same data differently. That difference is the whole point. I have used this for vendor selection, product feature prioritization, and yes, even personnel decisions. The method works best when you are uncertain and overstimulated. It does not help much when the decision is trivial or when you already have complete information.

How to Run a Proper Three Times Lucky Cycle

First, write down the decision as a single clear sentence. If you cannot state it in one line, you do not understand the decision well enough to apply this method. "Should we move our email deliverability infrastructure to a new provider?" is a valid statement. "Should we maybe think about improving our outreach?" is not. Pass one: Evaluate the decision exactly as you would normally, with no special constraints. Record your conclusion and the top three reasons supporting it. Do this within a single focused session. Most people spend twenty to forty-five minutes here depending on decision complexity. I typically cap mine at thirty minutes because beyond that I start rationalizing instead of deciding. Pass two: Wait at least twenty-four hours. Then re-read your original conclusion and reasons, and evaluate the same decision again from scratch. Do not look at your first pass notes until after you have written your second conclusion. Record your new answer. This is where most of the actual value lives. You will often find that your reasoning has shifted in ways you did not expect, usually because you have had time to recall details you initially glossed over or because the initial emotional charge has faded.

Pass three: Wait another twenty-four to forty-eight hours. Repeat the same process. By now you should have three conclusions. If all three match, you have a high-confidence decision. If two match and one diverges, the outlier is worth investigating rather than immediately discarding. If all three differ significantly, you do not have enough information to decide yet, and that is useful information in itself.

Where the Method Breaks Down

I ran into a concrete edge case last year that exposed a real limitation. We were evaluating a new analytics dashboard for a client project. On pass one, I was leaning toward Tool A. On pass two, after a full day of sleep, I had strongly shifted toward Tool B. On pass three, I was back at Tool A but with weaker reasoning than before. I spent roughly three hours going in circles across the three passes because the core trade-off was actually environmental: Tool A performed better in staging but Tool B handled production load better, and I had not separated those two contexts during my evaluation. The workaround was simple and I wish I had done it earlier. Before pass one, I split the evaluation criteria into distinct categories: development experience, production performance, cost structure, and support quality. I scored each option independently within each category. Once I forced that separation, pass two and pass three both converged on the same answer without the back-and-forth. The method did not fail. My initial categorization was just sloppy enough to manufacture false ambiguity. Another hard boundary: this does not work for time-sensitive decisions where waiting twenty-four hours between passes causes real damage. If a vendor lock-in deadline is forty-eight hours away, running three passes is actively harmful. In those cases, use a condensed two-pass version with only a four-hour gap instead, and accept that your confidence ceiling is lower.

Common Mistakes That Waste the Whole Exercise

The most frequent error I see is treating the three passes as confirmation loops rather than independent evaluations. If you read your first conclusion before writing your second, you have not actually created distance. You have just rehearsed your original bias. The temporal gap is meaningless if your brain is just reinforcing the same neural pathway each time. A second mistake is varying the decision itself between passes. "Should we hire Sarah?" on pass one and "Should we hire anyone from the marketing pool?" on pass two are not the same question. Keep the decision statement identical across all three rounds. Only your assessment of it should change. A third mistake is stopping too early. Some people run one pass, wait a day, run a second pass, see a clear winner, and call it done. That is two-time lucky, not three. The third pass exists specifically to catch the decisions where your second pass introduced a new blind spot. Skipping it means you only have two data points, and two is rarely enough to override your initial instinct reliably.

When to Skip It Entirely

Small decisions do not earn the overhead. Picking a meeting time, choosing a color scheme for an internal document, deciding which library version to bump by one minor release — these do not need three cycles. The method starts paying for itself around decisions that involve irreversible commitment, significant budget, or structural impact on a team. Below that threshold, you are spending time you could use elsewhere for marginal accuracy gains. High-uncertainty decisions with incomplete data also suffer from diminishing returns. If you lack basic information to evaluate the options in pass one, waiting two days will not magically produce that information. In those cases, the productive move is to run an information-gathering sprint first, then apply the three-pass filter once you actually have something to evaluate. I use this framework regularly and I have seen it catch bad decisions that felt right in the moment. It has also been useless more than once when applied to decisions that were poorly defined to begin with. The tool does not fix unclear thinking. It only reveals it more slowly.