Đây là bài tập tổng hợp (capstone) của cả module. Bạn đã học cách chấm điểm backlog bằng RICE/ICE/WSJF, cách dựng roadmap theo outcome thay vì danh sách feature, cách phân tích trade-off, và cách căn chỉnh (align) với stakeholder — nhưng trong công việc thật, không ai làm bốn việc đó tách rời nhau. Một buổi sáng thứ Hai, bạn mở backlog 40 item chưa ưu tiên, tối thứ Sáu bạn phải đứng trước hội đồng (CEO, Trưởng phòng Kinh doanh, Engineering Lead) trình bày roadmap quý tới và trả lời được câu hỏi khó nhất trong phòng. Bài này mô phỏng đúng hành trình đó, theo bốn giai đoạn liên tục, để bạn thực hành toàn bộ quy trình agentic — từ chấm điểm thô đến slide hội đồng — với AI hỗ trợ ở từng bước nhưng con người luôn là người ra quyết định cuối.
Kịch bản xuyên suốt cả bài: bạn là Product Manager của Retasy — phần mềm quản lý bán hàng đa kênh (multi-channel retail management SaaS) dành cho các chuỗi cửa hàng bán lẻ vừa và nhỏ tại Việt Nam (thời trang, mỹ phẩm, tạp hóa), cạnh tranh trực tiếp với KiotViet, Sapo, Haravan. Retasy hiện có 8.000 cửa hàng trả phí, ARR (doanh thu định kỳ hàng năm) khoảng 42 tỷ đồng, churn (tỷ lệ khách rời bỏ) hàng tháng đang ở mức 3,2% — cao hơn mục tiêu 2,5% mà hội đồng đặt ra đầu năm. Đội ngũ gồm bạn (PM), 2 BA, anh Long (Engineering Lead), chị Hương (Trưởng phòng Kinh doanh), chị Mai (Trưởng phòng Customer Success), và anh Tuấn (CEO) — người sẽ ngồi nghe bạn trình bày roadmap Quý 3/2026 vào thứ Sáu tuần này. Backlog trước mặt bạn có 10 hạng mục lớn, không thể làm hết, và mỗi phòng ban đều có một hạng mục họ tin là "quan trọng nhất". Hãy bắt đầu.
Giai Đoạn 1: Chấm Điểm Và Ưu Tiên Một Backlog Thật Bằng Framework Có Hỗ Trợ AI
Backlog của Retasy cho Quý 3/2026 có 10 hạng mục lớn, từ đồng bộ tồn kho đa kênh đến dark mode cho app di động. Nếu bạn chấm điểm bằng cảm tính hoặc theo thứ tự "ai la to nhất", roadmap sẽ phản ánh chính trị nội bộ chứ không phải giá trị thực cho khách hàng. Đây là lúc RICE (Reach — độ phủ, Impact — mức ảnh hưởng, Confidence — độ tin cậy, Effort — công sức) và WSJF (Weighted Shortest Job First — công việc ngắn nhất có trọng số cao nhất được ưu tiên) phát huy tác dụng, và AI giúp bạn chạy cả hai framework nhanh, nhất quán, có thể trace ngược lại logic chấm điểm.
Việc đầu tiên là đưa toàn bộ 10 hạng mục backlog vào AI cùng một lúc, kèm dữ liệu thật (không phải ước lượng suông): số cửa hàng bị ảnh hưởng ước tính, dữ liệu churn, feedback từ Customer Success, effort ước lượng theo người-tháng từ Engineering Lead. AI không tự "biết" Reach hay Impact của Retasy — bạn phải cung cấp context đó, AI chỉ giúp tính toán nhất quán và phơi bày logic ra bảng để cả team review.
Các Bước Thực Hành
- Gom toàn bộ 10 hạng mục backlog Quý 3/2026 vào một bảng nguồn (Notion, Google Sheet hoặc Jira export), mỗi hạng mục kèm mô tả ngắn 1-2 câu.
- Với mỗi hạng mục, thu thập dữ liệu thô thật có: số cửa hàng có thể hưởng lợi (ước lượng từ Customer Success), dữ liệu ticket support/churn liên quan (từ Zendesk/Intercom), effort ước lượng sơ bộ từ Engineering Lead (người-tháng).
- Đưa toàn bộ dữ liệu vào AI (ChatGPT hoặc Claude), yêu cầu tính RICE score cho từng hạng mục, xuất ra bảng có xếp hạng.
- Chạy lại với 5 hạng mục có tranh cãi nhiều nhất (RICE score gần nhau hoặc bị phản đối bởi một phòng ban) bằng WSJF, để nhìn góc độ Cost of Delay (chi phí trì hoãn) mà RICE không thể hiện rõ.
- Đối chiếu hai bảng kết quả, xác định hạng mục nào có RICE thấp nhưng WSJF cao (thường là hạng mục có Reach nhỏ nhưng ảnh hưởng doanh thu tập trung, ví dụ khách hàng lớn/khách sỉ) — đây là ứng viên cần override (ghi đè) bằng phán đoán chiến lược của con người.
- Họp 30 phút với Engineering Lead và Trưởng phòng Kinh doanh để review bảng chấm điểm AI tạo ra, điều chỉnh những chỗ AI thiếu context nội bộ (ví dụ: một hạng mục đã được hứa miệng với khách VIP).
Ví Dụ Prompt
Bạn là một Product Manager giàu kinh nghiệm về prioritization framework
cho sản phẩm SaaS bán lẻ đa kênh tại Việt Nam.
Dưới đây là 10 hạng mục backlog Quý 3/2026 của Retasy, kèm dữ liệu thô:
1. Đồng bộ tồn kho realtime đa kênh (online + tại quầy): ước tính ảnh
hưởng 5.000/8.000 cửa hàng, effort 4 người-tháng, độ tin cậy dữ liệu 80%
(dựa trên 42 ticket than phiền lệch tồn kho trong Q2).
2. Thanh toán QR VietQR đa ngân hàng tại quầy: ước tính ảnh hưởng
6.500/8.000 cửa hàng, effort 2 người-tháng, độ tin cậy 90%
(feature được yêu cầu nhiều nhất trên kênh hỗ trợ).
3. Quản lý công nợ khách sỉ (B2B ledger): ước tính ảnh hưởng 1.200 cửa
hàng có bán sỉ, effort 3 người-tháng, độ tin cậy 70%.
4. Tối ưu tốc độ trang báo cáo (hiện tải 8 giây, mục tiêu dưới 2 giây):
ảnh hưởng toàn bộ 8.000 cửa hàng, effort 1,5 người-tháng, độ tin cậy 90%.
5. Chatbot AI trả lời khách trên fanpage: ảnh hưởng 2.000 cửa hàng,
effort 3 người-tháng, độ tin cậy 50% (chưa có pilot xác nhận nhu cầu).
6. In tem nhãn mã vạch hàng loạt: ảnh hưởng 3.000 cửa hàng, effort 1
người-tháng, độ tin cậy 90%.
7. Module chấm công nhân viên: ảnh hưởng 1.500 cửa hàng, effort 2,5
người-tháng, độ tin cậy 70%.
8. Tích hợp kế toán với MISA: ảnh hưởng 900 cửa hàng, effort 2
người-tháng, độ tin cậy 60%.
9. Dark mode cho app di động: ảnh hưởng 4.000 cửa hàng, effort 0,5
người-tháng, độ tin cậy 90%.
10. Báo cáo doanh thu tự động gửi qua Zalo OA mỗi tối: ảnh hưởng 5.000
cửa hàng, effort 1 người-tháng, độ tin cậy 85%.
Hãy tính RICE score cho từng hạng mục theo công thức:
RICE = (Reach x Impact x Confidence) / Effort
Trong đó Impact dùng thang: 3 = massive, 2 = high, 1 = medium, 0.5 = low.
Tự đề xuất Impact cho từng hạng mục dựa trên mô tả, giải thích lý do chọn
mức đó trong 1 câu.
Xuất kết quả dưới dạng bảng Markdown: Hạng mục | Reach | Impact | Confidence
| Effort | RICE Score, sắp xếp giảm dần theo RICE Score.
Trả lời bằng tiếng Việt, giữ nguyên thuật ngữ RICE, Reach, Impact,
Confidence, Effort.
Bây giờ hãy chạy lại phân tích WSJF (Weighted Shortest Job First) cho
5 hạng mục sau, vì đây là những hạng mục có tranh cãi giữa các phòng ban:
[Đồng bộ tồn kho, Thanh toán QR VietQR, Công nợ khách sỉ B2B, Tối ưu tốc
độ báo cáo, Dark mode].
Với mỗi hạng mục, ước lượng theo thang 1-10:
- Business Value (giá trị kinh doanh trực tiếp).
- Time Criticality (mức độ khẩn cấp nếu trì hoãn thêm 1 quý).
- Risk Reduction / Opportunity Enablement (giảm rủi ro hoặc mở ra cơ hội
mới, ví dụ: giữ chân khách sỉ lớn có nguy cơ rời bỏ).
- Job Size (quy đổi từ effort người-tháng sang thang 1-10).
Tính WSJF = (Business Value + Time Criticality + Risk Reduction) / Job Size.
Xuất bảng WSJF, so sánh thứ hạng với bảng RICE đã tính ở trên. Chỉ ra rõ
những hạng mục có thứ hạng thay đổi đáng kể giữa hai framework, và giải
thích tại sao (ví dụ Reach nhỏ nhưng cost of delay cao do liên quan doanh
thu tập trung ở một nhóm khách hàng nhỏ nhưng giá trị lớn).
Trả lời bằng tiếng Việt, giữ nguyên thuật ngữ WSJF, Business Value,
Time Criticality, Job Size.
Kết quả điển hình mà bạn sẽ thấy: RICE xếp "Tối ưu tốc độ báo cáo" (RICE ≈ 9.600, do Reach lớn và effort nhỏ) và "Thanh toán QR VietQR" (RICE ≈ 5.850) lên đầu, trong khi "Công nợ khách sỉ B2B" chỉ đạt RICE ≈ 840 vì Reach nhỏ (chỉ 1.200/8.000 cửa hàng có bán sỉ). Nhưng khi chạy WSJF, công nợ B2B nhảy lên top 3 vì Time Criticality cao — chị Hương báo rằng 3 khách sỉ lớn (chiếm 900 triệu đồng ARR cộng lại) đang cân nhắc chuyển sang đối thủ vì thiếu tính năng này. Đây chính là giá trị của việc chạy cả hai framework: RICE tốt cho việc nhìn tổng thể độ phủ, WSJF tốt hơn cho việc bắt tín hiệu "cost of delay" tập trung ở nhóm khách hàng nhỏ nhưng giá trị cao — điều một framework thuần Reach-based dễ bỏ sót.
Mẹo: Đừng bao giờ để AI tự chọn thang điểm Impact hoặc Business Value mà không giải thích lý do — luôn bắt nó viết kèm 1 câu lý giải cho mỗi con số. Nếu bạn không thể tự tay giải thích lại con số đó trước hội đồng, đừng dùng nó trong roadmap.
Giai Đoạn 2: Tạo Roadmap Theo Outcome Từ Các Theme Đã Ưu Tiên
Có bảng RICE/WSJF xếp hạng 10 hạng mục là chưa đủ để trình bày roadmap — một danh sách feature xếp theo điểm số vẫn chỉ là danh sách feature, không phải roadmap. Việc tiếp theo là nhóm các hạng mục liên quan thành theme (chủ đề) gắn với outcome (kết quả kinh doanh đo lường được), rồi xếp theme đó vào khung thời gian Now/Next/Later thay vì cam kết ngày tháng cứng cho từng feature riêng lẻ.
Từ 10 hạng mục đã chấm điểm, bạn nhóm chúng thành 4 theme: "Đồng Bộ Bán Hàng Đa Kênh Liền Mạch" (đồng bộ tồn kho, in tem mã vạch), "Thanh Toán Không Ma Sát Tại Quầy" (QR VietQR, báo cáo tự động qua Zalo OA), "Sức Khỏe Tài Chính Cho Khách Sỉ" (công nợ B2B, tích hợp MISA), và "Nền Tảng Nhanh & Đáng Tin Cậy" (tối ưu tốc độ báo cáo). Chatbot AI, module chấm công, và dark mode bị gộp vào backlog "Explore" — không đủ dữ liệu hoặc giá trị để đưa vào roadmap chính thức quý này. Mỗi theme cần gắn với một outcome cụ thể trong OKR (Objectives and Key Results — mục tiêu và kết quả then chốt) của công ty: giảm churn từ 3,2% xuống 2,5%, và tăng tỷ lệ upsell lên gói Pro thêm 15%.
Các Bước Thực Hành
- Đưa bảng RICE/WSJF đã hoàn thiện ở Giai đoạn 1 vào AI, yêu cầu nó đề xuất cách nhóm 10 hạng mục thành 3-5 theme dựa trên outcome kinh doanh chung, không nhóm theo loại công nghệ.
- Với mỗi theme, yêu cầu AI viết rõ: outcome/metric thành công, problem statement (vấn đề đang giải quyết), giả thuyết (hypothesis) tại sao giải quyết vấn đề này sẽ dịch chuyển metric, và các hạng mục backlog nằm trong theme đó.
- Đối chiếu từng theme với 2 OKR chính của công ty (giảm churn, tăng upsell Pro) — loại bỏ hoặc gộp theme không liên kết rõ ràng với OKR nào.
- Xếp 4 theme vào khung Now/Next/Later: Now (đang làm, Quý 3/2026), Next (đã cam kết hướng đi, chưa bắt đầu, Quý 4/2026), Later (đang khám phá, chưa cam kết ngày).
- Với theme ở Now, yêu cầu AI soạn "theme card" chi tiết (outcome, problem, hypothesis, phạm vi, giả định, rủi ro) để đưa vào Productboard hoặc Notion làm tài liệu tham chiếu chung cho cả team.
- Review roadmap nháp với Engineering Lead để xác nhận effort tổng theo quý là khả thi (không xếp quá 3 theme lớn cùng lúc vào Now với đội 6 dev).
Ví Dụ Prompt
Bạn là Product Manager, hãy giúp tôi nhóm 10 hạng mục backlog đã chấm
điểm RICE/WSJF sau đây thành 3-5 "theme" outcome-based (dựa trên kết quả
kinh doanh, không phải dựa trên loại công nghệ):
[PASTE BẢNG RICE/WSJF ĐÃ HOÀN THIỆN Ở GIAI ĐOẠN 1]
Công ty có 2 OKR chính trong Quý 3/2026:
- Giảm churn hàng tháng từ 3,2% xuống 2,5%.
- Tăng tỷ lệ khách hàng nâng cấp lên gói Pro thêm 15%.
Với mỗi theme đề xuất, hãy viết:
1. Tên theme (ngắn gọn, hướng outcome, không phải tên tính năng).
2. Outcome/metric mà theme này nhắm tới, liên kết rõ với 1 trong 2 OKR
trên (hoặc nêu rõ nếu theme không liên kết OKR nào — trường hợp này
cần cân nhắc loại khỏi roadmap quý này).
3. Problem statement — vấn đề khách hàng/kinh doanh đang gặp phải.
4. Giả thuyết (hypothesis) theo cấu trúc "Nếu chúng ta [làm gì], thì
[metric] sẽ [thay đổi thế nào], vì [lý do]".
5. Danh sách hạng mục backlog thuộc theme này.
Trả lời bằng tiếng Việt, giữ nguyên thuật ngữ OKR, theme, outcome, hypothesis.
Với theme "Đồng Bộ Bán Hàng Đa Kênh Liền Mạch" (Now, Quý 3/2026), hãy
soạn một theme card đầy đủ theo cấu trúc dưới đây để tôi đưa vào Productboard:
- Outcome / Success Metric
- Problem Statement
- Hypothesis
- Phạm vi (In-scope) và Ngoài phạm vi (Out-of-scope)
- Giả định (Assumptions) cần xác nhận trước khi cam kết
- Rủi ro và dependency (phụ thuộc bên ngoài, ví dụ API đối tác)
- Timeframe dự kiến
Bối cảnh: theme này gồm 2 hạng mục — "Đồng bộ tồn kho realtime đa kênh"
(RICE 3.000) và "In tem nhãn mã vạch hàng loạt" (RICE 2.700). Vấn đề gốc:
42 ticket than phiền trong Q2/2026 về lệch tồn kho giữa kênh online
(TikTok Shop, Shopee) và tại quầy, dẫn đến bán hụt hàng hoặc bán trùng.
Trả lời bằng tiếng Việt, giữ nguyên thuật ngữ theme card, in-scope,
out-of-scope, dependency.
Kết quả AI trả về cho theme card thường có dạng như sau — đây là ví dụ thực tế bạn có thể dán thẳng vào Productboard sau khi chỉnh sửa:
## Theme: Đồng Bộ Bán Hàng Đa Kênh Liền Mạch
**Outcome / Success Metric:** Giảm ticket than phiền lệch tồn kho từ
42/quý xuống dưới 10/quý; đóng góp giảm churn từ 3,2% xuống 2,5%.
**Problem Statement:** Cửa hàng bán trên nhiều kênh (TikTok Shop, Shopee,
tại quầy) không có tồn kho realtime dùng chung, dẫn đến bán hụt hàng
(oversell) hoặc giữ hàng ảo (hàng đã bán ở kênh khác nhưng vẫn hiện còn).
**Hypothesis:** Nếu tồn kho được đồng bộ realtime qua webhook giữa POS
và các kênh online, thì số ticket lệch tồn kho sẽ giảm trên 75%, vì phần
lớn nguyên nhân gốc là độ trễ đồng bộ (hiện đang batch 15 phút/lần).
**In-scope:** Đồng bộ realtime cho TikTok Shop và Shopee (2 kênh chiếm
80% giao dịch online của khách Retasy); in tem nhãn mã vạch hàng loạt
đi kèm để hỗ trợ kiểm kê nhanh khi đối soát.
**Out-of-scope:** Đồng bộ với Lazada và website riêng của khách (backlog
Later, chưa đủ dữ liệu nhu cầu).
**Assumptions:** API webhook của TikTok Shop và Shopee ổn định, không
giới hạn rate quá thấp cho use case realtime.
**Risks & Dependencies:** Phụ thuộc vào việc TikTok Shop phê duyệt quyền
truy cập webhook (thời gian phê duyệt trung bình 2-3 tuần theo kinh
nghiệm team Partnership).
**Timeframe:** Now — Quý 3/2026.
Mẹo: Nếu một hạng mục backlog không thể gắn vào theme outcome nào một cách tự nhiên, đừng ép nó vào — đó là tín hiệu hạng mục này nên nằm ở backlog "Explore" chờ thêm dữ liệu, hoặc là dấu hiệu bạn đang làm feature vì áp lực chính trị nội bộ chứ không phải vì giá trị khách hàng.
Giai Đoạn 3: Soạn Câu Chuyện Roadmap Cho Đối Tượng Exec Và Đối Tượng Engineering
Cùng một roadmap, nhưng CEO và Engineering Lead cần hai câu chuyện khác nhau — không phải vì bạn giấu thông tin, mà vì mỗi audience quan tâm một lớp thông tin khác nhau. Anh Tuấn (CEO) cần biết roadmap này giải quyết bài toán churn/doanh thu nào, bằng ngôn ngữ kết quả kinh doanh, không cần biết chi tiết webhook hay kiến trúc queue. Anh Long (Engineering Lead) và đội dev cần biết chính xác phạm vi kỹ thuật, dependency, và tại sao thứ tự làm việc lại như vậy — nếu không, khi bắt tay implement họ sẽ hỏi lại đúng những câu bạn đã trả lời ở tầng exec nhưng theo cách không đủ cụ thể để code.
Sai lầm phổ biến là viết một tài liệu roadmap duy nhất rồi cố đọc nó cho cả hai audience — kết quả là exec thấy quá chi tiết kỹ thuật gây mất tập trung, còn engineering thấy quá mơ hồ để bắt đầu breakdown thành epic/sprint. AI giúp bạn giữ nguyên một nguồn sự thật (single source of truth) là theme card đã tạo ở Giai đoạn 2, nhưng render (hiển thị) ra hai bản dịch phù hợp với hai audience, thay vì viết tay hai tài liệu tách biệt dễ lệch nhau theo thời gian.
Các Bước Thực Hành
- Lấy theme card đầy đủ đã tạo ở Giai đoạn 2 làm nguồn dữ liệu gốc, không viết lại từ đầu.
- Yêu cầu AI viết bản tóm tắt cho exec: tối đa 5-6 câu, mở đầu bằng outcome kinh doanh, không nhắc chi tiết kỹ thuật, kết thúc bằng ask cụ thể (ví dụ: cần phê duyệt ngân sách, hoặc chỉ cần thông báo).
- Yêu cầu AI viết bản brief kỹ thuật cho engineering: phạm vi chi tiết, dependency bên ngoài, rủi ro kỹ thuật, câu hỏi mở cần Engineering Lead xác nhận trước khi break down thành epic.
- Đối chiếu hai bản để đảm bảo không có mâu thuẫn về phạm vi hoặc timeline giữa bản exec và bản engineering — đây là lỗi thường gặp nhất khi viết tay riêng lẻ.
- Đưa bản exec vào slide Google Slides/Canva cho buổi trình bày hội đồng; đưa bản engineering vào Jira epic description hoặc Confluence để team dev tham chiếu khi refinement.
- Xin Engineering Lead review nhanh bản kỹ thuật trước, vì nếu có sai lệch phạm vi, phải sửa trước khi trình bày với exec, không phải sau.
Ví Dụ Prompt
Dưới đây là theme card đầy đủ của theme "Đồng Bộ Bán Hàng Đa Kênh Liền
Mạch" (Now, Quý 3/2026):
[PASTE THEME CARD TỪ GIAI ĐOẠN 2]
Hãy viết bản tóm tắt dành cho CEO và hội đồng quản trị, dùng để đưa vào
1 slide Google Slides. Yêu cầu:
- Tối đa 6 câu, không dùng thuật ngữ kỹ thuật (webhook, API, queue).
- Câu đầu tiên nêu thẳng outcome kinh doanh (số liệu churn/ticket cụ thể).
- Nêu rõ đây là theme Now hay Next, và vì sao ưu tiên nó trước các theme
khác trong quý (liên kết ngắn gọn tới RICE/WSJF score nếu cần).
- Kết thúc bằng 1 câu "ask" cụ thể dành cho hội đồng (ví dụ: xin xác
nhận ngân sách, hoặc chỉ cần for-your-information).
Trả lời bằng tiếng Việt, văn phong ngắn gọn dùng cho slide trình bày,
không dùng gạch đầu dòng dài dòng.
Từ cùng theme card trên, hãy viết một bản brief kỹ thuật (technical
brief) dành cho Engineering Lead và đội dev, dùng để đưa vào mô tả Jira
epic. Yêu cầu:
1. Phạm vi kỹ thuật chi tiết hơn bản dành cho exec — liệt kê rõ các
thành phần hệ thống bị ảnh hưởng (API tồn kho, service đồng bộ,
webhook nhận sự kiện từ TikTok Shop/Shopee).
2. Danh sách dependency bên ngoài cần Engineering Lead xác nhận trước
khi ước lượng effort chính xác (ví dụ quyền truy cập webhook, rate
limit của đối tác).
3. Danh sách câu hỏi mở (open question) cần trả lời trong buổi
backlog refinement trước khi breakdown thành sprint.
4. Không đưa số liệu churn/OKR vào phần này — engineering cần biết "làm
gì và tại sao về mặt kỹ thuật", không cần lặp lại câu chuyện kinh
doanh đã có ở brief dành cho exec.
Trả lời bằng tiếng Việt, giữ nguyên thuật ngữ kỹ thuật tiếng Anh (API,
webhook, epic, sprint, rate limit).
Một chi tiết quan trọng cần nhớ: hai bản narrative này phải cùng trỏ về một roadmap, không phải hai roadmap khác nhau. Nếu bản exec nói "Quý 3" nhưng bản engineering ghi "cần xác nhận dependency trước, có thể trễ sang đầu Quý 4", bạn phải giải quyết mâu thuẫn đó trước khi đưa cả hai ra ngoài — không phải để hai audience tự phát hiện ra sự khác biệt và mất niềm tin vào roadmap.
Mẹo: Luôn đọc thử bản dành cho exec trước một người ngoài team sản phẩm (ví dụ đồng nghiệp phòng Marketing) — nếu họ phải hỏi lại "vậy ý là gì" ở câu nào, câu đó vẫn còn quá kỹ thuật hoặc quá mơ hồ cho slide hội đồng.
Giai Đoạn 4: Diễn Tập Buổi Review Roadmap Với Phản Đối Do AI Tạo Ra
Roadmap đã có, narrative đã có cho cả hai audience — nhưng buổi trình bày thật với hội đồng thứ Sáu sẽ không diễn ra suôn sẻ như slide. Chị Hương sẽ hỏi tại sao công nợ B2B bị đẩy sang Next thay vì Now dù RICE thấp nhưng 3 khách sỉ lớn đang lung lay. Anh Long sẽ hỏi tại sao đồng bộ tồn kho và tối ưu tốc độ báo cáo lại làm cùng lúc trong khi đội chỉ có 6 dev. Anh Tuấn, với vai trò CEO, có thể hỏi một câu không nằm trong kịch bản nào bạn chuẩn bị. Cách tốt nhất để không bị động là diễn tập trước — dùng AI đóng vai từng stakeholder, tạo ra phản đối (objection) thực tế dựa trên động cơ và ưu tiên riêng của họ, rồi bạn luyện trả lời bằng dữ liệu trước khi bước vào phòng họp thật.
Kỹ thuật ở đây là cho AI biết rõ vai trò, động cơ, và mối quan tâm điển hình của từng stakeholder — không chỉ hỏi chung chung "họ sẽ phản đối gì". Một Trưởng phòng Kinh doanh thường phản đối theo hướng "khách hàng cụ thể sẽ mất", một Engineering Lead phản đối theo hướng "effort/rủi ro kỹ thuật bị đánh giá thấp", một CEO thường hỏi câu tổng quát nhất về đánh đổi (trade-off) và trách nhiệm nếu roadmap sai.
Các Bước Thực Hành
- Liệt kê từng stakeholder sẽ có mặt trong buổi review (CEO, Trưởng phòng Kinh doanh, Engineering Lead, Trưởng phòng Customer Success), kèm 1-2 câu mô tả động cơ/mối quan tâm chính của họ mà bạn biết từ các cuộc họp trước.
- Đưa roadmap hoàn chỉnh (bản exec từ Giai đoạn 3) vào AI, yêu cầu nó đóng vai từng stakeholder và đưa ra objection (phản đối) thực tế nhất mà người đó có khả năng nêu ra.
- Với mỗi objection, tự viết nháp câu trả lời trước, sau đó nhờ AI phản biện lại câu trả lời của bạn như một stakeholder khó tính, để tìm lỗ hổng trong lập luận.
- Yêu cầu AI tổng hợp "câu hỏi khó nhất" có khả năng xảy ra trong buổi — câu hỏi mang tính chiến lược, khó trả lời bằng dữ liệu đơn thuần — và chuẩn bị riêng cho câu này.
- Diễn tập lại toàn bộ (dry-run) với một đồng nghiệp đóng vai hội đồng thật trong 15-20 phút, dùng chính các objection AI đã tạo ra làm kịch bản.
- Ghi chú lại câu trả lời tốt nhất cho từng objection vào phần speaker notes của slide, để không bị lúng túng khi câu hỏi thật xuất hiện.
Ví Dụ Prompt
Bạn sẽ đóng vai lần lượt 4 stakeholder trong buổi review roadmap Quý
3/2026 của Retasy. Dưới đây là roadmap (bản dành cho exec) và thông tin
về từng người:
[PASTE BẢN ROADMAP DÀNH CHO EXEC TỪ GIAI ĐOẠN 3]
1. Anh Tuấn - CEO: quan tâm nhất đến tăng trưởng ARR và uy tín với nhà
đầu tư, thường hỏi về đánh đổi tổng thể và rủi ro nếu roadmap sai.
2. Chị Hương - Trưởng phòng Kinh doanh: đã hứa miệng tính năng công nợ
B2B với 3 khách sỉ lớn (tổng 900 triệu đồng ARR), lo lắng nếu bị đẩy
sang Next sẽ mất khách.
3. Anh Long - Engineering Lead: lo về việc đội chỉ có 6 dev nhưng roadmap
xếp 2 theme lớn cùng lúc vào Now, sợ bị quá tải và trễ deadline.
4. Chị Mai - Trưởng phòng Customer Success: quan tâm đến việc 42 ticket
lệch tồn kho mỗi quý có được giải quyết dứt điểm hay chỉ giảm một phần.
Với mỗi người, hãy đóng vai họ và đưa ra 1 objection (phản đối) thực tế
nhất, viết bằng giọng văn tự nhiên như họ sẽ nói trong phòng họp, không
phải liệt kê khô khan.
Trả lời bằng tiếng Việt, giữ nguyên các thuật ngữ ARR, roadmap, theme.
Đây là objection của Chị Hương (Trưởng phòng Kinh doanh) và câu trả lời
nháp của tôi:
Objection: [PASTE OBJECTION AI VỪA TẠO Ở TRÊN]
Câu trả lời nháp của tôi: [PASTE CÂU TRẢ LỜI BẠN TỰ VIẾT]
Hãy đóng vai Chị Hương, phản biện lại câu trả lời của tôi một cách khó
tính nhất có thể — tìm ra điểm yếu, giả định chưa được kiểm chứng, hoặc
số liệu tôi chưa đưa ra để bảo vệ lập luận. Sau đó, với vai trò cố vấn
Product Management, hãy đề xuất cách tôi nên bổ sung câu trả lời để nó
thuyết phục hơn.
Trả lời bằng tiếng Việt.
Một buổi diễn tập thực tế do AI tạo ra thường có dạng như sau — đây là ví dụ cho objection khó nhất trong buổi, cùng câu trả lời đã được chuẩn bị kỹ:
## Chị Hương — Trưởng Phòng Kinh Doanh (Objection)
"Em đã cam kết miệng với 3 khách sỉ lớn — Thời Trang Kim Anh, Mỹ Phẩm
Lan Chi, và chuỗi tạp hóa Bình Minh — rằng tính năng công nợ khách sỉ sẽ
có trong Quý 3. Ba khách này cộng lại là 900 triệu ARR. Nếu roadmap đẩy
nó sang Quý 4, em sợ họ chuyển sang đối thủ trước khi mình kịp làm."
**Câu trả lời đã chuẩn bị:** "Chị nói đúng, đây là rủi ro thật và team
đã tính đến khi xếp WSJF — công nợ B2B thực ra đứng top 3 theo WSJF dù
RICE thấp, chính vì lý do chị vừa nêu. Đề xuất của em là tách nhỏ theme
này: làm một bản MVP (phiên bản tối thiểu khả dụng) chỉ có tính năng ghi
nhận công nợ dạng xem-only trong Quý 3 — đủ để 3 khách sỉ này thấy tiến
độ thật, không phải lời hứa suông — và hoàn thiện đầy đủ tính năng nhắc
nợ tự động, xuất báo cáo công nợ vào đầu Quý 4. Em cần chị xác nhận với
3 khách rằng bản xem-only sẽ có trước 30/9, để em lock effort này vào
sprint planning tuần sau."
## Câu Hỏi Khó Nhất Của Buổi (Hardest Question of the Session)
**Anh Tuấn (CEO) hỏi:** "Nếu mình đánh cược sai — dồn lực vào tối ưu tốc
độ báo cáo và đồng bộ tồn kho, còn 3 khách sỉ lớn kia thật sự rời bỏ vì
chờ công nợ B2B — thì ai chịu trách nhiệm, và tại sao em vẫn tin roadmap
này đúng?"
**Câu trả lời đã chuẩn bị:** "Em chịu trách nhiệm về quyết định ưu tiên
này, và đây là lý do em vẫn tin nó đúng ở thời điểm hiện tại: nếu không
làm tối ưu tốc độ báo cáo, toàn bộ 8.000 cửa hàng tiếp tục chịu ảnh hưởng
mỗi ngày — đây là nguyên nhân churn lớn nhất theo dữ liệu Customer Success
6 tháng qua, không phải công nợ B2B. Rủi ro với 3 khách sỉ là thật nhưng
có thể giảm bằng MVP xem-only mà em vừa đề xuất với chị Hương, chi phí
thêm chưa tới 0,5 người-tháng. Em đề xuất mình theo dõi tín hiệu churn
của nhóm khách sỉ này hàng tuần trong suốt Quý 3 — nếu có dấu hiệu rời
bỏ sớm hơn dự kiến, em sẽ đưa công nợ B2B đầy đủ lên ưu tiên Now ngay,
đánh đổi bằng việc lùi dark mode hoặc chatbot, hai hạng mục vốn đã ở
backlog Explore."
Mẹo: Câu trả lời tốt cho "câu hỏi khó nhất" không phải là câu trả lời hoàn hảo không có rủi ro — mà là câu trả lời cho thấy bạn đã lường trước rủi ro, có phương án giảm thiểu cụ thể, và có ngưỡng theo dõi rõ ràng để biết khi nào cần đổi quyết định. Hội đồng tin PM không phải vì PM luôn đúng, mà vì PM luôn kiểm soát được tình huống.
Tổng Hợp Lại — Checklist Quy Trình Từ Đầu Đến Cuối
Dưới đây là checklist đầy đủ, gộp cả bốn giai đoạn, để bạn dùng lại mỗi khi cần chạy quy trình từ backlog thô đến buổi trình bày hội đồng — không chỉ cho Retasy mà cho bất kỳ sản phẩm nào bạn quản lý.
Giai đoạn 1 — Chấm điểm và ưu tiên backlog:
- [ ] Gom toàn bộ backlog quý vào một nguồn duy nhất, kèm mô tả ngắn gọn.
- [ ] Thu thập dữ liệu thật (Reach, dữ liệu ticket/churn, effort ước lượng) trước khi đưa vào AI — không để AI tự bịa số liệu.
- [ ] Chạy RICE cho toàn bộ backlog, xuất bảng xếp hạng có lý do rõ ràng cho từng con số Impact.
- [ ] Chạy WSJF cho các hạng mục gây tranh cãi hoặc có Reach nhỏ nhưng nghi ngờ giá trị tập trung cao.
- [ ] Đối chiếu hai bảng, xác định hạng mục cần override bằng phán đoán chiến lược của con người.
- [ ] Review bảng chấm điểm với Engineering Lead và các trưởng phòng liên quan trước khi khóa thứ tự ưu tiên.
Giai đoạn 2 — Roadmap theo outcome:
- [ ] Nhóm hạng mục đã chấm điểm thành 3-5 theme dựa trên outcome kinh doanh, không dựa trên loại công nghệ.
- [ ] Gắn mỗi theme với một OKR cụ thể của công ty; loại bỏ theme không liên kết OKR nào.
- [ ] Viết theme card đầy đủ (outcome, problem, hypothesis, scope, assumption, risk) cho các theme ở Now.
- [ ] Xếp theme vào Now/Next/Later, xác nhận effort tổng khả thi với capacity đội dev hiện có.
- [ ] Đưa roadmap nháp vào công cụ dùng chung (Productboard/Notion) để cả team truy cập.
Giai đoạn 3 — Narrative cho từng audience:
- [ ] Dùng theme card làm nguồn sự thật duy nhất cho cả hai bản narrative.
- [ ] Soạn bản exec: ngắn gọn, dẫn bằng outcome kinh doanh, không thuật ngữ kỹ thuật, có ask rõ ràng.
- [ ] Soạn bản engineering: đầy đủ phạm vi kỹ thuật, dependency, câu hỏi mở cho refinement.
- [ ] Đối chiếu hai bản, đảm bảo không mâu thuẫn về phạm vi hoặc timeline.
- [ ] Xin Engineering Lead review bản kỹ thuật trước khi đưa bản exec ra ngoài.
Giai đoạn 4 — Diễn tập buổi review:
- [ ] Liệt kê từng stakeholder sẽ tham dự, kèm động cơ/mối quan tâm chính của họ.
- [ ] Dùng AI đóng vai từng stakeholder, tạo objection thực tế dựa trên roadmap bản exec.
- [ ] Tự viết nháp câu trả lời, nhờ AI phản biện lại như stakeholder khó tính để tìm lỗ hổng.
- [ ] Xác định và chuẩn bị riêng cho "câu hỏi khó nhất" có khả năng xảy ra.
- [ ] Diễn tập dry-run 15-20 phút với đồng nghiệp trước buổi họp thật.
- [ ] Ghi chú câu trả lời tốt nhất vào speaker notes của slide trình bày.
Trước khi bước vào phòng họp hội đồng:
- [ ] Roadmap, theme card, bản exec, và bản engineering đã đồng nhất về phạm vi và timeline.
- [ ] Mọi con số trên slide đều có thể truy vết ngược lại dữ liệu gốc (RICE/WSJF, ticket, ARR).
- [ ] Có sẵn ngưỡng theo dõi (trigger) để biết khi nào cần điều chỉnh roadmap giữa quý.
Những Điểm Chính Cần Nhớ
- Backlog scoring, roadmap, narrative, và stakeholder review không phải bốn việc tách rời — chúng là một pipeline liên tục, mỗi bước dùng lại kết quả của bước trước, không viết lại từ đầu.
- RICE tốt cho việc nhìn tổng thể độ phủ (Reach), nhưng dễ đánh giá thấp các hạng mục có Reach nhỏ mà giá trị tập trung cao — luôn chạy thêm WSJF cho các hạng mục gây tranh cãi.
- Roadmap thật sự là tập hợp theme gắn với outcome và OKR, không phải danh sách feature xếp theo điểm số — nếu một hạng mục không gắn được vào outcome nào, nó không thuộc về roadmap chính thức.
- Một nguồn sự thật (theme card), nhiều bản narrative — đừng viết tay hai tài liệu tách biệt cho exec và engineering, vì chúng sẽ lệch nhau theo thời gian.
- Diễn tập phản đối trước khi vào phòng họp thật không phải là bước thừa — đó là cách rẻ nhất để tránh bị động trước câu hỏi khó, và AI đóng vai stakeholder là công cụ luyện tập hiệu quả vì có thể lặp lại nhiều lần với chi phí gần bằng không.
- Câu trả lời tốt cho câu hỏi khó nhất không cần hoàn hảo — nó cần cho thấy bạn đã lường trước rủi ro, có phương án giảm thiểu cụ thể, và có ngưỡng theo dõi để biết khi nào cần đổi quyết định.
- AI tăng tốc từng bước trong pipeline này, nhưng quyết định override, chịu trách nhiệm trước hội đồng, và đọc đúng động cơ thật của từng stakeholder vẫn luôn là việc của con người — đó là lý do PM vẫn là người đứng trước phòng họp, không phải AI.