·

Tiếng Việt: PM Evolving Role

PM Evolving Role

9 giờ sáng thứ Hai, một PM tại một fintech app mở laptop lên với to-do list quen thuộc: viết lại 8 user story cho sprint tới từ note họp với stakeholder tuần trước, tổng hợp 200 phản hồi từ khảo sát NPS quý này thành vài insight chính, kéo số liệu conversion funnel từ dashboard để chuẩn bị cho buổi review với leadership chiều nay, và soạn một bản changelog cho release cuối tuần. Nếu làm thủ công đúng nghĩa, cả 4 việc này ngốn gần trọn một ngày làm việc — và đó là ngày không còn thời gian cho việc PM thực sự cần làm: suy nghĩ xem tính năng nào đáng làm tiếp theo, tại sao, và đánh đổi ra sao. Giờ hình dung một kịch bản khác: PM đó dùng AI agent để draft cả 8 user story trong 10 phút, có một agent khác chạy phân tích NPS và trả về theme kèm trích dẫn gốc, một agent thứ ba tự kéo dữ liệu funnel và tóm tắt xu hướng, còn changelog thì được sinh ra từ commit log và Jira ticket đã đóng. PM chỉ còn việc đọc, sửa, quyết định — và dành phần lớn buổi sáng để suy nghĩ về ưu tiên quý tới. Đây không phải viễn cảnh xa vời, mà là thực tế đang diễn ra ở nhiều team ngay lúc này. Bài học hôm nay sẽ đi sâu vào việc vai trò PM đang dịch chuyển ra sao khi AI agent (tác nhân AI có khả năng tự thực thi nhiều bước) trở thành đồng đội thực sự trong công việc hàng ngày, việc gì nên giao cho AI, và bộ năng lực mới nào PM cần xây dựng để không bị bỏ lại phía sau.

Từ Người Thực Thi Tác Vụ Đến Người Điều Phối Chiến Lược

Trong phần lớn lịch sử nghề PM, một tỷ lệ đáng ngạc nhiên thời gian làm việc không dành cho tư duy chiến lược, mà dành cho thực thi tác vụ mang tính lặp lại: viết story, format lại slide, đối chiếu số liệu giữa các dashboard, chạy theo stakeholder xin feedback, note lại biên bản họp. Nhiều khảo sát trong ngành ước tính PM dành 60-70% thời gian cho các việc vận hành (operational work) như vậy, chỉ còn một phần nhỏ cho việc thật sự tạo ra giá trị chiến lược: hiểu vấn đề khách hàng, định hình tầm nhìn sản phẩm, đưa ra quyết định đánh đổi khó.

Agentic AI (AI có khả năng agentic — tự lên kế hoạch và thực thi chuỗi nhiều bước để đạt một mục tiêu, thay vì chỉ trả lời một câu hỏi đơn lẻ) thay đổi phương trình này một cách căn bản. Khác với chatbot thế hệ trước chỉ trả lời khi được hỏi, một AI agent có thể được giao một mục tiêu mở ("tổng hợp feedback khách hàng tuần này thành báo cáo theme") và tự chia nhỏ thành các bước: đọc dữ liệu thô, phân loại, tổng hợp, format kết quả — tất cả không cần con người can thiệp ở từng bước nhỏ. Khi phần lớn công việc thực thi này được agent đảm nhận, giá trị của PM buộc phải dịch chuyển lên một tầng cao hơn.

Hai Chân Dung PM: Task Executor Và Strategic Orchestrator

Để hình dung rõ sự dịch chuyển, hãy so sánh hai chân dung PM trong cùng một ngày làm việc.

PM dạng "Task Executor" (người thực thi tác vụ) — mô hình phổ biến trước agentic AI: buổi sáng dành để tự tay viết story từ note họp, buổi trưa vật lộn với SQL hoặc chờ data analyst trả kết quả, buổi chiều format lại slide báo cáo cho đúng template công ty, cuối ngày nhắn Slack xin feedback từ 5 stakeholder rồi chờ phản hồi. PM này bận suốt ngày, nhưng phần lớn năng lượng đổ vào việc "làm ra sản phẩm phụ" (story, slide, báo cáo) chứ không phải việc "quyết định điều gì đáng làm".

PM dạng "Strategic Orchestrator" (người điều phối chiến lược) — mô hình đang hình thành với agentic AI: buổi sáng giao cho một agent việc draft 8 story từ note họp kèm bối cảnh rõ ràng (persona, business goal, format chuẩn của team), trong lúc agent chạy thì PM dành thời gian đọc lại 3 câu hỏi nghiên cứu thị trường còn treo. Đến trưa, PM review story do AI draft — sửa 30%, giữ nguyên 70%, bổ sung một acceptance criteria mà AI bỏ sót vì không biết một quy định nghiệp vụ nội bộ. Buổi chiều, một agent khác đã tự kéo và tổng hợp dữ liệu funnel, PM chỉ cần diễn giải con số dưới góc nhìn chiến lược để trình bày cho leadership. Cuối ngày, PM dành thời gian còn lại cho việc mà AI không thể làm thay: gọi điện trực tiếp với một stakeholder đang bất đồng về độ ưu tiên của một tính năng.

