How to Before Assuming the Best Outcome, Ask Yourself, 'what Could Go Wrong (Thinking)

Check Your Optimism (Optimism Bias)

Published By MetalHatsCats Team

How to Before Assuming the Best Outcome, Ask Yourself, "What Could Go Wrong (Thinking)" — MetalHatsCats × Brali LifeOS

At MetalHatsCats, we investigate and collect practical knowledge to help you. We share it for free, we educate, and we provide tools to apply it. We learn from patterns in daily life, prototype mini‑apps to improve specific areas, and teach what works.

We open with a simple scene. It is 08:07. The calendar says “Present to client — 9:00.” Our notes look good. The optimism gut-tug is thick: slides, narrative, the exact phrasing of the opening line. If we assume everything will go well, we skip three small checks: is the projector cable in the room, is the Wi‑Fi password current, and does the time we thought was 9:00 actually match the client’s timezone? If we miss one, the first ten minutes of the meeting will be awkward. If we do a short 'what could go wrong' run, we buy ourselves 15 to 30 minutes of buffer and reduce that awkwardness. That buffer often shifts the experience from friction to competence.

Hack #591 is available in the Brali LifeOS app.

Brali LifeOS

Brali LifeOS — plan, act, and grow every day

Offline-first LifeOS with habits, tasks, focus days, and 900+ growth hacks to help you build momentum daily.

Get it on Google PlayDownload on the App Store

Explore the Brali LifeOS app →

Background snapshot

  • The technique we describe traces to the military and engineering practice of "premortem" and risk assessment, repackaged for everyday decisions. It borrows from cognitive forcing techniques used in aviation and medicine, where short, structured reframes prevent avoidable errors.
  • Common traps: people treat such thinking as pessimism; they either skip it entirely or overpopulate decisions with improbable horrors. Both extremes fail: skipping leaves us blind to common faults; overpopulating saps time and morale.
  • This method often fails when it becomes a ritual checklist without context — we tick boxes but do not change behavior. That happens because we imagine complexity instead of listing actionable responses.
  • What changes outcomes: a short, repeatable pattern that trades vague worry for 3–5 concrete mitigations. When each mitigation is measurable and enacted, contingency thinking improves outcomes in 60–80% of everyday scheduling and planning problems, according to applied team reports in business settings.

This long read is practice‑first. Each section pushes us toward a specific action in the next 10–30 minutes. We will think aloud, tell small stories, make explicit trade‑offs, and end with a compact Hack Card you can copy into Brali LifeOS. We assumed a long, theory-heavy treatise → observed that readers wanted immediate practice → changed to a narrative that alternates lived micro‑scenes and short actions. That pivot matters: if we don’t practice, a new idea is just an unread memo.

Why this helps (one sentence)

  • Asking “what could go wrong?” converts optimistic projection into targeted preparation, typically reducing small but common failures by roughly 50–70% in everyday tasks when followed by one concrete mitigation.

How to start right now (first micro‑task — ≤10 minutes)

  • Pick the next thing you’re about to do (call, meeting, trip to the store).
  • Spend 5 minutes writing: 1) two things that could go wrong, and 2) one action that would reduce the chance of each.
  • Set a single timer for 5 minutes and stop. Move on with the chosen mitigation.

If you have Brali LifeOS open, create a task titled “Premortem: [Task name]” and add two bullet mitigations. If you don’t have Brali open, write on the back of a receipt. The implementation is less important than the done‑ness. ()

Part 1 — The small scene that reveals the method

We stand in the kitchen on a Tuesday morning, rehearsing aloud a short talk while making coffee. The talk is 12 minutes; we have 14 minutes before the train. Optimism says we’ll finish the talk and still make the train. The worry voice lists plausible speed bumps: spill coffee on the laptop, unexpected call, missing bus because platform was moved. We then pick the two most likely and influential problems and choose one concrete mitigation for each: place laptop on the counter away from the kettle; set phone to do-not-disturb and activate auto‑reply; check the train app now and buy a ticket with a one-click buffer.

That mix of micro‑scene + concrete mitigation is the core move of this hack. We start with a short, clear forecast and end with an implementable step we can actually do. Each time we do it, we make the practice faster and the mitigations more precise.

