QuanLyKho là một SaaS quản lý kho và tồn kho dành cho SME (doanh nghiệp vừa và nhỏ) tại Việt Nam, hiện có 1.400 khách hàng trả phí và MRR khoảng 2,1 tỷ đồng. Số liệu tổng churn hàng tháng của công ty là 6,8% — nằm trong ngưỡng chấp nhận được với SaaS B2B SME. Nhưng khi Linh, Senior PM phụ trách mảng Onboarding & Retention, cắt dữ liệu theo cohort, cô phát hiện một con số gây sốc: nhóm khách hàng mới onboard trong 90 ngày đầu có tỷ lệ churn tích lũy lên tới 34% — gần gấp đôi mức trung bình. Nói cách khác, cứ 3 khách hàng mới ký hợp đồng thì có hơn 1 khách hàng rời đi trước khi kịp thấy giá trị thực sự của sản phẩm.
Ban lãnh đạo chốt OKR quý 3/2026 cho team của Linh: "Giảm churn 90-ngày-đầu từ 34% xuống 20%". Đây là bài toán lớn, có deadline, có số đo rõ ràng, và đụng chạm tới cả discovery, planning, delivery lẫn measurement. Đúng nghĩa một sáng kiến để chạy toàn bộ agentic PM loop (Discover → Define/Plan → Deliver → Measure) mà 5 bài trước trong module này đã dạy riêng lẻ.
Bài hands-on này sẽ đưa bạn đi qua toàn bộ hành trình đó — không phải chỉ hướng dẫn "bạn hãy làm", mà show luôn từng prompt, từng output AI trả về, từng bảng go/no-go, đúng như Linh và team đã chạy thật. Mục tiêu là để bạn nhìn thấy agentic PM workflow không phải là một khái niệm trừu tượng, mà là một chuỗi input → agent → output → quyết định con người, lặp lại nhiều lần cho tới khi sáng kiến đi vào production và được đo lường.
Team của Linh: Linh (Senior PM), Minh (BA), An (Data Analyst), và squad delivery "Falcon" (5 kỹ sư + 1 QA). Công cụ: Claude Projects làm kho ngữ cảnh discovery, ChatGPT để brainstorm nhanh, Productboard quản lý opportunity backlog, Jira + Confluence cho delivery, Amplitude đo lường hành vi, Slack + n8n để nối các bước agentic lại thành một chuỗi tự động có cổng phê duyệt của con người.
Thiết Lập Agentic Workflow — Đầu Vào Discovery, Bối Cảnh Planning, Và Tích Hợp Delivery
Trước khi giao việc cho bất kỳ AI agent nào, Linh phải làm một việc mà nhiều PM hay bỏ qua: dọn dẹp và tập trung ngữ cảnh (context). Một agent chỉ tốt bằng dữ liệu nó được cho ăn — nếu ném một prompt mơ hồ vào ChatGPT mà không có dữ liệu nền, kết quả sẽ là những insight chung chung, vô thưởng vô phạt. Bước setup này quyết định 80% chất lượng của toàn bộ workflow phía sau.
Linh cần ba nhóm ngữ cảnh:
- Discovery inputs: 22 bản ghi phỏng vấn khách hàng đã churn trong quý trước (transcript từ Zoom, đã anonymize), 340 ticket hỗ trợ có tag "onboarding" trong 6 tháng qua, và dữ liệu funnel onboarding từ Amplitude (bao nhiêu % khách hàng hoàn thành từng bước setup: tạo kho, nhập tồn kho đầu kỳ, mời thành viên team, tích hợp với phần mềm kế toán).
- Planning context: roadmap hiện tại của quý 3/2026 (đã có trong Productboard), OKR công ty, và các ràng buộc về nguồn lực (squad Falcon chỉ có capacity ~34 story point/sprint).
- Delivery integration: Jira project "WMS", kênh Slack #squad-falcon, nhịp sprint 2 tuần, và quy tắc Definition of Done hiện có trong Confluence.
Linh tạo một Claude Project riêng tên "Churn90-Q3" và upload toàn bộ 3 nhóm dữ liệu trên làm project knowledge. Đây là bước "wiring" — nối các nguồn dữ liệu rời rạc thành một ngữ cảnh thống nhất mà mọi agent sau này (discovery agent, planning agent, delivery agent, measurement agent) đều có thể truy cập nhất quán, tránh tình trạng mỗi bước lại phải giải thích lại bối cảnh từ đầu.
Các Bước Thực Hành
- Tạo một Claude Project (hoặc workspace tương đương) đặt tên theo sáng kiến, ví dụ "Churn90-Q3", để làm nơi lưu trữ ngữ cảnh dùng chung cho cả 4 giai đoạn.
- Thu thập và upload discovery inputs: transcript phỏng vấn khách hàng churn, export ticket hỗ trợ (CSV từ Zendesk/Intercom), báo cáo funnel onboarding (export từ Amplitude).
- Upload planning context: snapshot roadmap quý hiện tại, file OKR, bảng capacity của squad delivery.
- Kết nối delivery integration: cấp quyền đọc/ghi Jira project WMS cho agent (qua MCP hoặc Zapier/n8n connector), tạo Slack webhook để agent có thể đăng thông báo vào #squad-falcon.
- Dùng n8n dựng một workflow khung: Trigger thủ công (Linh bấm "Run") → Discovery Agent → điểm dừng chờ phê duyệt (approval gate) → Planning Agent → điểm dừng chờ phê duyệt → Delivery Agent → Measurement Agent. Mỗi điểm dừng gửi thông báo Slack cho Linh kèm link output để review.
- Viết một "system prompt" dùng chung, mô tả bối cảnh công ty, sản phẩm, khách hàng mục tiêu, để mọi agent trong chuỗi đều hiểu đúng ngữ cảnh mà không cần lặp lại mỗi lần.
Ví Dụ Prompt
Bạn là trợ lý discovery cho sản phẩm QuanLyKho — SaaS quản lý kho cho SME Việt Nam.
Tôi vừa upload vào project này:
- 22 transcript phỏng vấn khách hàng đã churn trong 90 ngày đầu (quý 2/2026)
- 340 ticket hỗ trợ tag "onboarding" (6 tháng gần nhất)
- Báo cáo funnel onboarding từ Amplitude (tỷ lệ hoàn thành từng bước setup)
Hãy xác nhận bạn đã nắm được cấu trúc của 3 nguồn dữ liệu này, và liệt kê
3-5 câu hỏi bạn cần tôi làm rõ thêm trước khi bắt đầu phân tích discovery,
để đảm bảo output sau này đủ chính xác và có thể hành động được.
Trả lời bằng tiếng Việt, giữ nguyên thuật ngữ kỹ thuật tiếng Anh.
Sample output (AI trả về):
Đã nắm được cấu trúc 3 nguồn dữ liệu. Trước khi phân tích discovery sâu, tôi cần làm rõ:
1. Ngưỡng "onboard thành công" của QuanLyKho là gì — hoàn thành cả 4 bước setup, hay chỉ cần bước "nhập tồn kho đầu kỳ"?
2. 22 khách hàng churn có phân bổ đều theo ngành nghề (bán lẻ, F&B, phân phối) hay tập trung vào một nhóm?
3. Ticket hỗ trợ tag "onboarding" có được phân loại theo mức độ nghiêm trọng (severity) không, hay tôi cần tự suy luận từ nội dung?
4. Funnel Amplitude có mốc thời gian cụ thể cho từng bước (ví dụ: ngày thứ mấy sau ký hợp đồng) không?
5. Có ràng buộc nào về ngân sách/kỹ thuật (ví dụ: không được thay đổi luồng tích hợp kế toán trong quý này) mà tôi cần biết trước khi đề xuất giải pháp?
Mẹo: Đừng bỏ qua bước "agent hỏi lại trước khi phân tích". Một agent hỏi đúng câu hỏi làm rõ ngữ cảnh trước khi chạy insight thường cho kết quả sát thực tế hơn hẳn so với agent lao vào phân tích ngay — vì bạn (con người) buộc phải trả lời và qua đó tự làm rõ luôn cả cho chính mình những giả định còn mập mờ.
Thực Thi Từng Bước Của Agentic PM Loop Với Sự Hỗ Trợ Của AI
Sau khi wiring xong, Linh chạy toàn bộ vòng lặp Discover → Define/Plan → Deliver → Measure cho sáng kiến "giảm churn 90 ngày" — mỗi bước cho ra một artifact cụ thể, và artifact đó trở thành đầu vào cho bước kế tiếp. Đây là phần lõi thể hiện agentic workflow không phải 4 hoạt động tách rời, mà là một chuỗi (chain) có tính kế thừa.
Bước 1 — Discover: Discovery agent phân tích 22 transcript + 340 ticket + dữ liệu funnel, tổng hợp thành một discovery synthesis doc.
Bước 2 — Define/Plan: Planning agent lấy discovery synthesis doc làm input, biến các insight thành các opportunity đã được ưu tiên hóa (prioritized opportunities) và một backlog update cụ thể trong Productboard.
Bước 3 — Deliver: Delivery agent lấy top opportunity đã chọn, sinh ra breakdown task trong Jira, ước lượng story point, và tạo sprint plan cho squad Falcon.
Bước 4 — Measure: Measurement agent, sau khi sprint chạy xong và tính năng lên production, tự động kéo dữ liệu Amplitude để dựng báo cáo đo lường tác động lên churn 90-ngày.
Các Bước Thực Hành
- Chạy discovery agent với toàn bộ dữ liệu đã upload, yêu cầu output là một discovery synthesis doc có cấu trúc: Top pain points (xếp hạng theo tần suất + mức độ nghiêm trọng), Jobs-to-be-done của khách hàng mới onboard, và Quotes minh họa.
- Đưa discovery synthesis doc làm input cho planning agent, yêu cầu chuyển mỗi pain point thành một opportunity theo khung ICE hoặc RICE (Reach, Impact, Confidence, Effort), rồi xếp hạng.
- Chọn thủ công (con người) opportunity ưu tiên nhất — đây là bước quyết định, không giao hết cho AI.
- Đưa opportunity đã chọn cho delivery agent, yêu cầu breakdown thành epic/story trong Jira kèm ước lượng effort, và đề xuất sprint plan phù hợp với capacity 34 story point của squad Falcon.
- Sau khi sprint hoàn thành và tính năng release, chạy measurement agent để kéo dữ liệu Amplitude, so sánh cohort trước/sau và tính lại churn 90-ngày của cohort mới.
- Lưu toàn bộ 4 artifact (discovery doc, opportunity backlog, sprint plan, measurement report) vào Confluence, liên kết chéo (cross-link) để bất kỳ ai trong công ty cũng truy vết được từ insight ban đầu tới kết quả đo lường cuối cùng.
Ví Dụ Prompt
Prompt Discover:
Dựa trên 22 transcript phỏng vấn khách hàng churn và 340 ticket hỗ trợ
tag "onboarding" đã upload, hãy tổng hợp một Discovery Synthesis Doc gồm:
1. Top 5 pain point trong 90 ngày đầu, xếp hạng theo (a) số lần xuất hiện
trong dữ liệu và (b) mức độ ảnh hưởng tới quyết định churn (dựa trên
ngôn ngữ khách hàng dùng khi được hỏi lý do rời đi).
2. Với mỗi pain point, trích 1-2 quote nguyên văn (đã ẩn danh) minh họa.
3. Một job-to-be-done tổng quát mô tả điều khách hàng SME thực sự cần
đạt được trong 90 ngày đầu dùng QuanLyKho.
Trả lời bằng tiếng Việt, giữ nguyên thuật ngữ kỹ thuật tiếng Anh.
Sample output — Discovery Synthesis Doc (rút gọn):
| # | Pain Point | Tần suất | Quote minh họa |
|---|---|---|---|
| 1 | Không tự đối chiếu được tồn kho với dữ liệu kế toán, phải nhập tay 2 lần | 61% ticket | "Em phải copy sang Excel rồi nhập lại vào phần mềm kế toán, mất cả buổi." |
| 2 | Không hiểu cách thiết lập mã kho/vị trí lưu trữ ngay từ đầu, dẫn tới nhập sai dữ liệu tồn đầu kỳ | 44% ticket | "Lúc nhập tồn kho đầu kỳ em không biết chia theo kho nào, làm sai phải làm lại." |
| 3 | Không có ai hướng dẫn trực tiếp trong 2 tuần đầu, chỉ có tài liệu chung chung | 38% transcript churn | "Bên em không có ai support riêng, đọc docs không hiểu nổi." |
| 4 | Mời thành viên team bị lỗi phân quyền, nhân viên kho không thấy đúng module | 27% ticket | — |
| 5 | Không thấy giá trị rõ ràng trong 30 ngày đầu vì chưa dùng hết tính năng | 5/22 transcript churn nêu trực tiếp | "Dùng 1 tháng thấy cũng như Excel, không thấy khác biệt nhiều." |
Job-to-be-done tổng quát: "Khi tôi mới chuyển từ quản lý kho bằng Excel/giấy sang phần mềm, tôi cần thiết lập đúng dữ liệu nền (kho, tồn đầu kỳ, phân quyền) một cách nhanh và không sai sót, để trong 30 ngày đầu tôi thấy rõ phần mềm tiết kiệm thời gian hơn cách cũ — nếu không tôi sẽ quay lại cách làm cũ trước khi hết 90 ngày."
Prompt Plan (dùng discovery doc trên làm input):
Dựa trên Discovery Synthesis Doc ở trên, hãy chuyển 5 pain point thành
5 opportunity cụ thể, chấm điểm theo khung RICE (Reach: % khách hàng mới
bị ảnh hưởng mỗi quý; Impact: 1-3; Confidence: %; Effort: story point ước
lượng thô). Xếp hạng theo RICE score giảm dần và đề xuất top 1 nên đưa
vào sprint kế tiếp.
Trả lời bằng tiếng Việt, giữ nguyên thuật ngữ kỹ thuật tiếng Anh.
Sample output — Prioritized Opportunity Backlog:
| Opportunity | Reach | Impact | Confidence | Effort | RICE |
|---|---|---|---|---|---|
| Auto-đối chiếu tồn kho với phần mềm kế toán phổ biến (MISA, Fast) | 90% | 3 | 70% | 8 | 23,6 |
| Wizard thiết lập mã kho/vị trí lưu trữ có gợi ý mẫu theo ngành | 65% | 2 | 80% | 5 | 20,8 |
| Chương trình "Customer Success 14 ngày đầu" (checklist + nhắc việc trong app) | 100% | 2 | 60% | 3 | 40 |
| Sửa lỗi phân quyền khi mời thành viên | 40% | 1 | 90% | 2 | 18 |
| In-app milestone hiển thị "đã tiết kiệm X giờ so với Excel" | 55% | 1 | 50% | 5 | 5,5 |
Đề xuất: opportunity "Chương trình Customer Success 14 ngày đầu" có RICE cao nhất (40) và effort thấp — nên đưa vào sprint kế tiếp trước, song song lên roadmap cho "Auto-đối chiếu tồn kho" ở sprint sau vì effort lớn hơn nhưng impact dài hạn cao.
Prompt Deliver (dùng opportunity đã chọn làm input):
Opportunity đã chọn: "Chương trình Customer Success 14 ngày đầu" — checklist
onboarding trong app + nhắc việc tự động qua email/in-app cho khách hàng
mới trong 14 ngày đầu. Squad Falcon có capacity 34 story point/sprint 2 tuần.
Hãy breakdown thành epic và story cho Jira project WMS, ước lượng story
point cho từng story, và đề xuất sprint plan không vượt capacity.
Trả lời bằng tiếng Việt, giữ nguyên thuật ngữ kỹ thuật tiếng Anh.
Sample output — Sprint Plan (Jira WMS, Sprint 14):
| Story | Mô tả | Story point |
|---|---|---|
| WMS-441 | Thiết kế checklist 5 bước onboarding hiển thị trên dashboard | 3 |
| WMS-442 | API lưu trạng thái hoàn thành từng bước checklist theo tài khoản | 5 |
| WMS-443 | Job gửi email nhắc việc ngày 3, 7, 12 nếu chưa hoàn thành bước tương ứng | 8 |
| WMS-444 | Banner in-app "còn X bước để hoàn tất setup" | 3 |
| WMS-445 | Dashboard nội bộ cho CS team theo dõi tiến độ checklist của từng khách hàng | 8 |
| WMS-446 | QA + viết test tự động cho toàn bộ luồng | 5 |
| Tổng | 32/34 |
Prompt Measure (chạy sau khi release, dùng dữ liệu Amplitude):
Tính năng "Chương trình Customer Success 14 ngày đầu" đã release ngày
15/8/2026. Hãy so sánh churn 90-ngày của cohort khách hàng ký hợp đồng
từ 15/8 đến 15/9/2026 (đã dùng tính năng mới) với cohort quý trước
(chưa có tính năng). Trả về bảng so sánh và nhận định có đạt được xu
hướng hướng tới mục tiêu OKR (giảm churn 90-ngày từ 34% xuống 20%) không.
Trả lời bằng tiếng Việt, giữ nguyên thuật ngữ kỹ thuật tiếng Anh.
Sample output — Measurement Report (sau 90 ngày theo dõi cohort mới):
| Chỉ số | Cohort cũ (Q2/2026) | Cohort mới (từ 15/8/2026) | Thay đổi |
|---|---|---|---|
| Churn 90-ngày | 34% | 26% | -8 điểm % |
| % hoàn thành checklist trong 14 ngày | 41% | 68% | +27 điểm % |
| Thời gian tới "milestone tồn kho đầu kỳ chính xác" | 9,2 ngày | 5,4 ngày | -3,8 ngày |
Nhận định: xu hướng đúng hướng nhưng chưa đạt target 20%. Còn cách mục tiêu 6 điểm %, cần thêm can thiệp cho pain point #1 (auto-đối chiếu kế toán) — vốn có RICE cao thứ hai nhưng chưa triển khai — để đạt OKR trọn vẹn trong quý.
Mẹo: Luôn để artifact ở bước trước làm input tường minh cho prompt ở bước sau (copy-paste hoặc để agent tự đọc từ project knowledge) — đừng bắt agent "nhớ" ngữ cảnh qua nhiều phiên chat rời rạc. Điều này giữ cho chuỗi discover → plan → deliver → measure luôn nhất quán về số liệu và ngôn ngữ.
Rà Soát Kết Quả Ở Mỗi Giai Đoạn Và Ra Quyết Định Go/No-Go
Agentic workflow không có nghĩa AI chạy tự động từ đầu tới cuối mà không ai kiểm tra. Điểm khác biệt giữa "agentic" và "tự động hóa mù" chính là các cổng phê duyệt (approval gate) — nơi con người dừng lại, đọc kỹ output, và quyết định go/no-go trước khi cho phép chuỗi tiếp tục. Linh thiết lập 3 checkpoint bắt buộc trong workflow n8n của mình.
Các Bước Thực Hành
- Xác định trước các checkpoint go/no-go ngay khi thiết kế workflow (không phải bổ sung sau khi phát hiện lỗi) — với sáng kiến này là: sau discovery synthesis, sau khi chọn opportunity/backlog, và sau khi có cảnh báo rủi ro delivery.
- Ở mỗi checkpoint, chuẩn bị một bảng tiêu chí go/no-go cụ thể (không chỉ "trông ổn không" mà là các câu hỏi kiểm chứng được).
- Bắt agent dừng lại và chờ phê duyệt bằng cơ chế kỹ thuật (n8n approval node, hoặc đơn giản là Slack message yêu cầu react ✅/❌) — không để agent tự chạy tiếp.
- Ghi lại quyết định và lý do vào Confluence, kể cả khi quyết định là "revise" hoặc "reject" — đây là dữ liệu quý cho lần chạy workflow tiếp theo.
- Với quyết định "revise", đưa phản hồi cụ thể trở lại agent (không chỉ nói "chưa ổn") để agent chạy lại có định hướng rõ ràng.
Ví Dụ Prompt
Checkpoint 1 — Sau Discovery Synthesis:
| Tiêu chí | Đạt? |
|---|---|
| Có ít nhất 3 pain point được trích dẫn từ ≥ 30% dữ liệu (không phải outlier cá biệt) | ✅ (pain point #1, #2, #3 đều > 38%) |
| Quote minh họa là quote thật, không bị agent diễn giải quá tay | ✅ (Linh đối chiếu ngẫu nhiên 5 quote với transcript gốc) |
| Job-to-be-done khớp với hiểu biết thực tế của PM về khách hàng | ✅ |
| Không bỏ sót nhóm khách hàng lớn nào (ví dụ theo ngành nghề) | ⚠️ — thiếu phân tích riêng cho nhóm ngành F&B |
Quyết định: REVISE (không phải reject toàn bộ) — yêu cầu agent chạy lại riêng phần phân tích theo ngành F&B trước khi chuyển sang planning agent.
Discovery Synthesis Doc tốt, nhưng thiếu phân tích riêng cho nhóm khách
hàng ngành F&B (chiếm 22% trong tổng số 22 transcript). Hãy bổ sung: nhóm
F&B có pain point khác biệt gì so với nhóm bán lẻ/phân phối nói chung
không? Nếu có, có nên tách thành opportunity riêng không?
Trả lời bằng tiếng Việt, giữ nguyên thuật ngữ kỹ thuật tiếng Anh.
Checkpoint 2 — Sau khi có Opportunity Backlog:
| Tiêu chí | Đạt? |
|---|---|
| RICE score được tính dựa trên số liệu thật (không phải ước lượng cảm tính của agent) | ✅ (Reach lấy từ Amplitude, Effort do BA Minh thẩm định lại) |
| Opportunity đề xuất không xung đột với cam kết roadmap đã công bố cho khách hàng | ✅ |
| Effort ước lượng nằm trong khả năng thực tế của squad (không quá lạc quan) | ✅ (Minh giảm ước lượng WMS-443 từ 5 xuống 8 điểm sau khi review kỹ hơn — thực ra tăng lên vì phát hiện cần thêm xử lý edge case) |
| Có đủ ít nhất 1 opportunity effort thấp để triển khai nhanh, tạo momentum | ✅ ("Customer Success 14 ngày" effort thấp, RICE cao nhất) |
Quyết định: GO — phê duyệt đưa "Chương trình Customer Success 14 ngày đầu" vào sprint 14, đồng thời đưa "Auto-đối chiếu tồn kho" vào roadmap sprint 16-17.
Checkpoint 3 — Cảnh báo rủi ro delivery (giữa sprint):
Delivery agent tự động quét Jira mỗi ngày và phát hiện WMS-443 (job gửi email nhắc việc) đang trễ tiến độ vì phụ thuộc vào một API bên thứ ba (dịch vụ email) chưa được duyệt bảo mật.
| Tiêu chí | Đạt? |
|---|---|
| Rủi ro có ảnh hưởng tới ngày release cam kết không? | ⚠️ Có, trễ ước tính 3 ngày |
| Có phương án thay thế khả thi trong sprint này không? | ✅ Dùng lại dịch vụ email nội bộ đã duyệt sẵn thay vì bên thứ ba mới |
| Việc trễ có ảnh hưởng tới OKR quý không? | ❌ Không đáng kể (release lệch 3 ngày trong sprint 2 tuần, vẫn còn 6 tuần theo dõi churn 90-ngày) |
Quyết định: GO WITH MITIGATION — chấp nhận trễ 3 ngày, chuyển sang dịch vụ email nội bộ, Linh thông báo trong #squad-falcon và cập nhật ngày release dự kiến cho stakeholder.
Mẹo: Thiết kế tiêu chí go/no-go dạng bảng kiểm (checklist) kiểm chứng được (verifiable) — tránh tiêu chí mơ hồ như "output nhìn hợp lý". Một tiêu chí tốt phải trả lời được bằng dữ liệu, không phải cảm tính, để bất kỳ ai trong team cũng ra cùng một quyết định khi đọc cùng dữ liệu.
Nhìn Lại: Agentic Workflow Tự Động Hóa Gì Và Đâu Là Nơi Cần Phán Đoán Của Con Người
Sau khi kết thúc quý, Linh tổ chức một buổi retro riêng cho chính cái workflow — không phải retro về sprint, mà retro về cách team dùng AI agent xuyên suốt cả 4 giai đoạn. Đây là bước phản tư (reflect) quan trọng để cải thiện workflow cho sáng kiến tiếp theo, và cũng là cách để trả lời câu hỏi mà mọi PM cấp trên đều sẽ hỏi: "Rốt cuộc AI làm được bao nhiêu phần trăm việc, và phần nào vẫn cần con người?"
Các Bước Thực Hành
- Liệt kê lại toàn bộ artifact đã tạo ra ở mỗi giai đoạn (discovery doc, opportunity backlog, sprint plan, measurement report, các quyết định go/no-go).
- Với mỗi artifact, đánh dấu rõ phần nào AI tạo ra gần như hoàn chỉnh, phần nào con người phải sửa đáng kể hoặc tự quyết định hoàn toàn.
- Ước lượng thời gian tiết kiệm được so với cách làm truyền thống (không dùng agentic workflow) cho từng giai đoạn.
- Ghi nhận những lần agent "sai" hoặc "ảo giác" (hallucinate) số liệu, để rút kinh nghiệm về việc kiểm chứng.
- Cập nhật lại system prompt và checklist go/no-go dùng chung, dựa trên bài học lần này, để sáng kiến tiếp theo chạy mượt hơn.
Ví Dụ Prompt
Tôi vừa hoàn thành một chu kỳ agentic PM workflow cho sáng kiến giảm
churn 90-ngày. Dưới đây là tóm tắt: [dán tóm tắt 4 artifact + 3 quyết
định go/no-go]. Hãy giúp tôi liệt kê: (1) những việc AI agent tự làm mà
gần như không cần sửa, (2) những việc AI đề xuất nhưng con người phải
sửa/quyết định lại đáng kể, (3) rủi ro nếu lần tới tôi để AI tự động
hoàn toàn ở bước nào đó mà không có go/no-go.
Trả lời bằng tiếng Việt, giữ nguyên thuật ngữ kỹ thuật tiếng Anh.
Sample output — bảng phản tư do AI hỗ trợ tổng hợp (Linh bổ sung, chỉnh sửa lại):
| Việc | Agentic workflow tự động hóa | Con người (PM/BA) vẫn phải làm |
|---|---|---|
| Discovery | Đọc và tổng hợp 22 transcript + 340 ticket trong vài phút thay vì nhiều ngày; phát hiện pattern tần suất pain point | Xác minh quote không bị agent diễn giải sai lệch; phát hiện lỗ hổng thiếu phân tích nhóm F&B (agent không tự nhận ra) |
| Ưu tiên hóa | Tính RICE score nhất quán, không thiên vị theo cảm tính cá nhân | Thẩm định lại Effort với đội kỹ thuật thực tế (agent ước lượng thấp hơn thực tế ở WMS-443); quyết định opportunity nào đi trước dựa trên chiến lược công ty, không chỉ điểm số |
| Lập kế hoạch delivery | Breakdown epic/story nhanh, tính tổng story point khớp capacity | Đàm phán với squad về độ ưu tiên khi có xung đột với việc khác; quyết định trade-off khi phát hiện rủi ro API bên thứ ba |
| Đo lường | Kéo và so sánh dữ liệu cohort tự động, tính lại churn theo thời gian thực | Diễn giải "còn cách target 6 điểm %" nghĩa là gì cho chiến lược quý sau; quyết định có cần can thiệp thêm ngay hay chờ thêm dữ liệu |
| Go/No-Go | Chuẩn bị sẵn bảng dữ liệu để đối chiếu tiêu chí | Ra quyết định cuối cùng, chịu trách nhiệm giải trình với stakeholder |
Bài học rút ra:
- AI tiết kiệm nhiều nhất ở khâu tổng hợp dữ liệu thô quy mô lớn (discovery) và tính toán có công thức (RICE, story point) — đây là việc tốn thời gian nhưng ít đòi hỏi phán đoán chiến lược.
- AI hay bỏ sót "phân khúc ẩn" trong dữ liệu (ví dụ nhóm F&B) nếu không được nhắc rõ — con người cần chủ động đặt câu hỏi kiểm tra thay vì tin output đầu tiên.
- Quyết định đánh đổi (trade-off) mang tính chiến lược — chọn opportunity nào đi trước, chấp nhận trễ delivery hay không — luôn phải là con người, vì nó gắn với trách nhiệm giải trình và hiểu biết ngữ cảnh chính trị/quan hệ mà agent không có.
- Go/no-go checklist càng cụ thể, càng giảm rủi ro "tự động hóa mù" — nhưng chính con người phải thiết kế checklist đó, AI không tự nghĩ ra tiêu chí kiểm chứng phù hợp với văn hóa và rủi ro riêng của công ty.
Mẹo: Sau mỗi sáng kiến lớn, dành 30 phút làm "retro cho chính cái workflow" chứ không chỉ retro cho sản phẩm. Đây là cách duy nhất để agentic PM workflow của bạn được cải thiện liên tục thay vì lặp lại cùng một sai sót ở sáng kiến tiếp theo.
Những Điểm Chính Cần Nhớ
- Wiring ngữ cảnh (discovery inputs, planning context, delivery integration) vào một nơi tập trung trước khi chạy agent là bước quyết định chất lượng của toàn bộ workflow — đừng bỏ qua để "tiết kiệm thời gian".
- Agentic PM loop hiệu quả nhất khi artifact của bước trước trở thành input tường minh cho bước sau: discovery synthesis → opportunity backlog → sprint plan → measurement report, tạo thành một chuỗi có thể truy vết từ đầu đến cuối.
- Go/no-go checkpoint không phải thủ tục hình thức — nó phải có tiêu chí kiểm chứng được bằng dữ liệu, và mọi quyết định (kể cả revise/reject) cần được ghi lại làm tư liệu cho lần sau.
- Agentic workflow tự động hóa tốt các việc tốn thời gian nhưng có công thức rõ ràng (tổng hợp dữ liệu lớn, tính điểm ưu tiên, breakdown task) — nhưng quyết định chiến lược, đánh đổi nguồn lực, và trách nhiệm giải trình luôn thuộc về con người.
- Kết thúc mỗi chu kỳ, hãy phản tư về chính cái workflow (không chỉ về kết quả sản phẩm) để liên tục tinh chỉnh system prompt, checklist go/no-go, và cách wiring ngữ cảnh cho sáng kiến tiếp theo.