Điểm mấu chốt: PM dạng thứ hai không làm ít việc hơn — họ làm ít việc thực thi tay chân hơn, và nhiều việc phán đoán, điều phối, ra quyết định hơn. Đây chính là bản chất của "strategic orchestrator": không tự chạy từng bước, mà thiết lập mục tiêu đúng, cung cấp context đúng, review kết quả với con mắt phản biện, và đưa ra quyết định mà chỉ con người mới đủ thẩm quyền và ngữ cảnh để quyết — như đánh đổi ưu tiên (prioritization trade-off), xử lý chính trị nội bộ giữa các phòng ban (stakeholder politics), hay diễn giải một bối cảnh nghiệp vụ mơ hồ mà không tài liệu nào ghi lại.

Vai Trò Mới Không Loại Bỏ PM — Nó Nâng Tầm PM

Một hiểu lầm phổ biến là "AI sẽ làm luôn việc của PM". Thực tế ngược lại: những gì AI agent làm tốt nhất — thực thi chuỗi bước có khuôn mẫu rõ ràng dựa trên dữ liệu và context sẵn có — chưa bao giờ là phần khó nhất của nghề PM. Phần khó nhất luôn là: xác định đúng vấn đề cần giải, cân bằng lợi ích giữa các bên liên quan, và ra quyết định trong điều kiện thông tin không đầy đủ. Không mô hình AI nào hiện tại (kể cả các LLM tiên tiến nhất) có đủ ngữ cảnh chính trị nội bộ, quan hệ cá nhân, hay trực giác thị trường để tự làm thay phần này.

Điều đang thay đổi là: PM giờ có một "đội quân" agent để giải phóng thời gian cho phần khó đó. Vai trò PM dịch chuyển từ "người làm mọi việc từ A đến Z" sang "người thiết kế quy trình, điều phối nhiều agent chạy song song, và là người ký duyệt cuối cùng chịu trách nhiệm với kết quả".

Các Bước Thực Hành

  1. Ghi log một tuần làm việc thực tế của bạn. Chia nhỏ theo giờ: việc nào là thực thi tay chân (viết, format, tổng hợp), việc nào là tư duy/quyết định (ưu tiên, đàm phán, phân tích chiến lược). Hầu hết PM lần đầu làm bài tập này sẽ ngạc nhiên vì tỷ lệ thực thi tay chân cao hơn họ tưởng.
  2. Chọn ra 2-3 việc thực thi tay chân lặp lại nhiều nhất trong tuần (ví dụ: viết story, tổng hợp meeting note, kéo báo cáo số liệu).
  3. Thử giao một agent (ví dụ Claude Projects, ChatGPT với custom instructions, hoặc tính năng AI trong Notion/Jira) làm thử một trong các việc đó, với đầy đủ context cần thiết (xem phần Prompt Examples bên dưới).
  4. So sánh kết quả AI làm với kết quả bạn tự làm trước đây — không phải để đánh giá "AI đã giỏi bằng bạn chưa", mà để hiểu AI mạnh ở phần nào (tốc độ, format nhất quán) và yếu ở phần nào (thiếu context ngầm, thiếu phán đoán chính trị nội bộ).
  5. Xác định lại lịch làm việc tuần tới, dành thời gian tiết kiệm được cho một việc chiến lược bạn đã trì hoãn quá lâu (ví dụ: phỏng vấn khách hàng, phân tích đối thủ cạnh tranh sâu hơn, viết roadmap quý tới).

Ví Dụ Prompt

Bạn là một Senior Product Manager với 10 năm kinh nghiệm làm agile
trong lĩnh vực fintech.

Tôi sẽ cung cấp cho bạn ghi chú từ buổi họp discovery với khách hàng
(customer discovery call) tuần này. Nhiệm vụ của bạn là chuyển ghi chú
thô này thành user story dạng chuẩn.

[PASTE GHI CHÚ HỌP VÀO ĐÂY]

Bối cảnh bổ sung:
- Sản phẩm: app quản lý chi tiêu cá nhân cho người dùng Việt Nam,
  đối tượng chính là nhân viên văn phòng 25-35 tuổi.
- Format story chuẩn của team: "Là [persona], tôi muốn [hành động],
  để [giá trị đạt được]".
- Mỗi story cần đi kèm 3-5 acceptance criteria dạng Given-When-Then.

Hãy thực hiện theo các bước:
1. Đọc kỹ ghi chú, xác định tối đa 5 nhu cầu người dùng riêng biệt
   được đề cập.
2. Với mỗi nhu cầu, viết một user story đúng format trên.
3. Viết acceptance criteria dạng Given-When-Then cho từng story.
4. Đánh dấu rõ những chỗ ghi chú họp còn mơ hồ, cần PM xác nhận lại
   với khách hàng hoặc stakeholder trước khi đưa vào backlog (không
   tự suy diễn hoặc bịa thêm chi tiết không có trong ghi chú).