Why five minutes matters

  • We have found that when people allow more than 10–15 minutes to this quick forecast, the exercise falls into two traps: 1) elaboration (we imagine dozens of unlikely things) or 2) avoidance (we rationalize away risk because the exercise feels discouraging). A 3–7 minute limit keeps us focused on the few things that will actually change behavior.

Practice task (right now)

  • Timer 5 minutes.
  • Subject: next task on calendar.
  • Write: 2 likely problems (not 20), and 1 mitigation per problem.
  • Execute at least one mitigation immediately (make the call, set the DND, buy the ticket).

Part 2 — How to choose "what could go wrong" without spiraling

We must be selective: not everything that can go wrong will. We prioritize using two axes: Likelihood and Impact. Imagine a 0–10 scale for each.

  • Likelihood: 0 (no chance) to 10 (very likely).
  • Impact: 0 (no consequence) to 10 (catastrophic for this task).

Pick items scoring above 5 on either axis or above 3 on both. Limit the list to 2–4 items. After we list them, we choose mitigations that cost less than 10% of the task's time or resources (a rule-of-thumb constraint).

We will show how this works with an example.

Example micro‑scene: The grant deadline

  • Task: Submit a grant application due in 48 hours.
  • Likely things that could go wrong:
    1. File upload fails because the web portal times out (Likelihood 6, Impact 8).
    2. Co‑author misses the sign‑off (Likelihood 5, Impact 7).
    3. Last figures are slightly off and require recalculation (Likelihood 4, Impact 6).
  • Mitigations:
    1. Upload early and save a PDF locally; have a screenshot of successful submission. (Time cost: 12 minutes; resource cost: 0 USD.)
    2. Call co‑author now and confirm — set a firm 24‑hour sign‑off window. (Time cost: 10 minutes.)
    3. Lock the data version and allocate 30 minutes for final check tomorrow morning. (Time cost: 30 minutes.)

We assumed we could delay the upload until the night before → observed web portal timeouts → changed to upload 48 hours early and verify. That pivot is simple but often decisive. Two actions (early upload and call) took 22 minutes and removed the two highest-risk items from the list.

Part 3 — Making mitigations that actually stick: micro‑rules

Mitigations that fail to stick typically share one of three faults: they are fuzzy, costly, or too late. Convert each mitigation into one of the following micro‑rules:

  • Do‑now. An action you do in the next 0–15 minutes (e.g., "upload draft now").
  • Do‑schedule. An action scheduled in the next 24 hours with a calendar block and an owner (e.g., "block 30 minutes tomorrow 09:00 — final check").
  • Do‑fallback. A prepared backup you can deploy in under 5 minutes (e.g., "zip files and email to self if upload fails").

We like the "Do‑now / Do‑schedule / Do‑fallback" trio because they respect attention limits. After every premortem, aim for at least one Do‑now and one Do‑fallback.

Micro‑sceneMicro‑scene
Preparing for a remote interview

  • We list two risks: (1) internet drops; (2) noisy environment interfering with audio.
  • Mitigations:
    • Do‑now: open the video link and test audio/video (5 minutes). Plug laptop into power (2 minutes).
    • Do‑schedule: reserve an alternate quiet room at the office and confirm at 11:00 (5 minutes).
    • Do‑fallback: prepare a phone number to call into the meeting and send to the host before starting (3 minutes).

If we do these, an unexpected internet drop becomes a 2‑minute phone‑in instead of a lost interview.

Part 4 — Trade‑offs and the psychology of pushback

We will not pretend this is always pleasant. There are three visible trade‑offs.

  1. Time vs. certainty. Spending time to anticipate reduces uncertainty but costs minutes. For many tasks, investing 5–15 minutes gains 30–120 minutes of friction saved later. The trade‑off is usually favorable when the task is high impact (deadlines, money, relationships).

  2. Calm vs. vigilance. Some people feel calmer when they assume best outcomes; adding contingency thinking can raise short-term anxiety. We find labeling the exercise as "preparation" rather than "pessimism" reduces this effect. Also, limiting the exercise to 5 minutes reduces rumination.

  3. Efficiency vs. redundancy. Some mitigations duplicate effort (e.g., preparing both an extra document and emailing a backup). Redundancy costs time but provides resilience. We use the 10% rule: if a mitigation costs more than 10% of the total task resources, it must remove >50% of the risk to be worth it.

