Backlog (danh sách công việc tồn đọng) của bạn có 120 item. Sếp Sales muốn feature X vì "khách VIP đòi hỏi". Sếp Marketing muốn feature Y vì "đối thủ vừa launch cái đó". Team Data đưa ra một insight cho thấy feature Z mới thực sự đáng làm nhất, nhưng chẳng ai chịu nghe vì nó không "nổi bật" bằng hai cái kia. Đây là buổi họp ưu tiên hóa (prioritization) điển hình của bất kỳ PM/PO nào — và phần lớn thời gian trong đó không dùng để phân tích dữ liệu, mà dùng để... thuyết phục lẫn nhau. RICE, ICE, WSJF, MoSCoW không phải công thức toán học chính xác tuyệt đối — chúng là công cụ tạo ra một ngôn ngữ chung, giúp cuộc tranh luận cảm tính chuyển thành cuộc thảo luận dựa trên tiêu chí rõ ràng. Vấn đề kinh điển là: chấm điểm 120 item theo 4 tiêu chí RICE tốn hàng chục giờ, và cách chấm của bạn tuần này rất dễ khác cách chấm tuần trước vì bạn đang mệt, đang vội, hoặc đang bị ảnh hưởng bởi ý kiến người vừa nói chuyện với bạn 5 phút trước.
AI thay đổi phương trình này không phải bằng cách "quyết định hộ" bạn nên làm gì — quyết định đó vẫn luôn là trách nhiệm của PM/PO — mà bằng cách rút ngắn thời gian chấm điểm từ hàng giờ xuống hàng phút, giữ tính nhất quán giữa các lần chấm, và quan trọng nhất: giúp bạn nhìn ra khi nào một quyết định ưu tiên đang bị chi phối bởi thiên kiến (bias) thay vì dữ liệu. Bài này đi từ cách dùng AI áp dụng RICE/ICE/MoSCoW/WSJF vào backlog thực tế, đến cách tạo rationale (lý giải) nhất quán, cách AI giúp giảm thiên kiến kinh điển như anchoring, recency, HiPPO, và cuối cùng — ranh giới quan trọng nhất: khi nào tin AI, khi nào con người phải override (ghi đè).
Cách Dùng AI Để Áp Dụng RICE, ICE, MoSCoW Và WSJF Vào Backlog Của Bạn
Bốn khung này không cạnh tranh nhau — mỗi khung phù hợp với một bối cảnh khác nhau, và việc đầu tiên cần làm không phải là chấm điểm, mà là chọn đúng khung cho đúng tình huống.
RICE (Reach — độ phủ, Impact — mức ảnh hưởng, Confidence — độ tin cậy, Effort — công sức) phù hợp khi bạn có nhiều feature/item cần so sánh trên cùng một roadmap dài hạn, và bạn có ít nhất một số dữ liệu định lượng về số lượng user bị ảnh hưởng. Công thức: RICE Score = (Reach × Impact × Confidence) / Effort.
ICE (Impact, Confidence, Ease — độ dễ triển khai) là phiên bản rút gọn, phù hợp khi bạn cần chấm điểm nhanh trong buổi backlog grooming (làm mịn backlog) mà không có đủ dữ liệu Reach chính xác — thường dùng cho brainstorm ý tưởng giai đoạn đầu hoặc growth experiment.
MoSCoW (Must have, Should have, Could have, Won't have) không cho điểm số mà phân loại nhị phân, phù hợp nhất khi làm việc với một release có phạm vi cố định (fixed scope) và cần thống nhất với stakeholder về "cái gì bắt buộc phải có" trước một deadline cụ thể.
WSJF (Weighted Shortest Job First) đến từ SAFe (Scaled Agile Framework), dùng Cost of Delay (chi phí trì hoãn — thiệt hại kinh tế nếu item bị chậm) chia cho Job Size (kích thước công việc), phù hợp nhất ở cấp độ portfolio/program khi bạn cần so sánh giữa nhiều team hoặc nhiều epic có quy mô effort rất khác nhau.
Các Bước Thực Hành
- Chuẩn hóa dữ liệu đầu vào trước khi đưa cho AI. Export backlog từ Jira/Productboard/Notion ra bảng gồm tối thiểu: tên item, mô tả ngắn, số liệu định lượng nếu có (số user request, doanh thu liên quan, ticket support), và effort ước lượng thô (story point hoặc man-day). AI chấm điểm tốt hơn rất nhiều nếu dữ liệu đầu vào có cấu trúc, thay vì một dòng mô tả mơ hồ.
- Chọn khung phù hợp với bối cảnh quyết định, không phải chọn khung "quen tay". Nếu đang họp roadmap quý, dùng RICE hoặc WSJF. Nếu đang brainstorm feature mới trong 30 phút, dùng ICE. Nếu đang chốt scope release tuần sau, dùng MoSCoW.
- Đưa cả backlog vào AI theo batch (lô), không chấm từng item riêng lẻ. Chấm 20-30 item cùng lúc trong một prompt giúp AI tự tạo ra một thang tham chiếu tương đối nhất quán giữa các item — chấm rời rạc từng cái dễ khiến điểm số trôi dạt (drift) qua các lần chạy khác nhau.
- Yêu cầu AI trích dẫn rõ căn cứ cho từng điểm số, không chỉ đưa con số trần trụi. Đây là bước bắt buộc để bạn (và stakeholder) có thể kiểm tra lại logic, không phải "tin mù" vào AI.
- Review và điều chỉnh cùng team liên chức năng (Dev lead, Design, Sales/CS nếu cần) trước khi chốt — AI tạo bản nháp điểm số, con người xác nhận và điều chỉnh dựa trên context nội bộ mà AI không biết.
- Lưu lại phiên bản chấm điểm kèm ngày tháng trong Notion/Confluence để so sánh khi backlog thay đổi ở sprint sau, tránh phải giải thích lại từ đầu mỗi lần có stakeholder mới hỏi "tại sao cái này ưu tiên hơn cái kia".
Ví Dụ Prompt
Prompt chấm RICE cho một batch backlog, dùng với ChatGPT, Claude, hoặc Notion AI (paste trực tiếp bảng backlog dạng Markdown/CSV):
Bạn là một Head of Product có 10 năm kinh nghiệm ưu tiên hóa backlog
bằng khung RICE.
Dưới đây là danh sách 15 backlog item của sprint/quý tới, mỗi item có
mô tả ngắn và dữ liệu hỗ trợ (nếu có):
[PASTE BẢNG: Tên item | Mô tả | Số user liên quan (nếu có) |
Ticket support liên quan | Effort ước lượng thô (story point)]
Hãy chấm điểm RICE cho từng item theo đúng công thức:
RICE = (Reach x Impact x Confidence) / Effort
Trong đó:
- Reach: số user/khách hàng bị ảnh hưởng trong 1 quý (ước lượng dựa
trên dữ liệu được cung cấp, nêu rõ nếu phải giả định).
- Impact: thang 0.25 (tối thiểu) / 0.5 (thấp) / 1 (trung bình) /
2 (cao) / 3 (rất cao - massive impact).
- Confidence: thang 50% (thấp) / 80% (trung bình) / 100% (cao),
dựa trên độ chắc chắn của dữ liệu đầu vào.
- Effort: số người-tuần ước lượng để hoàn thành.
Với mỗi item, xuất bảng gồm: Tên item | Reach | Impact | Confidence |
Effort | RICE Score | Lý do chấm từng chỉ số (2-3 câu, trích dẫn cụ
thể dữ liệu đầu vào, không chấm chung chung).
Sắp xếp kết quả theo RICE Score giảm dần. Cuối bảng, liệt kê 3 item
mà bạn (AI) có độ tin cậy thấp nhất trong cách chấm, kèm lý do và câu
hỏi cần hỏi thêm PM để chấm chính xác hơn.
Trả lời bằng tiếng Việt, giữ nguyên thuật ngữ RICE, Reach, Impact,
Confidence, Effort bằng tiếng Anh.
Prompt chấm WSJF khi so sánh giữa nhiều epic ở cấp portfolio, dùng với Claude hoặc ChatGPT:
Bạn là Product Portfolio Lead áp dụng WSJF (Weighted Shortest Job
First) theo mô hình SAFe.
Dưới đây là 8 epic đang cạnh tranh nguồn lực của quý tới:
[PASTE: Tên epic | Mô tả | Team liên quan | Effort ước lượng
(story point hoặc man-month)]
Hãy tính WSJF Score = Cost of Delay / Job Size, trong đó Cost of
Delay = User-Business Value + Time Criticality + Risk Reduction-
Opportunity Enablement (mỗi thành phần chấm thang Fibonacci: 1, 2,
3, 5, 8, 13, 20).
Với mỗi epic, xuất bảng: Epic | User-Business Value | Time
Criticality | Risk Reduction/Opportunity | Cost of Delay (tổng) |
Job Size | WSJF Score | Giải thích ngắn cho từng thành phần.
Sắp xếp theo WSJF Score giảm dần. Ghi chú rõ nếu có epic nào Time
Criticality cao bất thường (ví dụ liên quan compliance/pháp lý có
deadline cứng) cần cân nhắc ưu tiên vượt khung điểm số thông thường.
Trả lời bằng tiếng Việt, giữ thuật ngữ WSJF, Cost of Delay, Job Size
bằng tiếng Anh.
Mẹo: Đừng bao giờ để AI tự chọn khung ưu tiên hóa cho bạn — việc chọn RICE hay WSJF hay MoSCoW phụ thuộc vào bối cảnh tổ chức (bạn đang họp roadmap quý hay chốt release tuần sau), thứ mà chỉ PM/PO mới nắm rõ. Hãy luôn chỉ định rõ khung trong prompt, và dùng AI để thực thi phép tính lặp đi lặp lại một cách nhất quán, không phải để ra quyết định chiến lược.
Dùng AI Để Tạo Rationale (Lý Giải) Chấm Điểm Nhất Quán Giữa Các Backlog Item
Một trong những vấn đề nhức đầu nhất của prioritization không phải là con số, mà là "tại sao lại là con số đó". Khi PM nghỉ phép hoặc đổi vai trò, người kế nhiệm nhìn vào một cột RICE Score = 45 mà không hiểu vì sao — dữ liệu số bị mất ngữ cảnh (context) đã tạo ra nó. Rationale (lý giải chấm điểm) chính là cầu nối giữ lại "tại sao", và đây là chỗ AI phát huy giá trị rất rõ vì nó không mệt, không lười viết giải thích dài như con người thường làm khi backlog có hàng trăm item.
Các Bước Thực Hành
- Định nghĩa một template rationale cố định trước khi chạy AI trên toàn backlog. Ví dụ mỗi rationale phải có: nguồn dữ liệu tham chiếu (ticket, khảo sát, số liệu), giả định đã đưa ra, và mức độ chắc chắn. Không có template, AI (và cả con người) sẽ viết rationale ngẫu hứng, câu dài câu ngắn, không so sánh được giữa các item.
- Bắt AI trích dẫn cụ thể, không dùng ngôn ngữ mơ hồ. Cấm các cụm như "quan trọng", "khá tốt", "có vẻ ảnh hưởng lớn" — bắt buộc phải có con số hoặc nguồn cụ thể (ví dụ: "23 ticket support trong Q2 nhắc đến vấn đề này", "theo khảo sát NPS tháng 5, 40% người trả lời phàn nàn về...").
- Chạy AI cho toàn bộ backlog trong một lần, không phải rời rạc từng item, để đảm bảo văn phong và độ chi tiết của rationale nhất quán từ item đầu đến item cuối — tránh tình trạng 10 item đầu có rationale rất kỹ, 20 item cuối chỉ có một câu ngắn cụt vì AI "mệt" (thực ra là do cách bạn prompt rời rạc, không phải do model).
- Đối chiếu rationale với chấm điểm để phát hiện mâu thuẫn nội bộ — ví dụ AI viết rationale "impact thấp vì chỉ ảnh hưởng một nhóm nhỏ khách hàng" nhưng lại chấm Impact = 2 (cao). Đây là dấu hiệu cần yêu cầu AI chấm lại hoặc con người can thiệp trực tiếp.
- Gắn rationale vào field riêng trong Jira/Productboard (custom field "Prioritization Rationale"), không chỉ để trong comment dễ bị trôi mất khi backlog dài ra theo thời gian.
- Review định kỳ (mỗi 1-2 sprint) rationale của các item đứng đầu backlog để đảm bảo lý do ưu tiên vẫn còn đúng — dữ liệu 3 tháng trước có thể đã lỗi thời khi thị trường/user behavior thay đổi.
Ví Dụ Prompt
Prompt tạo rationale nhất quán cho toàn bộ backlog đã có điểm số RICE, dùng với ChatGPT/Claude:
Bạn là Product Manager cần viết rationale (lý giải chấm điểm) chuẩn
hóa cho một backlog đã được chấm RICE Score, để bàn giao cho stakeholder
và PM kế nhiệm hiểu rõ logic phía sau.
Dưới đây là bảng backlog đã chấm điểm:
[PASTE: Tên item | RICE Score | Reach | Impact | Confidence | Effort |
Dữ liệu thô liên quan (ticket support, khảo sát, số liệu doanh thu...)]
Với mỗi item, viết rationale theo đúng cấu trúc sau (không thêm bớt
mục, không viết văn hoa):
- Nguồn dữ liệu: [trích dẫn cụ thể ticket/khảo sát/số liệu đã dùng]
- Giả định đã đưa ra: [nêu rõ nếu phải giả định do thiếu dữ liệu]
- Độ chắc chắn: [Cao/Trung/Thấp] kèm 1 câu lý do
- Rủi ro nếu chấm sai: [1 câu, điều gì tệ nhất có thể xảy ra nếu điểm
số này thực ra sai]
Sau đó, quét lại toàn bộ để chỉ ra bất kỳ item nào có mâu thuẫn giữa
rationale và điểm số (ví dụ rationale nói impact nhỏ nhưng điểm Impact
lại cao), liệt kê riêng ở cuối để PM xem xét lại.
Trả lời bằng tiếng Việt, giữ thuật ngữ RICE/Reach/Impact/Confidence/
Effort bằng tiếng Anh, văn phong ngắn gọn súc tích, không lặp từ.
Ví dụ template output cho một item cụ thể (dùng làm mẫu minh họa cho một dòng trong bảng backlog đã chấm điểm):
## Item: Cho phép xuất báo cáo dạng Excel trên Dashboard
RICE Score: 32 (Reach: 4.000 user/quý | Impact: 1 (trung bình) |
Confidence: 80% | Effort: 1 người-tuần)
- Nguồn dữ liệu: 18 ticket support trong 60 ngày gần nhất yêu cầu
export Excel; khảo sát in-app tháng 4 có 12% người dùng chọn tính
năng này khi được hỏi "bạn thiếu tính năng gì nhất".
- Giả định đã đưa ra: giả định 4.000 user/quý dựa trên số lượng user
active dùng Dashboard hàng tháng x tỷ lệ ước tính 15% sẽ dùng tính
năng export (chưa có dữ liệu thực đo do tính năng chưa tồn tại).
- Độ chắc chắn: Trung bình — do Reach dựa trên ước lượng tỷ lệ sử
dụng, chưa có A/B test hay dữ liệu thực tế xác nhận.
- Rủi ro nếu chấm sai: nếu tỷ lệ sử dụng thực tế thấp hơn nhiều so
với 15% ước tính, RICE Score có thể bị thổi phồng gấp đôi so với
giá trị thực, khiến item này chiếm chỗ của item khác đáng làm hơn.
Mẹo: Lưu mọi rationale do AI tạo cùng với timestamp và tên người review — đừng để rationale trở thành "hộp đen" mà không ai biết ai đã xác nhận nó đúng. Một rationale không có người ký duyệt cuối cùng chỉ là bản nháp, không phải căn cứ ra quyết định chính thức.
Cách AI Giúp Giảm Thiên Kiến Trong Ưu Tiên Hóa — Hiệu Ứng Anchoring, Recency Và HiPPO
Đây có lẽ là giá trị lớn nhất mà AI mang lại cho prioritization — không phải tốc độ, mà là khả năng làm "gương chiếu hậu" giúp PM/PO nhìn ra chính thiên kiến (bias) của mình và của tổ chức. Ba loại thiên kiến kinh điển nhất trong các buổi họp ưu tiên hóa:
Anchoring bias (thiên kiến neo): khi item đầu tiên được chấm điểm hoặc thảo luận trong buổi họp vô tình trở thành "mốc neo" cho tất cả các item sau — nếu item đầu được chấm Impact = 3 (rất cao), những item tiếp theo dễ bị so sánh (và chấm thấp hơn một cách thiên lệch) so với cái neo đó, thay vì được đánh giá độc lập trên chính giá trị của nó.
Recency bias (thiên kiến gần đây nhất): feature vừa được stakeholder nhắc đến trong cuộc họp tuần này, hoặc vừa xuất hiện trong một bài báo về đối thủ, dễ được chấm điểm cao hơn thực tế chỉ vì nó "mới nóng trong đầu" — trong khi một item đã nằm trong backlog 3 tháng, dù giá trị thực sự cao hơn, lại bị lãng quên vì không ai nhắc tới gần đây.
HiPPO effect (Highest Paid Person's Opinion — hiệu ứng ý kiến của người trả lương cao nhất): khi CEO hoặc VP nói "tôi nghĩ chúng ta nên làm cái này trước", cả phòng họp im lặng gật đầu dù dữ liệu không ủng hộ, vì không ai muốn tranh luận trực tiếp với cấp trên. Đây là thiên kiến phổ biến nhất và khó xử lý nhất trong văn hóa doanh nghiệp Việt Nam, nơi tôn trọng cấp bậc thường mạnh hơn văn hóa tranh luận dựa trên dữ liệu.
Các Bước Thực Hành
- Chấm điểm AI độc lập trước khi họp, không phải trong lúc họp. Chạy AI chấm điểm toàn bộ backlog trước khi bất kỳ ai trong phòng họp nói ra ý kiến cá nhân — điểm số AI đóng vai trò "baseline trung lập" để so sánh, không bị ảnh hưởng bởi không khí cuộc họp.
- Ẩn thứ tự trình bày item khi đưa cho AI chấm. Xáo trộn (randomize) thứ tự các item trong prompt qua các lần chạy khác nhau, rồi so sánh kết quả — nếu điểm số một item thay đổi đáng kể chỉ vì vị trí nó xuất hiện trong danh sách, đó là dấu hiệu anchoring đang ảnh hưởng ngay cả cách AI xử lý, cần tách chấm riêng lẻ hoặc theo nhóm nhỏ hơn.
- Yêu cầu AI đánh giá lại dựa trên dữ liệu lịch sử dài hạn (6-12 tháng), không chỉ dữ liệu tuần gần nhất, để chống recency bias — ví dụ so sánh số ticket support/feature request trong cả năm, không chỉ tháng vừa rồi khi một sự kiện nổi bật vừa xảy ra.
- Dùng AI như "advocate của dữ liệu" khi có HiPPO effect: đưa cho AI cả ý kiến của lãnh đạo và dữ liệu thực tế, yêu cầu nó chỉ ra khoảng cách (gap) giữa hai bên một cách khách quan, trung lập — điều này giúp PM có "vũ khí" để phản biện lịch sự mà không phải tự mình đối đầu trực diện.
- So sánh điểm số AI chấm với điểm số con người chấm độc lập (blind), rồi thảo luận riêng phần chênh lệch lớn — đừng thảo luận toàn bộ backlog, chỉ tập trung vào những item có khoảng cách điểm số lớn nhất giữa AI và con người, đó thường chính là nơi bias đang ẩn náu.
- Ghi lại các trường hợp override AI thành công/thất bại theo thời gian để nhận diện pattern: nếu một loại thiên kiến (ví dụ luôn ưu tiên feature do Sales đề xuất) lặp lại nhiều lần, đó là vấn đề văn hóa tổ chức cần giải quyết ở cấp cao hơn, không chỉ ở từng buổi họp riêng lẻ.
Ví Dụ Prompt
Prompt phát hiện khoảng cách giữa ý kiến lãnh đạo và dữ liệu thực tế (giúp xử lý HiPPO effect), dùng với ChatGPT hoặc Claude:
Bạn là một Data-Informed Product Advisor, nhiệm vụ là đối chiếu ý
kiến định tính của lãnh đạo với dữ liệu định lượng thực tế, một cách
khách quan, không thiên vị bên nào.
Ý kiến của lãnh đạo (CEO/VP) về ưu tiên backlog:
[PASTE Ý KIẾN, ví dụ: "Tôi nghĩ mình nên ưu tiên tích hợp với đối tác
X ngay quý này vì đó là xu hướng thị trường"]
Dữ liệu thực tế hiện có:
[PASTE: số ticket support liên quan, số user request, dữ liệu doanh
thu/churn liên quan, benchmark đối thủ nếu có]
Hãy phân tích:
1. Ý kiến của lãnh đạo được dữ liệu hiện có ủng hộ ở mức độ nào
(Mạnh/Trung bình/Yếu/Không có bằng chứng), giải thích cụ thể.
2. Nếu dữ liệu KHÔNG ủng hộ mạnh, liệt kê rõ những dữ liệu còn thiếu
cần thu thập thêm để xác nhận hoặc bác bỏ ý kiến này (ví dụ: khảo
sát nhanh 50 khách hàng, phân tích win/loss 10 deal gần nhất).
3. Đề xuất một cách trình bày trung lập, không đối đầu, để PM có thể
dùng khi thảo luận lại với lãnh đạo — nêu rõ tôn trọng ý kiến định
hướng chiến lược, đồng thời đưa ra dữ liệu bổ sung một cách xây
dựng.
Trả lời bằng tiếng Việt, văn phong chuyên nghiệp, không phán xét.
Prompt kiểm tra anchoring/recency bias bằng cách chấm điểm blind hai lần và so sánh:
Đây là backlog 20 item, đã được chấm ICE Score hai lần độc lập:
lần 1 theo đúng thứ tự item được đề xuất trong cuộc họp (item được
nhắc đến gần đây nhất ở đầu danh sách), lần 2 theo thứ tự ngẫu nhiên
đã xáo trộn.
[PASTE BẢNG 2 CỘT ĐIỂM SỐ TỪ 2 LẦN CHẤM]
Hãy:
1. Liệt kê các item có chênh lệch điểm số giữa 2 lần chấm từ 20% trở
lên, sắp xếp theo mức chênh lệch giảm dần.
2. Với mỗi item chênh lệch lớn, đưa ra giả thuyết vì sao (do vị trí
trong danh sách, do thời điểm được nhắc đến, do thiếu dữ liệu rõ
ràng khiến việc chấm điểm nhạy cảm với ngữ cảnh xung quanh).
3. Đề xuất cách chấm lại các item này một cách độc lập, tách khỏi
toàn bộ danh sách, để có điểm số đáng tin cậy hơn.
Trả lời bằng tiếng Việt.
Mẹo: Thiên kiến không bao giờ biến mất hoàn toàn dù có AI hay không — mục tiêu thực tế không phải "loại bỏ 100% bias" mà là làm cho bias trở nên nhìn thấy được (visible) và có thể thảo luận công khai. Một team thừa nhận "chúng ta đang bị ảnh hưởng bởi ý kiến sếp" và chọn xử lý nó một cách có ý thức luôn tốt hơn một team giả vờ mình hoàn toàn khách quan trong khi thực ra không phải vậy.
Khi Nào Nên Tin AI Ưu Tiên Hóa Và Khi Nào Con Người Phải Ghi Đè (Override)
Sau tất cả những gì AI làm được, câu hỏi quan trọng nhất vẫn là: khi nào một PM/PO nên chấp nhận điểm số AI đưa ra, và khi nào bắt buộc phải override nó bằng judgment (phán đoán) của con người? Đây không phải câu hỏi triết học — nó là ranh giới trách nhiệm nghề nghiệp thực sự, vì cuối cùng, chính PM/PO là người phải giải trình trước ban lãnh đạo và khách hàng về quyết định ưu tiên, không phải AI.
AI đáng tin cậy nhất khi: dữ liệu đầu vào đầy đủ và có cấu trúc rõ ràng, tiêu chí chấm điểm đã được định nghĩa cụ thể (không mơ hồ), và quyết định thuộc dạng lặp lại nhiều lần với quy mô lớn (chấm hàng trăm ticket feature request tương tự nhau). AI kém tin cậy nhất khi: quyết định liên quan đến chiến lược dài hạn chưa có tiền lệ, dữ liệu định lượng gần như không có (toàn bộ dựa vào trực giác thị trường), hoặc có yếu tố chính trị/quan hệ đối tác/pháp lý mà AI không có ngữ cảnh đầy đủ để đánh giá.
Các Bước Thực Hành
- Phân loại quyết định theo hai trục: mức độ đảo ngược được (reversible) và quy mô ảnh hưởng. Quyết định dễ đảo ngược và ảnh hưởng nhỏ (ví dụ thứ tự 2 bug fix nhỏ trong sprint) — tin AI, không cần bàn nhiều. Quyết định khó đảo ngược và ảnh hưởng lớn (ví dụ chọn kiến trúc nền tảng, ký hợp đồng đối tác chiến lược) — AI chỉ nên là input tham khảo, quyết định cuối cùng bắt buộc phải qua con người có đầy đủ thẩm quyền.
- Luôn override khi AI thiếu context tổ chức mà con người có. Ví dụ: AI chấm một feature Impact thấp vì không biết rằng feature đó là điều kiện tiên quyết để ký hợp đồng enterprise trị giá lớn đang đàm phán — thông tin này thường không nằm trong bất kỳ dữ liệu nào bạn đưa cho AI, vì nó vẫn đang là thông tin mật giữa Sales và ban lãnh đạo.
- Override khi có ràng buộc pháp lý/compliance cứng. Một yêu cầu liên quan đến bảo vệ dữ liệu cá nhân (tương tự GDPR/Nghị định 13 về bảo vệ dữ liệu cá nhân tại Việt Nam) có deadline cứng theo luật phải luôn được ưu tiên bất kể điểm số RICE/ICE tính ra thấp — đây là loại risk không thể lượng hóa gọn trong công thức thông thường.
- Luôn kiểm tra lại khi Confidence AI tự báo cáo thấp. Nếu bạn đã yêu cầu AI tự đánh giá độ tin cậy của chính nó (như trong các prompt ở phần trên) và nó báo Confidence thấp cho một item quan trọng, đừng chấm điểm đó là "xong" — đây chính là tín hiệu cần thu thập thêm dữ liệu thực tế (khảo sát nhanh, phỏng vấn khách hàng) trước khi chốt.
- Dùng nguyên tắc "AI đề xuất, con người quyết định, và luôn ghi lại lý do nếu override". Mọi lần PM quyết định khác với điểm số AI đề xuất, hãy ghi ngắn gọn lý do (1-2 câu) vào cùng field rationale — dữ liệu này theo thời gian giúp bạn học được pattern: bạn override AI đúng bao nhiêu lần, override sai bao nhiêu lần, từ đó tinh chỉnh lại cách bạn tin tưởng AI trong tương lai.
- Định kỳ review lại các quyết định override sau 1-2 quý để đánh giá: quyết định override đó có đúng không (feature được ưu tiên nhờ override có đạt được kết quả kỳ vọng), từ đó cải thiện cả cách bạn prompt AI lẫn cách bạn ra quyết định thủ công trong tương lai.
Ví Dụ Prompt
Prompt yêu cầu AI tự đánh giá độ tin cậy và chỉ rõ những chỗ cần con người quyết định, dùng với Claude hoặc ChatGPT:
Bạn vừa chấm RICE Score cho backlog 20 item ở bước trước. Bây giờ hãy
tự đánh giá lại độ tin cậy của chính kết quả đó, một cách trung thực,
không tô hồng.
Với mỗi item, trả lời:
1. Mức độ tự tin của bạn vào điểm số đã chấm (Cao/Trung bình/Thấp),
dựa trên: dữ liệu đầu vào có đủ và cụ thể không, hay bạn phải suy
đoán/giả định nhiều.
2. Loại quyết định này có phải loại "dễ đảo ngược, ảnh hưởng nhỏ" hay
"khó đảo ngược, ảnh hưởng lớn"? Nêu rõ lý do.
3. Nếu có bất kỳ yếu tố nào ngoài dữ liệu định lượng (quan hệ đối tác,
cam kết hợp đồng, ràng buộc pháp lý, chính trị nội bộ tổ chức) có
thể ảnh hưởng đến quyết định mà bạn không có thông tin — hãy nêu
rõ ràng đây là điểm PM cần tự đánh giá thêm, không nên dựa hoàn
toàn vào điểm số AI.
4. Xếp hạng tất cả item theo mức độ "nên tin điểm số AI" giảm dần,
để PM biết nên ưu tiên xem xét thủ công item nào trước.
Trả lời bằng tiếng Việt, trung thực và thẳng thắn, không cố tỏ ra tự
tin hơn thực tế.
Prompt ghi log quyết định override để xây dữ liệu học hỏi lâu dài:
PM vừa quyết định ưu tiên item "[TÊN ITEM]" khác với điểm số AI đề
xuất (AI đề xuất hạng [X], PM quyết định đưa lên hạng [Y]).
Lý do override của PM: [MÔ TẢ NGẮN LÝ DO, ví dụ: "Feature này là điều
kiện để ký hợp đồng với khách hàng enterprise trị giá 2 tỷ đồng/năm,
thông tin đàm phán chưa công khai nên AI không biết"]
Hãy viết lại thành một đoạn ghi log ngắn gọn, chuẩn hóa, gồm: Item |
Điểm AI đề xuất | Quyết định thực tế | Lý do override | Loại lý do
(context tổ chức thiếu / ràng buộc pháp lý / quan hệ đối tác / khác)
| Ngày quyết định.
Mục đích: lưu vào một bảng theo dõi để cuối quý phân tích pattern
override, xem loại lý do nào lặp lại nhiều nhất.
Trả lời bằng tiếng Việt.
Mẹo: Xây một "sổ log override" (override log) đơn giản trong Notion hoặc Google Sheet, chỉ cần 5 cột: item, điểm AI, quyết định thật, lý do, ngày. Sau 2-3 quý, sổ này trở thành tài sản cực kỳ giá trị — nó cho bạn biết chính xác loại thông tin nào AI luôn thiếu (ví dụ luôn thiếu context về deal Sales đang đàm phán), từ đó bạn biết nên chủ động bổ sung loại dữ liệu đó vào prompt cho những lần chấm điểm sau, thay vì cứ lặp lại việc phải override thủ công mỗi lần.
Những Điểm Chính Cần Nhớ
- RICE, ICE, WSJF, MoSCoW là công cụ tạo ngôn ngữ chung, không phải công thức tuyệt đối — chọn đúng khung theo đúng bối cảnh quyết định (roadmap quý dùng RICE/WSJF, brainstorm nhanh dùng ICE, chốt scope release dùng MoSCoW).
- AI rút ngắn thời gian chấm điểm từ hàng giờ xuống hàng phút, nhưng giá trị thật nằm ở cách bạn cấu trúc dữ liệu đầu vào và yêu cầu AI trích dẫn căn cứ cụ thể, không phải ở việc AI tự "biết" đâu là ưu tiên đúng.
- Rationale (lý giải chấm điểm) phải nhất quán và có nguồn dữ liệu cụ thể, được lưu lại có timestamp và người xác nhận — đừng để điểm số trở thành con số vô nghĩa không ai giải thích được sau vài tháng.
- AI là công cụ mạnh để phát hiện anchoring, recency bias, và HiPPO effect — bằng cách chấm điểm blind, xáo trộn thứ tự, và đối chiếu ý kiến định tính với dữ liệu định lượng một cách khách quan.
- Luôn tin AI khi quyết định dễ đảo ngược, quy mô nhỏ, dữ liệu đầy đủ; luôn override khi có yếu tố pháp lý, quan hệ đối tác, hoặc context tổ chức mà AI không có — và luôn ghi lại lý do override để học hỏi theo thời gian.
- Trách nhiệm cuối cùng của quyết định ưu tiên hóa luôn thuộc về PM/PO, không phải AI — AI là trợ lý tăng tốc và tăng tính nhất quán, không phải người ra quyết định thay bạn.