5. Xuất kết quả dưới dạng bảng Markdown: Story | Acceptance Criteria |
   Ghi chú cần xác nhận thêm.

Trả lời bằng tiếng Việt, giữ nguyên các thuật ngữ kỹ thuật tiếng Anh
(user story, acceptance criteria, persona, v.v.).

Mẹo: Đừng đánh giá một AI agent bằng câu hỏi "nó có làm đúng 100% không", mà bằng câu hỏi "tỷ lệ tôi phải sửa là bao nhiêu, và việc sửa đó có nhanh hơn tự viết từ đầu không". Một agent draft 8 story mà bạn phải sửa 20% vẫn nhanh hơn rất nhiều so với tự viết cả 8 story từ số không — đừng để kỳ vọng "hoàn hảo ngay lần đầu" khiến bạn bỏ lỡ lợi ích thực tế.

Công Việc PM Lặp Đi Lặp Lại Nào Phù Hợp Nhất Để Giao Cho AI Agent?

Không phải mọi việc PM làm đều nên giao cho AI. Nguyên tắc chọn lọc đơn giản: những việc có đầu vào rõ ràng, đầu ra có khuôn mẫu (pattern) lặp lại, và không đòi hỏi phán đoán chính trị hay quyết định "không thể đảo ngược" — đó là ứng viên tốt để agent augmentation (tăng cường năng lực bằng AI agent). Dưới đây là danh mục các việc phổ biến nhất, cùng pattern augmentation và rào chắn (guardrail) cần thiết cho từng loại.

Viết Và Tinh Chỉnh User Story, Acceptance Criteria

Đây là ứng viên kinh điển nhất. PM/BA thường nhận ghi chú họp rời rạc, yêu cầu miệng từ stakeholder, hoặc ý tưởng phác thảo trên Miro, rồi phải chuyển hóa thành story chuẩn có thể đưa vào backlog. AI agent làm rất tốt việc chuyển đổi format này khi được cho đúng template và persona.

Pattern augmentation: AI draft toàn bộ story + acceptance criteria từ input thô → PM/BA review, sửa ngôn ngữ nghiệp vụ, bổ sung context AI không biết, quyết định story nào đưa vào backlog.

Guardrail: AI có xu hướng "làm đẹp" story ngay cả khi input gốc mơ hồ — nó sẽ tự suy diễn chi tiết để câu văn nghe trọn vẹn. Luôn yêu cầu AI đánh dấu rõ phần nào là suy diễn, phần nào có căn cứ trực tiếp từ input, tránh để story "nghe hay" nhưng sai bản chất yêu cầu.

Tổng Hợp Feedback Khách Hàng, Ticket Hỗ Trợ, Bình Luận NPS

Với sản phẩm có hàng trăm, hàng nghìn phản hồi mỗi tháng, việc đọc thủ công để tìm ra theme (chủ đề chung) gần như bất khả thi ở quy mô lớn — nhưng đây chính là việc LLM làm cực tốt: đọc lượng lớn văn bản, phân cụm theo chủ đề, đếm tần suất.

Pattern augmentation: AI đọc toàn bộ feedback thô → phân loại theo theme, gắn mức độ ưu tiên gợi ý (dựa trên tần suất và mức độ bức xúc thể hiện trong ngôn ngữ) → PM xác nhận theme có hợp lý không, đối chiếu với dữ liệu định lượng khác (ví dụ churn rate), rồi quyết định action.

Guardrail: Dữ liệu khách hàng thường chứa thông tin cá nhân (personal data) — email, số điện thoại, đôi khi cả thông tin tài chính trong ticket hỗ trợ. Luôn ẩn danh (anonymize) hoặc loại bỏ PII (Personally Identifiable Information — thông tin định danh cá nhân) trước khi đưa vào công cụ AI không được công ty phê duyệt cho dữ liệu nhạy cảm. Ngoài ra, AI có thể phóng đại một theme nếu vài khách hàng dùng ngôn từ mạnh — luôn đối chiếu số lượng thực tế trước khi kết luận "đây là vấn đề lớn".

Soạn Release Note Và Changelog

Việc viết release note từ danh sách ticket đã đóng hoặc commit log là việc lặp lại theo chu kỳ release, có khuôn mẫu rõ ràng (nhóm theo tính năng mới/cải tiến/sửa lỗi), rất phù hợp để tự động hóa phần lớn.

Pattern augmentation: AI đọc Jira ticket đã đóng hoặc commit message → nhóm theo loại thay đổi, viết bằng ngôn ngữ hướng người dùng (thay vì ngôn ngữ kỹ thuật nội bộ) → PM review lại giọng văn, đảm bảo không để lộ thông tin nhạy cảm về roadmap cạnh tranh, rồi mới publish.

Guardrail: Không bao giờ để AI tự động gửi/publish release note ra ngoài mà không qua review của con người — rủi ro lớn nhất là AI vô tình tiết lộ chi tiết kỹ thuật nội bộ, cách diễn đạt sai giọng thương hiệu, hoặc nhắc đến một tính năng chưa chính thức công bố.