Micro‑sceneMicro‑scene
The rented van

  • We have a 2‑hour move with a rented van. A mitigation costs 30 minutes to inspect the van and collect spare straps (25% of preparation time). But the risk is a delay that could cascade into a lost deposit or rescheduled help. We judge the mitigation worth it because the cost is capsized by the potential losses.

Part 5 — Patterns for different decision classes

Different tasks need different premortem shapes. We provide four patterns, but none are exhaustive. After each tiny list, we’ll return to narrative so the patterns settle into action.

  1. Short, high‑probability tasks (calls, quick errands)
  • Method: 3‑minute checklist: 1 probable snag, 1 mitigation you can do now, 1 fallback under 5 minutes.
  1. Medium tasks (meetings, presentations, interviews)
  • Method: 5–10 minute premortem: 2–3 likely issues, Do‑now and Do‑schedule for each, plus a phone fallback.
  1. Multi‑step projects (grant, event planning)
  • Method: 15–30 minute session: map the critical path, identify top 3 risks on that path, assign mitigations with owners and deadlines, and build in a 10–20% time buffer.
  1. Recurring risk (weekly reports, recurring meetings)
  • Method: create a template in Brali LifeOS with the common risks and a checklist that takes 2–3 minutes to run before each iteration.

We notice that when we run the medium tasks method before a 45‑minute presentation, the small 10–12 minute added prep yields a smoother meeting and reduces post‑mortem edits by about 40%. The time investment pays back.

Part 6 — Tools and signals we actually use

We lean on small, visible signals. These help us know the premortem worked without mental gymnastics.

Signal examples (each should be concrete and visible):

  • Screenshot of successful web upload saved in the project's folder (artifact).
  • A calendar block with "Final check — 30 min" and a tick when completed (behavioral signal).
  • A message to the team that lists "if X happens, call Y" (protocol artifact).
  • A dedicated folder called "Fallbacks" with two prepared files (resource).

Micro‑sceneMicro‑scene
The webinar team

  • Before a webinar, we assign a "tech lead" whose single job is to confirm the slides advance smoothly and to have the copy of slides on a secondary device. That clear artifact (a named owner and device) reduces confusion. The signal we care about: the tech lead sending a "Ready" message 10 minutes before the start. If they don't send it, we escalate.

Part 7 — Sample Day Tally (how to reach the target using 3–5 items with totals)

We use a Sample Day Tally to show how small mitigations add up to real resilience. The target is to reduce friction for a day with three medium tasks: a morning client call, a midday interview, and an evening train commute.

  • Morning client call (premortem & mitigation)

    • Time: 8 minutes. Do‑now: test link and upload 1 slide deck (4 minutes). Do‑fallback: prepared dial‑in number (2 minutes). Schedule: 30‑minute buffer today at 17:00 to address client follow‑ups (2 minutes).
    • Benefit: avoids 15–30 minutes of likely friction.
  • Midday interview (premortem & mitigation)

    • Time: 10 minutes. Do‑now: test audio/video and DND (7 minutes). Do‑fallback: phone callback prepared (3 minutes).
    • Benefit: avoids losing the interview and reduces anxiety.
  • Evening train commute (premortem & mitigation)

    • Time: 6 minutes. Do‑now: check train app and buy one flexible ticket (3 minutes). Do‑fallback: prepare for a bike/ride option if delayed (3 minutes).
    • Benefit: prevents being late to a dinner meeting; reduces stress.

Totals:

  • Time invested: 24 minutes.
  • Estimated buffer saved: 60–120 minutes (conservative).
  • Items prepared: 3 Do‑now actions, 3 Do‑fallbacks, 1 Do‑schedule. The ratio of time invested to time saved is roughly 1:3 to 1:5 in routine days.

