Soc Cognitive Bias

Cognitive Bias Analysis

Overview

Cognitive biases are systematic deviations from rational judgment. They're not random errors — they're predictable patterns that affect everyone, including experts. This skill helps identify which biases are at play in a specific decision context and design countermeasures.

Framework

IRON LAW: Name the Specific Bias, Not Just "Bias"

"This decision might be biased" is not analysis. Identify the SPECIFIC
bias by name, explain its mechanism, and show how it applies to this
particular situation. Different biases require different countermeasures.

Bias Audit Process

1. Describe the decision: What is being decided? By whom? Based on what evidence? 2. Identify potential biases by name: Which specific biases (confirmation, anchoring, sunk cost, groupthink, overconfidence, availability, etc.) could be influencing this decision? 3. Find the evidence: What specific behavior or reasoning pattern indicates the bias? 4. Assess impact: How much does this bias affect the decision quality? (High/Med/Low) 5. Design countermeasures: What specific debiasing technique addresses each identified bias?

For the full bias catalog (12 biases × mechanism × example) and debiasing techniques per bias, see `references/debiasing-protocols.md`.

Output Format

# Cognitive Bias Audit: {Decision Context}

## Decision Under Review
- Decision: {what is being decided}
- Decision-makers: {who}
- Current leaning: {which way they're leaning}

## Biases Identified
| Bias | Evidence | Impact | Countermeasure |
|------|----------|--------|---------------|
| {name} | {specific behavior/reasoning} | H/M/L | {debiasing technique} |

## Debiased Recommendation
{What the decision looks like after accounting for identified biases}

Examples

Correct Application

Scenario: Company deciding whether to continue a failing product launch (6 months in, NT$5M spent)

Debiased question: "If a competitor offered us this product line for free, would we take it?" If the answer is no, the product should be discontinued regardless of sunk costs ✓

Incorrect Application

• "The team is biased" without specifying which bias → Not actionable. Violates Iron Law: name the specific bias.

Gotchas

• Everyone has biases, including you: The analyst conducting the bias audit is also biased. Use structured processes (checklists, red teams) rather than relying on self-awareness.
• Bias identification ≠ bias elimination: Knowing about a bias reduces but does not eliminate its effect. Debiasing requires structural interventions (processes, incentives), not just awareness.
• Motivated reasoning looks like analysis: When someone has a preferred outcome, they unconsciously construct logical-sounding arguments for it. Check: did the conclusion come before or after the analysis?
• False balance: Not every decision is biased. Sometimes the team's leaning is correct. Don't force-fit biases where they don't exist.
• Cultural context: Some biases manifest differently across cultures. Authority bias is stronger in hierarchical cultures. Groupthink manifests differently in collectivist vs individualist settings.

References

• For behavioral economics applications of biases, see the econ-behavioral skill
• For group decision-making debiasing protocols, see references/debiasing-protocols.md

Example: SaaS 新市場進入決策的認知偏誤稽核

Scenario

用戶問題：

「我們是台灣 B2B SaaS 公司，核心產品是製造業 ERP 系統（年費 NT$480,000）。董事會三個月前批准進軍日本市場，但整個決策過程讓我很不安。起點是 CEO 在 2025 年 9 月去日本出差，跟幾家工廠聊完之後回來就大力推動這件事。我們已經花了 NT$3.2M 請顧問做市場研究和本地化，但顧問報告其實很清楚指出：日本 SME 的 ERP 滲透率只有 12%，而且在地競爭者 Kaiho Systems 市占率高達 47%。問題是，CEO 在董事會報告裡只分享了第一章的『市場規模 2.1 兆日圓』，後面的競爭分析根本沒被提到。現在下個月要決定是否再投入 NT$15M 開設東京辦公室。我們是不是在騙自己？」

---

Analysis

Step 1：釐清決策全貌

• 決策內容：是否投入 NT$15M 於東京設立實體辦公室，正式進軍日本製造業 ERP 市場
• 決策者：CEO 主導，董事會批准
• 當前傾向：繼續推進（已核准方向，下個月正式定案）
• 現有證據一覽：

---

Step 2：逐一命名偏誤並找出具體證據

偏誤 1：可得性捷思法（Availability Heuristic）

機制：人傾向以「在腦中最容易浮現的具體事件」估計可能性，而非依賴統計數據。

證據：CEO 的決策觸發點是幾次日本工廠拜訪中「氣氛很好」的正面互動。這幾個場景鮮明、具體、帶有情緒溫度，在記憶中特別顯著，因此被當作市場需求的代表性樣本——即便這幾家工廠從未承諾付費，也不是隨機抽樣的結果。

影響：高 — 觸發整個市場進入計畫的「信號」，本質上只是 3-4 個正面的社交場合。

---

偏誤 2：確認偏誤（Confirmation Bias）

機制：決策者選擇性蒐集、詮釋、分享支持既定結論的資訊，忽略或過濾掉反面證據。

證據：顧問報告同時包含機會面（市場規模）與風險面（滲透率 12%、Kaiho 市占 47%），但 CEO 在董事會只呈現第一章。這不是摘要的篇幅限制——因為正面數字「2.1 兆日圓」被完整保留，而負面數字「47%」完全消失。這是選擇性過濾，不是摘要。

影響：高 — 董事會在資訊不對稱的條件下批准，等同於「知情同意」的形式合法但實質缺失。

---

偏誤 3：沉沒成本謬誤（Sunk Cost Fallacy）

機制：已投入且不可回收的成本，被錯誤地納入未來決策，成為「繼續」的論據。

證據：內部討論中「都已經花了 NT$3.2M 做市場研究，不能半途而廢」這類說法已出現。NT$3.2M 無論接下來如何決定，都不可能回收。「是否再投入 NT$15M」與「過去花了多少」是兩個獨立問題。

影響：中 — 非主要顯性論點，但作為心理底色拉高了「繼續」的決策慣性。

---

偏誤 4：過度自信偏誤（Overconfidence Bias）

機制：決策者對自身能力、或對未來成果的掌控力，系統性高估。

證據：台灣製造業 ERP 成功經驗被直接投射為「日本可複製」的假設，但兩市場在語言障礙、採購文化（日本企業高度偏好本地供應商關係）、競爭格局上差距顯著。目前沒有任何付費 PoC 客戶、沒有 LOI，卻計畫投入 NT$15M 的固定成本承諾。

影響：高 — 整個投資建立在未被驗證的市場可複製性假設上。

---

Step 3：去偏工具應用

歸零測試（Zero-Base Test）：

「假設今天才第一次評估日本市場，從未花過任何費用——在看完完整顧問報告（含競爭章節）之後，你會建議立刻投入 NT$15M 開辦公室嗎？」

如果答案是「不，我們會先做小規模驗證」，那麼 NT$3.2M 的沉沒成本正在扭曲決策門檻。

事前驗屍（Pre-mortem）：

「假設 18 個月後，日本市場進入以失敗告終，公司損失 NT$18.2M。請列出最可能的前三個原因。」

預期答案：（1）Kaiho 的客戶鎖定效應使轉換成本過高、（2）在地銷售團隊建立比預期慢 2 倍、（3）沒有本地參考客戶導致無法打開大型客戶大門。這三個風險在決策時均未被正式評估。

---

Result

# Cognitive Bias Audit: 日本製造業 ERP 市場進入決策

## Decision Under Review
- Decision: 是否投入 NT$15M 於東京設立辦公室，正式進軍日本製造業 ERP 市場
- Decision-makers: CEO 主導，董事會批准
- Current leaning: 繼續推進（下個月定案）

## Biases Identified
| Bias | Evidence | Impact | Countermeasure |
|------|----------|--------|---------------|
| 可得性捷思法 | CEO 以 3-4 次正面工廠拜訪印象驅動決策，取代「滲透率 12%」的統計數據 | H | 委外結構化問卷調查 ≥30 家目標 SME，以系統性資料取代軼事印象 |
| 確認偏誤 | 顧問報告競爭章節（Kaiho 47% 市占、滲透率 12%）未呈現給董事會 | H | 指定獨立董事擔任「魔鬼代言人」，在定案會議前向全體董事補報完整顧問報告 |
| 沉沒成本謬誤 | NT$3.2M 已支出，被隱性引用作為「不能停」的論據 | M | 歸零測試：假設今天才開始評估，完整看過報告後門檻是否相同？ |
| 過度自信 | 無付費 PoC 客戶，計畫直接投入 NT$15M 固定成本 | H | 事前驗屍 + 設立進入門檻（先取得 ≥3 家付費 PoC 合約再設辦公室） |

## Debiased Recommendation

**暫緩 NT$15M 辦公室投資，改採里程碑制進入策略：**

**Gate 0 → 第一階段（3 個月，預算 NT$500K）**
- 委外執行 ≥30 家日本製造業 SME 結構化調查
- 量化指標：ERP 更換意願、對非日系供應商的接受度、Kaiho 的客戶滿意度缺口
- 同時完整補報顧問報告給董事會，重新確認市場進入意願

**Gate 1（決策門檻）**：調查結果顯示 ≥20% 受訪者有近期換約意願，且 ≥5 家同意進入付費 PoC（NT$50,000/家試用費），才啟動第二階段

**Gate 2 → 第二階段（6 個月，預算 NT$2M）**
- 以虛擬辦公室 + 本地業務代理模式執行 PoC
- 驗證留存率與擴充付費意願

**Gate 3（辦公室決策門檻）**：PoC 轉換率 ≥40% 且年化 ARR 達 NT$5M，才評估設立東京實體辦公室

---
NT$3.2M 的沉沒成本不應影響此決定。若 PoC 驗證失敗，損失 NT$500K
遠優於損失 NT$15M + 2 年機會成本。Kaiho 47% 市占並非不可突破，
但需要差異化切入點（價格、整合、利基產業），而非複製台灣打法。

Debiasing Protocols

Structured procedures that reduce specific cognitive biases through process design, not self-awareness. Organized by the bias each protocol primarily targets, with step-by-step procedures and worked examples.

---

Selecting the Right Protocol

Do not stack all protocols on every decision. Over-process is its own failure mode. Match protocol intensity to decision stakes and reversibility.

---

Protocol 1: Red Team / Devil's Advocate

Targets: Confirmation bias, groupthink, authority bias

When to use: Team has a strong preferred conclusion; high-stakes recommendation; any situation where everyone agrees too quickly.

Procedure

1. Appoint the role explicitly. Designate one person (or a small sub-group) as the Red Team. This must be a formal role, not "who wants to argue the other side?" Voluntary advocates are too soft. 2. Give the Red Team the strongest version of the opposition case. Brief them on all arguments for the current recommendation, then ask: "Build the most compelling argument AGAINST this decision. Assume the current recommendation fails — why?" 3. Red Team presents first. Before the main team presents their recommendation, Red Team argues the opposing case for a fixed time (10–20 min depending on decision complexity). 4. Main team responds. Not to "win" but to identify which Red Team objections they cannot rebut. 5. Unrefuted objections become decision conditions. Any Red Team argument the main team can't rebut gets added to the decision log as a named risk or condition.

Rules that prevent the protocol from degrading

• Red Team is not playing devil's advocate for fun — they should be genuinely trying to find fatal flaws.
• The Red Team lead should not be the most junior person in the room (authority bias will prevent real challenge).
• After the session, the Red Team role ends. Don't let it create permanent "designated skeptic" dynamics.

Worked Example

Decision: Launch a premium pricing tier at 2x current price.

Red Team brief: "Argue that this pricing move will destroy net revenue within 18 months."

Red Team arguments (presented first):

• Price-sensitive cohort (identified as ~38% of users in past churn analysis) will cancel at 2x, not upgrade
• Competitor X has been testing similar pricing and rolled it back after 90 days
• Net Revenue Retention calculation assumes 70% upgrade rate — no evidence base given for this number

Main team cannot rebut: The 38% price-sensitive cohort estimate. They had assumed 15%.

Outcome: Decision conditions added — cap downside exposure by launching in one region first; conduct price-sensitivity survey before full rollout.

---

Protocol 2: Independent Parallel Estimates

Targets: Anchoring, groupthink, authority bias

When to use: Any meeting where a number will be discussed — budget, timeline, market size, probability of success. Run this before the meeting, not during.

Procedure

1. Frame the estimation question precisely. Write down the exact question with units and time horizon. "What is the probability this product reaches $1M ARR within 12 months of launch?" is better than "Will this succeed?" 2. Collect estimates independently, in writing. Each participant submits their estimate (and optionally their top 2 reasoning factors) before seeing any other estimates. Use anonymous forms if authority bias is likely. 3. Reveal all estimates simultaneously. Not sequentially — sequential revelation anchors later responders to earlier numbers. 4. Identify the spread, not just the average. Wide spread = hidden disagreement that needs surfacing. Narrow spread = possible groupthink (especially if one authority submitted first). 5. Discuss the outliers first. Ask the highest and lowest estimators to explain their reasoning. This surfaces hidden information and resets the group's frame. 6. Re-estimate (optional). If discussion reveals new information, a second round of independent estimates is legitimate. Don't average the rounds mechanically.

Common failure mode

Running "independent" estimates in the meeting itself while the CEO's number is written on the whiteboard. That number will anchor everyone. Estimates must be collected before any numbers are visible in the room.

Worked Example

Pre-meeting form sent to 5 decision-makers:

"Independent of anything discussed in previous meetings: What percentage of beta users do you estimate will convert to paid within 30 days of receiving their upgrade prompt?"

Responses (collected blind):

Spread: 12%–35%. Not groupthink. Outliers are A (12%) and B (35%).

Discussion reveals: A has been monitoring support tickets and sees significant confusion with the upgrade flow. B extrapolated from a single cohort that had an unusually high engagement week.

Revised consensus after discussion: 18–22%, with a blocker: fix the upgrade UX before launch.

Without the protocol, the meeting would have opened with the CEO's gut figure of "around 30%" and anchored everyone there.

---

Protocol 3: Pre-Mortem

Targets: Overconfidence, planning fallacy

Developed by: Gary Klein (1989). Validated in research by Deborah Mitchell et al.

When to use: Before committing to a plan — project launch, investment, strategic pivot. Run once the plan is finalized but before execution begins.

Why it works

Prospective hindsight — imagining that an event has already happened — increases the ability to identify reasons for future outcomes by approximately 30% (Mitchell et al., 1989). The pre-mortem exploits this by forcing the imagination of failure before it occurs.

Procedure

1. State the premise explicitly to the group: "It is now 12 months from today. The project has failed — completely, not just underperformed. We are in a post-mortem meeting. What happened?" 2. Individual silent writing (5–10 min). Each participant writes down every reason they can think of for the failure. No discussion yet. This prevents early speakers from anchoring the frame. 3. Round-robin sharing. Each person shares one reason in rotation. Continue until all reasons are exhausted. Facilitator captures on a shared board. 4. Cluster and rank. Group similar reasons. Vote on which failure modes are (a) most likely and (b) most severe. 5. Modify the plan. For each high-ranked failure mode, ask: "What change to the current plan would reduce this risk?" Update the plan or add explicit monitoring tripwires.

Prompt variants by bias type

Worked Example

Plan: Expand to Japanese market in Q3. Team confidence: "very high."

Pre-mortem session produces 23 failure reasons. Top 5 after clustering and voting:

Plan modifications added:

• Hire Tokyo-based BD contractor before launch (not after)
• Commission localization quality review from native speakers
• Legal review of financial data handling requirements added to pre-launch checklist

Note: The regulatory item had Low likelihood but Critical severity — it would have been missed in a standard risk review because no one was thinking about it.

---

Protocol 4: Nominal Group Technique (NGT)

Targets: Groupthink, authority bias, bandwagon effect

When to use: Group decisions where rank differences or dominant personalities are likely to suppress minority views. Standard brainstorming meetings are the primary failure case.

Procedure

1. Silent idea generation (5–10 min). All participants write their ideas or votes individually without discussion. No verbal communication. 2. Round-robin recording. Each participant shares one idea per round in order. The facilitator records every idea without evaluation or comment. No discussion, no "yes but," no "we tried that." Continue until all ideas are exhausted. 3. Clarification only. Once all ideas are recorded, participants may ask clarification questions — only to understand, not to challenge or advocate. 4. Individual silent ranking. Each participant privately ranks the top 5 items (or votes using dot voting). Rankings are written, not spoken. 5. Aggregate and display results. Tally rankings publicly. The group sees the aggregate — not who voted for what. 6. Discussion, then final vote. Only now does the group discuss, focused on items with surprising rankings. Final vote if needed.

Why this outperforms standard brainstorming

Standard brainstorming produces production blocking (only one person speaks at a time), evaluation apprehension (fear of criticism suppresses ideas), and social loafing (people defer to whoever speaks first). NGT eliminates all three by separating generation from evaluation.

Worked Example

Decision: Which of four product roadmap priorities should get Q3 resources?

Standard meeting outcome: VP of Engineering proposes Option A enthusiastically first. Four others agree quickly. One person mentions Option C but doesn't push it.

NGT outcome:

Individual silent rankings (5 participants, rank 1=highest):

Option C wins. It was the item "mentioned but not pushed" in the standard meeting. Under NGT, three participants had it ranked #1.

Discussion reveals: C solves a key customer pain point that engineering staff knew about but felt junior to raise against the VP's preferred option.

---

Protocol 5: Zero-Base Challenge

Targets: Sunk cost fallacy, status quo bias, escalation of commitment

When to use: Any decision where past investment (money, time, effort, reputation) is being cited as a reason to continue. Particularly effective for ongoing projects that are underperforming.

The core reframe

The sunk cost fallacy persists because the mind frames the decision as:

"We've spent X. Should we continue?"

The Zero-Base Challenge reframes it as:

"Ignoring everything spent so far: if we were offered this opportunity today for the first time, with current knowledge, would we invest?"

These are the same decision economically. They produce different answers psychologically because the reframe removes the sunk investment from the frame entirely.

Procedure

1. Document the forward economics only. Strip out all past costs. Calculate only: (a) remaining investment required, (b) expected forward returns, (c) probability-weighted expected value. 2. State the zero-base question. "If a competitor offered us this asset/project/position today — for free — would we take it on?" If free isn't enough to take it, the project should be discontinued. 3. Identify the real objection. If the answer is "yes we'd take it for free, but we need to continue investing," verify this is driven by forward economics, not sunk cost reasoning. 4. Separate stranded costs from reversibility. Some continuation costs are legitimate — not because of sunk costs, but because stopping now would create new costs (contract penalties, team disruption, customer commitments). Name these explicitly and include them in the forward calculation.

Worked Example

Situation: SaaS company 14 months into a data pipeline rebuild. NT$8M spent. Timeline overrun by 6 months. Current estimate: NT$4M more to complete. Original business case: NT$2M annual savings.

Standard framing: "We've spent NT$8M. We can't stop now."

Zero-base calculation:

Zero-base question: "If a vendor offered to build this for NT$4M, would we commission it?"

Answer: No — the business case at current costs doesn't justify it.

Decision: Evaluate if a commercial off-the-shelf solution exists at lower cost. If not, negotiate a reduced scope rebuild.

Stranded cost check

Before stopping: NT$1.2M in vendor contracts have cancellation penalties of NT$300K if terminated before month 18. This is a legitimate forward cost of stopping — include it. It doesn't change the direction of the decision in this case.

---

Protocol 6: Reference Class Forecasting

Targets: Availability heuristic, planning fallacy, overconfidence in unique-case reasoning

Developed by: Daniel Kahneman and Amos Tversky; operationalized by Bent Flyvbjerg for infrastructure planning.

When to use: Whenever a forecast is being built primarily from the "inside view" (project-specific features, team's own models). Add the outside view via reference class.

Inside view vs. outside view

Both views are legitimate. The bias is that inside-view estimates dominate, and reference class forecasting corrects this.

Procedure

1. Select the reference class. Find a database of projects/decisions sufficiently similar to your case. The class should be (a) similar in type, (b) large enough to be statistically meaningful (n ≥ 20 is a rough minimum), and (c) historical, not projected. 2. Establish the base rate. From the reference class, compute the distribution of outcomes. For schedule: what % of similar projects came in on time, over by 10%, over by 50%? For revenue: what's the P50, P80 outcome? 3. Adjust for specific features. Apply a limited set of adjustments for features that genuinely differentiate your case from the reference class. Document each adjustment and its direction/magnitude. 4. Produce a calibrated forecast. The reference class sets the prior. Specific adjustments shift it. Do not let inside-view optimism override the prior without explicit justification.

Example Reference Classes

Worked Example

Inside view forecast: New B2B SaaS product will reach NT$10M ARR in Year 1. Team reasoning: strong product-market fit signals, 3 LOIs from enterprise prospects, experienced sales team.

Reference class: B2B SaaS products launched by Series A companies with similar ACV (NT$500K–2M), past 5 years.

Reference class data (n=47 products):

Base rate P50 outcome: approximately 25% of target = NT$2.5M ARR.

Adjustments applied:

• +15%: Existing enterprise relationships (2 of 3 LOI companies are existing customers of related product)
• -10%: No dedicated enterprise sales hire yet (historical data shows companies without dedicated AE miss by more)

Adjusted forecast: P50 = NT$2.8M ARR. P80 = NT$5M ARR.

Decision implication: Build the Year 1 operating plan on NT$3M ARR, not NT$10M. Hire the enterprise AE in month 1, not month 6.

---

Calibration Tracking (Supporting Tool)

Targets: Overconfidence — specifically, persistent overconfidence that repeats across decisions

Reference class forecasting and pre-mortems address overconfidence in individual decisions. Calibration tracking addresses systematic overconfidence in a person or team over time.

What to track

For every probabilistic prediction made with a stated confidence level, record:

• Date
• Decision / question
• Stated probability (e.g., "80% confident this will succeed")
• Actual outcome (recorded when known)

Calibration score

A well-calibrated forecaster is right approximately X% of the time on predictions stated with X% confidence.

Simple check: Of all predictions stated with "70–80% confidence" over the past year, what % actually came true?

Minimum viable implementation

A spreadsheet with four columns: Date, Prediction, Confidence (%), Outcome. Review quarterly. Show team members their own calibration scores — not to shame, but to give feedback the brain cannot generate on its own.

Teams that track calibration consistently improve over 6–12 months. Teams that only attend "debiasing workshops" without tracking show little lasting improvement.

---

Protocol Selection by Decision Type

---

What Protocols Cannot Fix

• Motivated reasoning with deliberate concealment. If a decision-maker knows the truth and is hiding it, debiasing won't help. This is a governance/incentive problem.
• Biases reinforced by incentive structures. A sales team on commission will be overconfident in revenue forecasts regardless of what protocol you use. Fix the incentive, or accept the bias and apply a reference class correction.
• Single-person decisions under time pressure. Most protocols require ≥ 2 people and preparation time. For urgent solo decisions, the best available tool is a written checklist: "What would I advise a friend in this situation?" (removes self-serving bias) and "What's the base rate?" (removes availability bias).