Tóm Tắt Cuộc Họp Và Action Item

Sau mỗi buổi họp stakeholder, sprint review, hay demo, luôn có việc tóm tắt lại nội dung và liệt kê action item kèm người phụ trách — việc tốn thời gian nhưng rất có khuôn mẫu.

Pattern augmentation: Ghi âm/transcript họp (qua công cụ như Otter.ai, hoặc transcript tự nhập) → AI tóm tắt quyết định chính, liệt kê action item kèm người phụ trách được nhắc tới → PM xác nhận lại, gửi cho team trong vòng vài phút sau họp thay vì cuối ngày.

Guardrail: AI có thể gán nhầm action item cho sai người nếu transcript không rõ giọng nói — luôn để PM xác nhận trước khi gửi, đặc biệt với action item liên quan cam kết deadline.

Nghiên Cứu Thị Trường Và Đối Thủ Cạnh Tranh (Bản Draft Đầu Tiên)

AI agent có thể tổng hợp thông tin công khai về đối thủ (tính năng, pricing, định vị thương hiệu) thành bản draft đầu tiên nhanh hơn nhiều so với PM tự tìm kiếm thủ công.

Pattern augmentation: AI tổng hợp thông tin công khai → PM xác thực (fact-check) từng điểm quan trọng, đặc biệt số liệu và pricing vì AI có thể dùng thông tin cũ hoặc bị lỗi thời → bổ sung phân tích chiến lược mà chỉ con người mới có (ví dụ: đối thủ này đang nhắm vào phân khúc nào mà công ty ta có lợi thế).

Guardrail: Đây là khu vực rủi ro hallucination (AI tự bịa thông tin nghe có vẻ hợp lý nhưng sai) cao nhất, vì thông tin đối thủ thay đổi liên tục và AI có thể trộn lẫn dữ liệu cũ với mới. Không bao giờ trích dẫn số liệu đối thủ từ AI vào tài liệu chính thức (như bản trình bày cho leadership) mà không tự tay kiểm chứng lại nguồn gốc.

Phân Tích Dữ Liệu Và Báo Cáo Chỉ Số

Với các công cụ AI hỗ trợ truy vấn ngôn ngữ tự nhiên (natural language query) trên dashboard như những tính năng đang có ở Amplitude, Mixpanel, hay việc dùng AI để viết SQL, PM giờ có thể tự kéo số liệu mà trước đây phải chờ data analyst.

Pattern augmentation: PM mô tả câu hỏi bằng ngôn ngữ tự nhiên ("tỷ lệ chuyển đổi từ đăng ký sang thanh toán tháng này so với tháng trước") → AI viết truy vấn hoặc gọi API dashboard → PM kiểm tra kết quả có hợp lý không (sanity check) trước khi đưa vào báo cáo.

Guardrail: Luôn đối chiếu con số AI trả về với ít nhất một nguồn khác (ví dụ dashboard đã có sẵn) trước lần đầu tin tưởng một truy vấn mới — SQL do AI viết có thể sai logic JOIN hoặc filter mà nhìn qua tưởng đúng, dẫn đến số liệu sai lệch nghiêm trọng khi trình bày cho leadership.

Soạn Thảo Từng Phần Của PRD

PRD (Product Requirement Document — tài liệu yêu cầu sản phẩm) thường có cấu trúc lặp lại giữa các dự án: bối cảnh vấn đề, đối tượng người dùng, yêu cầu chức năng, tiêu chí thành công. AI có thể draft các phần có khuôn mẫu này rất nhanh nếu được cho đủ context.

Pattern augmentation: PM cung cấp bối cảnh (business goal, dữ liệu nghiên cứu, ràng buộc kỹ thuật đã biết) → AI draft từng phần theo template PRD chuẩn của team → PM chỉnh sửa phần chiến lược (why now, trade-off), giữ nguyên phần mô tả chức năng nếu chính xác.

Guardrail: Phần "why" (tại sao làm, tại sao làm bây giờ) của PRD gần như luôn cần con người viết lại hoàn toàn — đây là phần thể hiện tư duy chiến lược, AI chỉ có thể diễn đạt lại ý bạn đưa vào, không thể tự nghĩ ra lý do chiến lược thay bạn.

Chuẩn Bị Backlog Grooming — Phát Hiện Trùng Lặp, Gợi Ý Ước Lượng

Trước buổi backlog grooming, AI có thể quét qua backlog để phát hiện story trùng lặp hoặc chồng chéo phạm vi, và gợi ý story point dựa trên độ phức tạp mô tả (so sánh với story tương tự đã làm trước đây).

Pattern augmentation: AI quét backlog → gắn cờ story nghi trùng lặp, gợi ý story point sơ bộ → team (không chỉ PM) thảo luận và chốt điểm thực tế trong buổi grooming, AI chỉ là điểm khởi đầu thảo luận, không phải kết luận cuối.

