Founder gửi message lúc 11h đêm: “Tôi vừa chat với Claude 2 tiếng về việc fire một bạn senior. Claude bảo nên fire. Tôi định sáng mai báo. Có ổn không?”
Tôi hỏi lại: “Bạn đã viết ra 5 lý do KHÔNG nên fire chưa?”.
Im lặng 5 phút. Sau đó anh nhắn: “Chưa. Claude và tôi chỉ đi mỗi một chiều.”
Đây là cạm bẫy lớn nhất của AI decision: nó tạo cảm giác bạn đã suy nghĩ kỹ, trong khi thực ra bạn chỉ confirm một hướng. Bài này dạy bạn dùng Claude làm decision partner đúng cách: bắt nó cấu trúc câu hỏi và challenge bạn, không quyết hộ.
Tại sao “nhờ Claude quyết” là sai
Có 3 lý do.
1. Claude không có skin in the game. Bạn fire sai, công ty bạn lỗ. Claude fire sai, Claude không sao. Người không gánh hậu quả không nên là người ra quyết định.
2. Claude không có context đầy đủ. Bạn có 100 chi tiết về bạn nhân viên đó, buổi tối anh ấy đi đâu, hôm qua nói gì, gia đình ra sao. Bạn không paste hết cho Claude được. Claude quyết dựa trên 5% thông tin bạn cho.
3. Claude bias toward action. Khi bạn hỏi “có nên làm không”, Claude thường nghiêng về “có” vì câu trả lời đó có vẻ helpful hơn. Đây là bias huấn luyện, không phải bug.
Vì vậy: đừng hỏi “tôi nên làm gì”. Hỏi “giúp tôi cấu trúc câu hỏi này”.
Framework 4 bước
Bước 1: Clarify câu hỏi thật
90% quyết định bạn cảm thấy khó là vì câu hỏi đặt sai. Claude rất giỏi unbundle câu hỏi to thành câu hỏi nhỏ chính xác.
Tôi đang phải quyết định: [mô tả 2-3 câu].
Trước khi bạn cho ý kiến, hãy giúp tôi làm rõ câu hỏi.
1. Câu hỏi thật sự ở đây là gì? Tôi có vẻ đang hỏi 1 câu nhưng thực ra có thể là 2-3 câu lồng nhau.
2. Có giả định ngầm nào trong cách tôi đặt vấn đề mà có thể sai?
3. Câu hỏi này nên được trả lời bởi ai (tôi, advisor, market, hay bằng experiment)?
4. Nếu phải trả lời trong 30 ngày, câu hỏi này có thể tách thành 1 quyết định nhỏ hơn để test trước không?
Đừng cho ý kiến về quyết định. Chỉ làm rõ.
Ví dụ thật: founder hỏi “có nên fire bạn senior này không”. Sau khi clarify, câu thật là “tôi có biết cách quản bạn này không, và tôi có muốn học không”. Đó là câu khác hẳn.
Bước 2: Expand option tree
Hầu hết founder ra quyết định binary: làm A hay làm B. Thực tế thường có 5-8 phương án mà bạn chưa nghĩ tới.
Vấn đề: [mô tả].
Hiện tại tôi đang phân vân giữa A và B. Hãy giúp tôi mở rộng option tree.
Liệt kê tối thiểu 7 phương án, bao gồm:
- A và B tôi đã nghĩ
- 2 phương án "ở giữa" (compromise)
- 2 phương án "lateral" (giải quyết vấn đề từ angle khác)
- 1 phương án "không làm gì" (status quo cụ thể trong 6 tháng nữa sẽ ra sao)
- 1 phương án mà bạn nghĩ tôi sẽ không thích nhưng đáng cân nhắc
Mỗi phương án 2-3 câu mô tả. Chưa cần đánh giá.
Output thường có 1-2 phương án mà bạn ngồi đó tự cười: “ô đúng rồi tại sao mình không nghĩ ra”.
Bước 3: Trade-off matrix có trọng số
Sau khi có 5-7 option, đánh giá có cấu trúc.
Đây là 6 phương án từ bước trước [paste].
Tôi đánh giá theo 5 tiêu chí, mỗi cái có trọng số:
- Chi phí trong 6 tháng tới (trọng số 25%)
- Tốc độ thấy kết quả (20%)
- Reversibility, quay đầu nếu sai (20%)
- Năng lượng tôi phải bỏ ra (20%)
- Tác động dài hạn nếu thành công (15%)
Cho điểm mỗi option theo 5 tiêu chí trên (1-5 với 5 là tốt nhất).
Trình bày dạng bảng. Cuối bảng có cột tổng có trọng số.
Sau bảng, viết 1 paragraph: option nào ra top, option nào surprise (bạn nghĩ sẽ tệ nhưng điểm cao), option nào "bẫy" (điểm cao nhưng có rủi ro ẩn).
Trọng số là của bạn, không của Claude. Bạn điều chỉnh trọng số theo tình huống, ví dụ nếu đang thiếu tiền, “chi phí” lên 40%.
Bước 4: Reversibility check
Đây là step quan trọng nhất mà 90% founder bỏ qua.
Top 2 option từ trade-off matrix là [option X] và [option Y].
Cho từng option, trả lời:
1. Nếu chọn sai, mất bao lâu để biết là sai?
2. Nếu biết là sai, mất bao lâu/bao nhiêu tiền để quay đầu?
3. Có phần nào của quyết định là "1 chiều" (không reversible)? Tách phần đó ra.
4. Có cách nào test rẻ trước khi commit toàn bộ không?
Khái niệm: Type 1 quyết định = không reversible (ví dụ ký hợp đồng 2 năm). Type 2 = reversible (ví dụ test giá mới 1 tháng).
Phần Type 2 nên quyết nhanh. Phần Type 1 nên quyết chậm.
Tách quyết định này thành Type 1 và Type 2.
Đây là framework của Jeff Bezos. Lý do hay: hầu hết quyết định bạn cảm thấy “to” thực ra có thể tách thành 1 phần Type 1 nhỏ và 1 phần Type 2 lớn. Phần Type 2 cứ làm. Chỉ phần Type 1 cần suy nghĩ kỹ.
Pattern pre-mortem, pattern tốt nhất
Trong tất cả prompt decision, đây là pattern tôi dùng nhiều nhất:
Giả định: 6 tháng sau, tôi đã quyết định [phương án X] và quyết định này thất bại rõ ràng.
Viết một bản hậu xét chi tiết với góc nhìn của tôi nhìn lại:
- Dấu hiệu cảnh báo nào đã có sẵn lúc quyết mà tôi bỏ qua?
- Giả định nào trong reasoning của tôi đã sai?
- Có khoảnh khắc nào tôi có thể quay đầu nhưng không quay?
- 3 sai lầm chính dẫn đến thất bại?
- Nếu được làm lại, tôi sẽ quyết khác như thế nào?
Viết theo tone của tôi tự kiểm điểm, không phải Claude khuyên.
Tại sao pattern này hay: nó bắt bộ não nhìn quyết định từ tương lai ngược về. Hầu hết “lý do thất bại” mà Claude generate ra là những cờ đỏ bạn đang thấy nhưng ngại đối mặt. Pre-mortem đưa chúng lên bàn.
Sau khi đọc pre-mortem, hỏi tiếp:
Trong các sai lầm bạn vừa liệt kê, cái nào là cảnh báo CÓ THẬT ngay bây giờ trong tình huống của tôi (dựa vào những gì tôi đã kể)?
Cờ đỏ ở đây là cờ đỏ thật.
Pre-mortem là tool để nhìn thấy, không phải để quyết. Nếu sau pre-mortem bạn thấy 3 cờ đỏ to mà bạn không có cách giải quyết, đó là tín hiệu “chưa”, không phải tín hiệu “không”. Đôi khi cờ đỏ đó là cái cần giải quyết trước, không phải lý do hủy quyết định.
5 dạng quyết định founder hay phải ra
1. Pricing
Sản phẩm: [mô tả]. ICP: [mô tả]. Giá hiện tại: X.
Tôi đang phân vân giữa 3 phương án giá: giữ X, tăng lên Y, giảm xuống Z (kèm tier mới).
Trước khi đánh giá:
- Pricing leverage hiện tại của tôi đến từ đâu (giá trị, scarcity, switching cost, hay không có)?
- 3 thử nghiệm nhỏ tôi có thể chạy trong 30 ngày để thu data trước khi quyết?
- Nếu sai giá 1 tháng, hậu quả gì? (revert được không, mất khách bao nhiêu?)
2. Hire / Fire
Tình huống: [mô tả ngắn về người này, role, hiệu suất 3 tháng gần, dấu hiệu cụ thể].
Trước khi quyết hire/fire, giúp tôi trả lời:
1. Có phải vấn đề là role thiết kế sai, không phải con người? (job description không khả thi)
2. Đã có conversation trực tiếp về vấn đề chưa? Họ phản ứng thế nào?
3. Nếu fire, người tiếp theo có khả thi tìm không? Trong bao lâu?
4. Cost của giữ thêm 30 ngày để cho 1 lần feedback nữa = bao nhiêu?
Sau đó pre-mortem cả 2 hướng (fire và không fire).
3. Build vs Buy
Tôi đang cân nhắc build [tính năng/system X] vs buy [tool Y giá Z].
Đánh giá theo:
- True cost build: dev hours, opportunity cost, maintenance 12 tháng tới
- True cost buy: subscription + integration time + lock-in risk
- Reversibility: nếu build sai, mất bao lâu vứt? Nếu buy sai, exit thế nào?
- Core vs context: tính năng này có phải core competency không?
Cuối cùng: 70% trường hợp build là sai cho startup early stage. Nếu tôi đang nghĩ build, hỏi lại 3 lần "tại sao không buy".
4. Pivot vs Persevere
Sản phẩm hiện tại: [mô tả]. Metric 3 tháng gần: [paste]. Cảm giác của tôi: [mô tả thật].
Khung Eric Ries, pivot khi:
1. Validated learning đang đứng yên (số chính không cải thiện dù effort tăng)
2. Customer feedback cùng 1 hướng khác với hướng bạn đi
3. Burn rate buộc bạn quyết trong N tháng
Đánh giá tôi đang ở chỗ nào trên 3 tiêu chí.
Nếu pivot: list 3 pivot type Eric Ries (zoom-in, zoom-out, customer segment, etc.) và cái nào fit nhất.
Nếu persevere: list 3 thử nghiệm cần thấy kết quả trong 60 ngày tới để justify persevere.
5. Đầu tư marketing
Tôi đang cân nhắc đổ X VND vào kênh [Y] trong 3 tháng tới.
Đánh giá:
1. CAC hiện tại của các kênh đang chạy. Kênh mới có data benchmark từ ngành không?
2. Payback period (tháng): với LTV của tôi là Z, CAC tối đa cho phép là bao nhiêu?
3. Có cách spend 10% budget để test trước không?
4. Cờ đỏ ngầm: bạn đang lãng phí ngân sách vì "phải làm gì đó" hay vì có hypothesis cụ thể?
Cờ đỏ, khi nào ngừng nói chuyện với Claude
3 dấu hiệu nên đứng dậy đi bộ một vòng:
- Cuộc chat dài hơn 90 phút mà chưa quyết được. Bạn đang trì hoãn, không phải đang nghĩ.
- Bạn cảm thấy “rõ ràng” sau khi Claude nói. Claude rất giỏi tạo cảm giác rõ ràng. Test: bạn có giải thích lại quyết định cho cộng sự bằng 1 phút mà không cần mở chat không? Nếu không, bạn chưa hiểu.
- Bạn đang argue lại với Claude. Bạn không đang ra quyết định nữa, bạn đang tìm validation. Ngừng chat. Đi ngủ.
Decision quan trọng cần ngủ một đêm. Nguyên tắc: nếu quyết định có hậu quả > 3 tháng, không quyết trong cùng ngày đầu nghĩ.
Trước khi sang bài 6
Checklist tự đánh giá:
- Bạn đã thử framework 4 bước (clarify → option → trade-off → reversibility) với 1 quyết định thật.
- Bạn đã chạy pre-mortem cho ít nhất 1 quyết định và phát hiện ít nhất 1 cờ đỏ thật.
- Bạn đã phân biệt được Type 1 (irreversible) và Type 2 (reversible) trong tình huống của mình.
- Bạn đã hiểu: nhiệm vụ của Claude không phải là quyết hộ, là làm rõ.
Bài 6 chuyển sang việc dùng Claude với data và slides, cách paste số liệu, dựng phân tích, sinh bảng và slide có cấu trúc.
AI cowork tip
Sau mỗi quyết định lớn, mở chat Claude và nói “sau khi tôi đã quyết, viết hậu xét trong tương lai cho tôi”, kể cả khi bạn tự tin. Lưu vào 1 file decision-log.md trong knowledge base. Sau 1 năm, bạn có 20-30 hậu xét, data mạnh nhất để hiểu pattern ra quyết định của bạn.
Đọc tiếp
Bài 1, Vì sao founder nên xem Claude là cộng tác viên, không phải một công cụ
Khác biệt giữa dùng AI như công cụ tra cứu và dùng như cộng tác viên là khác biệt giữa tiết kiệm 30 phút và tiết kiệm 30 giờ. Bài đầu series giải thích vì sao mindset quyết định kết quả, kèm cách chọn model Claude phù hợp.
Đọc bàiBài 2, Setup Claude workspace: Projects, system prompt và knowledge base
Project là 'phòng làm việc' của Claude. System prompt dạy Claude biết bạn là ai. Knowledge base là tài liệu Claude luôn nhớ. 3 thứ này tạo nên khác biệt giữa cộng tác viên và chatbot. Bài này có template setup + ví dụ filled.
Đọc bàiBài 3, Writing partner: viết blog, email, sales script với Claude mà không bị 'AI giọng'
Workflow viết 4 bước: bạn nói ý → Claude draft → bạn refine → Claude polish. Có cách giữ voice không bị nhạt, cách dùng Artifacts để iterate, và 6 use case thường gặp với prompt mẫu.
Đọc bài