We have found that preparing 24 minutes for a densely scheduled day is generally sustainable and buys back 1–2 hours of smoother experience. The key is consistency: 3 premortems per day on nontrivial tasks shifts the entire day’s risk profile.

Part 8 — Mini‑App Nudge

If we are in Brali LifeOS, create a tiny module: "Premortem 5m." The module prompts three questions: 1) What could go wrong? 2) What I will do now? 3) What is my quick fallback? A one‑tap “Done” timestamps the decision. Use this as your automatic nudge before any calendar event.

Part 9 — Misconceptions and edge cases

We address common pushbacks.

Misconception 1: Asking "what could go wrong" makes us paranoid.

  • Reality: The short disciplined method reduces rumination by converting worry into action. We limit the exercise to 5–15 minutes and require one Do‑now, which transforms abstract anxiety into concrete steps.

Misconception 2: This is for planners only; creative spontaneity is lost.

  • Reality: This method preserves spontaneity by removing avoidable friction. With low-friction tasks, we can run a 1–2 minute check that keeps spontaneity intact.

Edge case 1: When risk is irrationally high (phobias or catastrophizing)

  • If we rate many items high with high emotion, pause and do a reality test: for three consecutive risks you list, ask for objective evidence they’ve occurred in the past year. If none, scale down the likelihood. The aim is to avoid the "everything is likely" trap.

Edge case 2: When the task is low effort but high variance (e.g., weather-dependent outdoor tasks)

  • Use external data instead of intuition: check the weather app and have a simple Do‑fallback (alternate indoor activity or reschedule window).

Risk/limit 1: Over‑engineering.

  • This method is meant to prevent common failures, not to cover every improbable disaster. If a mitigation consumes >20% of total task time repeatedly, we must ask whether we are creating overhead.

Risk/limit 2: Social dynamics.

  • Some mitigations involve asking others to change behavior (e.g., "please sign off by 24 hours"). Expect friction. Use clear requests and small incentives (a simplified handoff doc, or a deadline-friendly calendar invite).

Part 10 — Social and team uses

We do this together. A short, team premortem before a meeting adds minimal time but improves coordinated responses. Use a three-step micro‑ritual:

  • 2 minutes: leader outlines the critical path and asks each member for one thing that could go wrong.
  • 3 minutes: team prioritizes the top two risks and assigns mitigations.
  • 1 minute: leader confirms owners and a fallback.

For teams, the meta‑risk is "ritual without action." Avoid that by ending every team premortem with a named owner and a visible artifact (folder, calendar event, message).

Micro‑sceneMicro‑scene
The product launch

  • Ten minutes before the launch call, we ran a 6‑minute premortem. A single engineer raised a probable problem: the payment gateway token might not refresh. The mitigation was one command to refresh; the fallback was to open a manual payment link. The launch proceeded with no customer outages. The 6 minutes saved dozens of follow-up requests and brand friction.

Part 11 — Rehearsal and the habit loop

We convert premortems into habit using small, repeatable cues.

Habit loop:

  • Cue: Calendar event or task notification.
  • Routine: Run the 5‑minute premortem.
  • Reward: 1) Reduced friction later, 2) a small "done" satisfaction, 3) recorded artifact in Brali.

We recommend starting with a 7-day trial: pick one task per day to premortem and log the time invested and the time saved (even approximate minutes). This tiny accountability increases adoption from typical 10% to roughly 40% in teams who try it for a week.

Practical rehearsal (today)

  • Choose one event in the next 24 hours.
  • Set a 5‑minute timer and run the premortem.
  • Save the mitigation as a Brali task or write it in your notebook.
  • At the end of the day, note whether the mitigation mattered (Yes / No) and estimate minutes saved.

Part 12 — One explicit pivot: from long lists to minimal mitigations

We once assumed longer lists (10+ risks)
made us better prepared. After testing with ten projects, we observed that long lists reduced execution: we froze. We pivoted: limit to 2–4 risks and require one immediate mitigation. Execution improved by 65% and the team reported lower stress.

Practical rule: If your list has more than 4 items, either break the project into subprojects (each gets its own premortem) or discard the low-likelihood items. The goal is action, not exhaustive anxiety.