Guardrail: Không bao giờ để estimate (ước lượng) của AI thay thế hoàn toàn cho planning poker hay thảo luận nhóm — giá trị lớn nhất của việc estimate theo nhóm nằm ở việc lộ ra các giả định khác nhau giữa các thành viên, điều mà một con số AI đưa ra không thể tái tạo được.

Các Bước Thực Hành

  1. Liệt kê toàn bộ việc lặp lại trong tháng vừa qua của bạn — dùng lại log từ phần trước, nhưng lần này phân loại theo 8 nhóm vừa nêu ở trên.
  2. Chấm điểm mỗi nhóm việc theo 2 tiêu chí: (a) mức độ lặp lại có khuôn mẫu rõ ràng (1-5), (b) mức độ rủi ro nếu AI làm sai (1-5, càng cao càng rủi ro). Ưu tiên thử nghiệm agent cho nhóm điểm (a) cao và (b) thấp trước.
  3. Chọn 1 công cụ phù hợp cho từng nhóm việc — ví dụ Claude/ChatGPT cho story và PRD, tính năng AI tích hợp sẵn trong Productboard/Notion cho tổng hợp feedback, tính năng natural language query trong Amplitude/Mixpanel cho phân tích số liệu.
  4. Thiết lập một quy trình review bắt buộc cho mỗi loại output AI — ví dụ: "mọi release note do AI soạn phải được 1 người khác ngoài PM đọc lại trước khi publish", để guardrail không chỉ nằm trong đầu bạn mà thành quy trình team.
  5. Đo lường thời gian tiết kiệm được sau 2-4 tuần — ghi lại cụ thể (ví dụ: "tổng hợp feedback NPS từ 3 giờ xuống 30 phút") để có dữ liệu thuyết phục khi đề xuất mở rộng việc dùng AI agent cho cả team.

Ví Dụ Prompt

Bạn là một Product Analyst có kinh nghiệm phân tích customer feedback
cho sản phẩm SaaS B2C.

Dưới đây là 150 phản hồi thô từ khảo sát NPS quý này (đã được ẩn danh,
không còn thông tin định danh cá nhân).

[PASTE DỮ LIỆU FEEDBACK ĐÃ ẨN DANH VÀO ĐÂY]

Hãy phân tích theo các bước:
1. Phân loại toàn bộ phản hồi thành tối đa 6 theme (chủ đề) chính,
   đặt tên theme ngắn gọn, cụ thể (không dùng tên chung chung như
   "trải nghiệm người dùng").
2. Với mỗi theme, đếm số lượng phản hồi thuộc theme đó và trích 2-3
   câu trích dẫn tiêu biểu (giữ nguyên văn, không diễn giải lại).
3. Ước lượng mức độ cảm xúc trung bình của mỗi theme (Tích cực/Trung
   tính/Tiêu cực) dựa trên ngôn từ sử dụng.
4. Đề xuất theme nào cần ưu tiên xem xét trước, dựa trên kết hợp giữa
   số lượng phản hồi và mức độ tiêu cực.
5. Liệt kê rõ nếu có theme nào chỉ dựa trên rất ít phản hồi (dưới 5)
   để tránh kết luận vội vàng dựa trên mẫu quá nhỏ.

Xuất kết quả dưới dạng bảng Markdown: Theme | Số Lượng | Cảm Xúc |
Trích Dẫn Tiêu Biểu | Mức Độ Ưu Tiên Đề Xuất.

Trả lời bằng tiếng Việt, giữ nguyên thuật ngữ kỹ thuật tiếng Anh (NPS,
theme, churn, v.v.).

Mẹo: Khi thử nghiệm giao việc mới cho AI agent, đừng thử với việc quan trọng nhất trước — chọn một việc có rủi ro thấp nếu sai (ví dụ tóm tắt họp nội bộ) để xây dựng niềm tin và hiểu giới hạn công cụ, rồi mới mở rộng sang việc có tính rủi ro cao hơn như phân tích đối thủ hay soạn PRD.

Mô Hình Năng Lực PM Mới — Context Engineering, Prompt Literacy Và AI Judgment

Khi phần lớn công việc thực thi được san sẻ cho AI agent, bộ kỹ năng làm nên một PM giỏi cũng phải mở rộng. Ba năng lực mới nổi lên như "must-have" (bắt buộc phải có) chứ không còn là "nice-to-have": Context Engineering (kỹ thuật cấu trúc ngữ cảnh), Prompt Literacy (khả năng đọc-viết prompt thành thạo), và AI Judgment (khả năng phán đoán khi nào tin, khi nào nghi ngờ AI). Quan trọng là: ba năng lực này không thay thế các kỹ năng PM truyền thống — chúng bổ sung và khuếch đại giá trị của các kỹ năng đó.

Context Engineering — Biết Cách Cấp Đúng Ngữ Cảnh

Context engineering là kỹ năng cấu trúc và cung cấp đúng loại thông tin nền để AI hiểu đúng bài toán, thay vì chỉ ném một câu hỏi ngắn và hy vọng AI "tự đoán" ra ý bạn. Đây có lẽ là kỹ năng bị đánh giá thấp nhất nhưng lại tạo ra khác biệt lớn nhất giữa một PM dùng AI hiệu quả và một PM thất vọng vì "AI trả lời chung chung".

Một context đầy đủ cho một tác vụ PM thường cần bao gồm: mục tiêu kinh doanh (business goal) đứng sau yêu cầu, ràng buộc (constraint) về kỹ thuật hoặc nguồn lực, chân dung người dùng (persona) liên quan, các quyết định trước đó đã được chốt (để AI không đề xuất lại điều đã bị bác bỏ), và ví dụ mẫu về format/giọng văn team đang dùng. Thiếu bất kỳ mảnh nào trong số này, AI vẫn trả lời — nhưng câu trả lời sẽ mang tính chung chung, "đúng về mặt lý thuyết" nhưng không dùng được ngay cho bối cảnh cụ thể của bạn.

Ví dụ cụ thể: nếu bạn hỏi AI "viết acceptance criteria cho tính năng nhắc nợ", bạn sẽ nhận một câu trả lời generic áp dụng cho bất kỳ app fintech nào trên thế giới. Nhưng nếu bạn cung cấp thêm: "sản phẩm nhắm vào người dùng Việt Nam, quy định về nhắc nợ phải tuân thủ hướng dẫn của Ngân hàng Nhà nước về tần suất liên hệ khách hàng, và team đã quyết định không dùng SMS mà chỉ dùng in-app notification vì lý do chi phí" — AI sẽ trả về kết quả sát với thực tế công việc của bạn hơn rất nhiều.

Một cách thực hành context engineering hiệu quả là xây dựng một "context pack" (gói ngữ cảnh) tái sử dụng được cho sản phẩm của bạn — một tài liệu ngắn chứa business goal hiện tại, persona chính, các quyết định nền tảng, giọng văn thương hiệu — rồi paste vào đầu mỗi phiên làm việc với AI, hoặc lưu vào tính năng "Project"/"Custom Instructions" của công cụ bạn dùng (Claude Projects, ChatGPT custom GPT) để không phải gõ lại từ đầu mỗi lần.

Prompt Literacy — Viết Prompt Như Một Kỹ Năng Nghề Nghiệp

Prompt literacy là khả năng viết yêu cầu (prompt) cho AI một cách rõ ràng, có cấu trúc, và biết cách chia nhỏ một tác vụ phức tạp thành các bước AI có thể xử lý tốt. Đây không phải kỹ năng "kỹ thuật" theo nghĩa lập trình — nó gần với kỹ năng viết yêu cầu công việc rõ ràng cho một đồng nghiệp mới, một kỹ năng PM vốn đã cần có từ trước.

Ba nguyên tắc cốt lõi của prompt literacy mà PM nên luyện tập:

  • Chia nhỏ tác vụ phức tạp thành các bước tuần tự thay vì hỏi một câu hỏi mở rộng ("phân tích sản phẩm này giúp tôi"). Một prompt tốt luôn có cấu trúc: vai trò AI cần đóng, input cụ thể, các bước cần thực hiện theo thứ tự, và format output mong muốn — giống hệt cấu trúc các ví dụ prompt xuyên suốt bài học này.
  • Biết lặp lại và tinh chỉnh (iterate) thay vì kỳ vọng đúng ngay lần đầu. Prompt hiếm khi hoàn hảo ở lần thử đầu tiên — kỹ năng thực sự nằm ở việc đọc output đầu tiên, nhận ra chỗ chưa đúng ý, rồi điều chỉnh prompt (thêm ràng buộc, làm rõ định nghĩa, cho ví dụ mẫu) cho lần chạy tiếp theo.
  • Xây dựng một "prompt library" (thư viện prompt) cá nhân hoặc của team cho các tác vụ lặp lại — một khi đã tìm ra cấu trúc prompt hiệu quả cho việc viết story, đừng viết lại từ đầu mỗi lần, hãy lưu lại làm template và chia sẻ cho cả team để nâng chất lượng đồng đều.

AI Judgment — Biết Khi Nào Tin, Khi Nào Nghi Ngờ

AI Judgment là năng lực khó xây dựng nhất trong ba năng lực, vì nó không có công thức cố định — nó là trực giác được rèn qua kinh nghiệm thực tế làm việc với AI, biết nhận diện khi nào một câu trả lời "nghe có vẻ đúng" nhưng thực chất là hallucination (AI tự bịa ra thông tin không có căn cứ, trình bày với sự tự tin y hệt thông tin đúng).

Một số dấu hiệu PM nên rèn phản xạ cảnh giác: AI đưa ra số liệu cụ thể (ví dụ market size, thống kê đối thủ) mà không dẫn nguồn rõ ràng; AI trả lời quá mượt mà, không có bất kỳ điểm "tôi không chắc" nào cho một câu hỏi vốn dĩ mơ hồ; AI tự bổ sung chi tiết nghiệp vụ nghe hợp lý nhưng bạn chưa từng cung cấp trong context; hoặc AI đưa ra kết luận nhất quán khác nhau khi bạn hỏi lại cùng một câu theo cách diễn đạt khác — dấu hiệu cho thấy nó không thực sự "biết", mà đang đoán theo pattern ngôn ngữ.