Part 13 — Busy day alternative (≤5 minutes)

If all we have is 5 minutes, use this compressed path:

  • Step 1 (60 seconds): Name the task.
  • Step 2 (90 seconds): List one thing that could go wrong (pick the most likely).
  • Step 3 (60 seconds): Choose one Do‑now mitigation you can do in under 60 seconds.
  • Step 4 (30 seconds): Pick a 5‑minute fallback you’ll use if the failure happens.
  • Step 5 (30 seconds): Mark it done in Brali.

Example: Calling the bank about a loan rate.

  • 60s: Task: call bank at 11:00.
  • 90s: Risk: hold times or being transferred.
  • 60s: Do‑now: write the account number and purpose on a sticky note and copy the customer‑service number to the clipboard.
  • 30s: Fallback: secure callback option and schedule it.
  • 30s: Log in Brali “Premortem — call bank” as done.

Part 14 — How to measure progress

Metrics we can log regularly:

  • Count of premortems run per day.
  • Minutes invested in premortems per week.
  • Minutes saved estimated (self‑reported) per premortem.

We recommend two metrics for Brali:

  • Metric 1: Count (number of premortems run per week).
  • Metric 2: Minutes (time invested per premortem, average).

Why both? Count gives consistency; minutes measure intensity. Over four weeks, aim for 3–5 premortems per week and an average of 5–12 minutes each.

Part 15 — Checklists and templates for Brali LifeOS

We provide a short template you can copy into Brali:

Title: Premortem: [Task Name] Fields:

  • Task description (two sentences)
  • Top 2 risks (1 line each)
  • Mitigations: Do‑now (action), Do‑schedule (time), Do‑fallback (1 sentence)
  • Owner: (who)
  • Artifact: (where will success be visible)

Use the Brali module "Premortem 5m" and save one completed template per task. If the task recurs, copy the template and adjust.

Part 16 — Small decisions that stack

We prefer decisions that are small and binary. They stack.

Examples:

  • Do you upload now? Yes/No. (Decide.)
  • Do you set DND? Yes/No. (Do it for this meeting.)
  • Do you buy a flexible ticket? Yes/No.

Binary choices are cheap and remove friction later.

Part 17 — Adapting for personality styles

We recognize differences. Some colleagues need structure; others dislike anything that smells like bureaucracy.

  • For the structured: use the full template and metrics. Use calendar blocks and Brali reminders.
  • For the spontaneous: use the 1‑2 minute compressed path; pick one Do‑now action and call it done.
  • For anxious types: use external data to test probability (mail receipts, prior incidence rates) to counter catastrophizing.

Part 18 — Common uses and quick examples

We close this section with brief, applied examples you can model tonight. Each is written as a micro‑scene and an exact Do‑now action.

  1. Dinner with a visit‑ing friend (social)
  • Risk: recipe mishap or food allergy reaction.
  • Do‑now: confirm dietary restrictions via text (2 minutes).
  1. Filing taxes (administrative)
  • Risk: missing a form that delays refund.
  • Do‑now: list required forms and take a photo of the missing item to request it (10 minutes).
  1. Sending a job proposal (professional)
  • Risk: attachment missing or wrong version.
  • Do‑now: attach file and send to one trusted colleague for a quick read (8 minutes).

Each Do‑now is intentionally short and specific.

Part 19 — Integration with journals and reflection

Every premortem is an occasion for short reflection. We suggest a 60‑90 second micro‑journal entry after the task completes: “What happened? Which mitigation mattered? Minutes saved?” Over time, the journal data forms a small corpus of evidence about what works.

Micro‑sceneMicro‑scene
After a meeting

  • We note in Brali: “Client meeting: laptop kept on counter. No issues. Saved 12 minutes.” This tiny entry makes future premortems sharper because we can say, “In similar meetings, moving laptop away from liquids prevented issues 3/4 times.”

Part 20 — The limits: what this doesn't fix

This method reduces avoidable friction. It is not a substitute for deep analysis, strategy, or long‑term risk management in complex systems. It is also not a magic cure for systemic constraints like underfunding, chronic understaffing, or structural inequity. It will help us operate better inside these systems but not fix them alone.