AI Judgment cũng bao gồm việc hiểu rõ giới hạn cấu trúc của mô hình: AI không có quyền truy cập dữ liệu nội bộ công ty bạn trừ khi bạn cung cấp, không biết các quyết định chính trị nội bộ chưa được viết thành văn bản, và có thể mang thiên kiến (bias) từ dữ liệu huấn luyện khiến nó ưu ái cách làm phổ biến ở thị trường nó học nhiều nhất (thường là thị trường Mỹ/phương Tây), chưa chắc phù hợp bối cảnh Việt Nam.

Nguyên tắc thực hành cho AI Judgment: luôn review output AI như bạn review công việc của một thực tập sinh giỏi nhưng chưa có domain knowledge (kiến thức nghiệp vụ) — tin tưởng ở phần cấu trúc, ngôn ngữ, tốc độ, nhưng luôn verify (xác minh) phần dữ kiện, số liệu, và bất kỳ kết luận nào sẽ được dùng để ra quyết định quan trọng.

Ba Năng Lực Này Bổ Sung Chứ Không Thay Thế Kỹ Năng PM Truyền Thống

Điều quan trọng cần nhấn mạnh: context engineering, prompt literacy, và AI judgment không phải kỹ năng độc lập tách rời khỏi nghề PM truyền thống — chúng là lớp kỹ năng mới xây trên nền các kỹ năng cũ, và thực ra làm các kỹ năng cũ trở nên quan trọng hơn, không phải kém quan trọng hơn.

Một PM giỏi context engineering vẫn cần nắm vững framework ưu tiên hóa (như RICE, MoSCoW) để biết business goal nào là quan trọng nhất, cần đưa vào context. Một PM giỏi prompt literacy vẫn cần kỹ năng viết rõ ràng, mạch lạc vốn đã là nền tảng của nghề — chỉ là giờ áp dụng kỹ năng đó cho một đối tượng giao tiếp mới (AI) thay vì chỉ con người. Một PM giỏi AI judgment vẫn cần data literacy (khả năng đọc hiểu và phân tích dữ liệu) truyền thống để biết một con số AI đưa ra có hợp lý hay không, và vẫn cần kỹ năng quản lý stakeholder để biết khi nào một quyết định cần con người xử lý thay vì giao cho AI.

Cách Bắt Đầu Xây Dựng Ba Năng Lực Này

Xây dựng năng lực mới này không cần một khóa học dài hạn — nó cần thực hành có chủ đích (deliberate practice) trong công việc hàng ngày. Ba cách bắt đầu thực tế:

  • Duy trì một "practice log" (nhật ký thực hành): mỗi lần dùng AI cho một tác vụ PM, ghi lại prompt đã dùng, kết quả nhận được, và điều bạn học được (context nào còn thiếu, câu hỏi nào cần rõ hơn). Sau 4-6 tuần, đọc lại log này sẽ cho bạn thấy rõ pattern lỗi lặp lại của chính mình khi viết prompt.
  • Xây dựng prompt library chia sẻ trong team, lưu trên Notion/Confluence, phân loại theo tác vụ (viết story, tổng hợp feedback, phân tích số liệu). Mỗi prompt hiệu quả nên có ghi chú ngắn về ngữ cảnh phù hợp để dùng nó.
  • Thiết lập peer review cho công việc có AI hỗ trợ — tương tự code review trong kỹ thuật, một PM khác trong team đọc lại output quan trọng do AI hỗ trợ tạo ra (như PRD, phân tích đối thủ) trước khi công bố rộng, giúp bắt lỗi hallucination hoặc thiếu context mà người viết prompt ban đầu có thể bỏ sót do quá quen thuộc với vấn đề.

Các Bước Thực Hành

  1. Viết một "context pack" cho sản phẩm bạn đang phụ trách — tối đa 1 trang, gồm: business goal quý này, 2-3 persona chính, 5 quyết định nền tảng quan trọng nhất đã chốt, và giọng văn/format chuẩn của team.
  2. Lưu context pack này vào công cụ AI bạn dùng thường xuyên nhất (Claude Projects, custom GPT, hoặc đơn giản là một file paste đầu mỗi phiên chat).
  3. Chọn 1 prompt bạn đã dùng gần đây và thử tách nó thành các bước tuần tự rõ ràng hơn (như cấu trúc trong các ví dụ prompt của bài học này), so sánh chất lượng output trước và sau.
  4. Thực hành nhận diện hallucination: lần tới khi AI đưa ra một số liệu hoặc dữ kiện cụ thể, tự hỏi "tôi có thể xác minh điều này từ đâu" trước khi dùng nó trong bất kỳ tài liệu chính thức nào.
  5. Rủ một đồng nghiệp PM khác cùng review chéo một tài liệu quan trọng có AI hỗ trợ trong tháng này, và ghi lại những gì họ phát hiện ra mà bạn bỏ sót.

Ví Dụ Prompt

Bạn là một AI assistant hỗ trợ Product Manager. Tôi sẽ cung cấp cho
bạn một "context pack" cố định cho sản phẩm của tôi. Hãy ghi nhớ và
áp dụng context này cho MỌI yêu cầu tôi đưa ra trong phiên làm việc
này, trừ khi tôi nói rõ là bỏ qua.

CONTEXT PACK:
- Sản phẩm: [MÔ TẢ SẢN PHẨM NGẮN GỌN]
- Business goal quý này: [MỤC TIÊU KINH DOANH CỤ THỂ, CÓ SỐ]
- Persona chính: [MÔ TẢ 2-3 PERSONA]
- Quyết định nền tảng đã chốt (không đề xuất lại): [LIỆT KÊ 3-5 QUYẾT
  ĐỊNH, ví dụ: "không hỗ trợ đăng nhập qua mạng xã hội vì lý do bảo
  mật", "chỉ hỗ trợ tiếng Việt trong năm nay"]
- Giọng văn/format chuẩn: [MÔ TẢ NGẮN, ví dụ: "thân thiện nhưng
  chuyên nghiệp, tránh thuật ngữ kỹ thuật khi giao tiếp với khách
  hàng cuối"]

Xác nhận lại bạn đã hiểu context pack bằng cách tóm tắt lại trong 3-4
câu, sau đó chờ tôi đưa yêu cầu tiếp theo.

Trả lời bằng tiếng Việt, giữ nguyên thuật ngữ kỹ thuật tiếng Anh.

Mẹo: Đừng cố học cả ba năng lực cùng lúc một cách hàn lâm. Chọn một tác vụ PM cụ thể bạn làm mỗi tuần (ví dụ viết story), rèn cả ba năng lực xuyên suốt chính tác vụ đó trong một tháng — context pack cho tác vụ đó, prompt template cho tác vụ đó, và thói quen verify cho tác vụ đó — trước khi mở rộng sang tác vụ khác. Học qua một tác vụ cụ thể luôn hiệu quả hơn học lý thuyết chung chung.

Những Điểm Chính Cần Nhớ

  • Agentic AI dịch chuyển vai trò PM từ "task executor" (người thực thi tác vụ tay chân) sang "strategic orchestrator" (người điều phối chiến lược) — không phải bằng cách loại bỏ PM, mà bằng cách giải phóng thời gian cho phần khó nhất của nghề: phán đoán, ưu tiên hóa, xử lý quan hệ stakeholder.
  • Giá trị cốt lõi của PM — hiểu vấn đề khách hàng, đánh đổi ưu tiên, xử lý chính trị nội bộ, quyết định trong điều kiện thiếu thông tin — vẫn hoàn toàn thuộc về con người, vì AI hiện tại không có đủ ngữ cảnh chính trị và trực giác thị trường để tự làm thay.
  • Các việc PM nên ưu tiên giao cho AI agent gồm: viết/tinh chỉnh user story, tổng hợp feedback khách hàng, soạn release note, tóm tắt họp, nghiên cứu thị trường bản draft đầu, phân tích số liệu, soạn PRD từng phần, và chuẩn bị backlog grooming — tất cả đều theo pattern "AI draft, con người review/quyết định".
  • Mỗi loại việc giao cho AI cần guardrail riêng: ẩn danh dữ liệu khách hàng trước khi đưa vào AI, không tự động gửi output ra ngoài mà không qua review, luôn xác minh số liệu và thông tin đối thủ trước khi trích dẫn chính thức.
  • Context Engineering — cung cấp đúng business goal, persona, ràng buộc, quyết định nền tảng, và ví dụ mẫu — là yếu tố quyết định chất lượng output AI nhiều hơn bất kỳ kỹ thuật prompt nào khác; xây một "context pack" tái sử dụng được cho sản phẩm của bạn.
  • Prompt Literacy nghĩa là biết cấu trúc yêu cầu rõ ràng (vai trò, input, các bước, format output), biết lặp và tinh chỉnh thay vì kỳ vọng đúng ngay lần đầu, và xây dựng thư viện prompt tái sử dụng cho team.
  • AI Judgment là khả năng nhận diện hallucination và biết giới hạn của AI — luôn verify số liệu cụ thể, cảnh giác với câu trả lời quá mượt mà cho câu hỏi vốn mơ hồ, và đối xử với output AI như công việc của một thực tập sinh giỏi cần được review kỹ.
  • Ba năng lực mới (context engineering, prompt literacy, AI judgment) không thay thế các kỹ năng PM truyền thống (prioritization framework, data literacy, quản lý stakeholder) — chúng xây trên nền các kỹ năng đó và làm chúng quan trọng hơn, không phải kém quan trọng hơn.
  • Bắt đầu xây năng lực mới bằng thực hành có chủ đích: duy trì practice log ghi lại prompt và bài học, xây prompt library chia sẻ trong team, và thiết lập peer review cho output AI quan trọng — thay vì học lý thuyết suông.
Tiếp Tiếng Việt: AI Toolkit