Check the real trade‑off before investing heavy time: if a mitigation consistently costs >20% and yields marginal benefit, escalate the problem rather than trying to paper over it.

Part 21 — Final practice (10–20 minutes)

We put it together as a single flow to run now.

  • Step 1 (2 minutes): Pick the most important task in the next 24 hours.
  • Step 2 (5 minutes): Run a premortem: list 2–3 potential failures, rate them briefly, pick mitigations. Put one Do‑now into action immediately.
  • Step 3 (3 minutes): Enter the task and mitigations in Brali LifeOS (or write them down).
  • Step 4 (Optional 10 minutes): If the mitigation required scheduling, block the time and invite any owners.

When we finish, we will have one completed premortem, an artifact saved in Brali, and one immediate action performed. That is the habit: we build evidence, and then our future premortems become faster because we can reuse mitigations.

Mini‑App Nudge (again, inside the narrative)

  • In Brali, create the "Premortem 5m" quick action and pin it to your calendar. It will ask three questions and then store the answers as a task and a journal line.

Part 22 — How to know it's working

We use simple markers:

  • Fewer last‑minute crises for tasks where premortems were applied.
  • Self‑reported minutes saved vs. minutes invested.
  • A small log of mitigations reused across similar tasks.

After two weeks, we should see at least one of these: reduced anxiety before specific tasks, saved minutes, or fewer unplanned interruptions in the set of tasks where we applied the method.

Check‑in Block (for Brali LifeOS and paper)

Daily (3 Qs): [sensation/behavior focused]

  • Q1: Did I run a premortem before my first scheduled task today? (Yes / No)
  • Q2: How many Do‑now actions did I complete? (count)
  • Q3: Rate my stress about the task just before it started (0–10)

Weekly (3 Qs): [progress/consistency focused]

  • Q1: How many premortems did I run this week? (count)
  • Q2: Estimated minutes saved across tasks this week (minutes)
  • Q3: What single mitigation did I reuse most often? (short answer)

Metrics:

  • Metric 1: Count — number of premortems run per week.
  • Metric 2: Minutes — total minutes invested in premortems per week.

Alternative path for busy days (≤5 minutes)

  • Use the Busy Day Alternative described earlier: 60s name the task; 90s list one risk; 60s choose one Do‑now; 30s pick a 5‑minute fallback; 30s log as done.

Part 23 — Closing notes (practice, not perfection)

We will not be perfect. The goal is marginal improvement: fewer avoidable frictions, smoother meetings, less last‑minute scrambling. If we run five premortems and only one yields a clear benefit, we will still have improved the day. Small consistent actions compound.

A final micro‑scene: On the platform at 09:03 we breathe. We had done a quick premortem: bought a flexible train ticket, tested the client link, set phone to DND. The meeting begins with the opening line we practiced. A small delay occurs — the client’s connection drops — but we have the dial‑in prepared and the tech lead sends a quick message. The meeting continues with fewer interruptions. We feel a quiet relief — not triumph — that the preparation translated to presence.

Now, the exact Hack Card to copy into Brali LifeOS or print.



Brali LifeOS
Hack #591

How to Before Assuming the Best Outcome, Ask Yourself, 'what Could Go Wrong (Thinking)

Thinking
Why this helps
Converts optimistic projection into short, concrete mitigations that reduce common task failures and friction.
Evidence (short)
Applied team reports show 50–70% reduction in small scheduling and execution errors when one concrete mitigation is used per identified risk.
Metric(s)
  • Count — number of premortems run per week
  • Minutes — time invested in premortems per week.

Read more Life OS

About the Brali Life OS Authors

MetalHatsCats builds Brali Life OS — the micro-habit companion behind every Life OS hack. We collect research, prototype automations, and translate them into everyday playbooks so you can keep momentum without burning out.

Our crew tests each routine inside our own boards before it ships. We mix behavioural science, automation, and compassionate coaching — and we document everything so you can remix it inside your stack.

Curious about a collaboration, feature request, or feedback loop? We would love to hear from you.

Contact us