AI có thay được Product Owner không? Việc nào vẫn cần PO

Một câu hỏi khó trả lời trong tuần đầu

Đây là tình huống minh họa. Bạn vừa nhận vai Product Owner (PO) cho Bếp Nhà, một ứng dụng đặt nguyên liệu nấu ăn (tên hư cấu). Trong một buổi trao đổi, anh quản lý vừa đọc xong một bài báo về AI. Anh hỏi nửa đùa nửa thật: “Giờ công cụ AI viết được user story, tóm tắt được phản hồi khách, còn lên được cả roadmap. Vậy team mình có cần PO nữa không?”

Bạn không biết trả lời sao. Tối đó bạn mở mạng xã hội, một nửa bài viết nói AI sẽ thay hết vai trò quản lý sản phẩm, nửa còn lại nói AI chỉ là trò chơi, đừng tin. Bạn vừa lo cho công việc mới, vừa thấy mình nên dùng AI mà không rõ dùng tới đâu.

Bài này không dự đoán bao nhiêu việc làm sẽ mất hay còn. Bài này đưa ra một cách tự trả lời câu hỏi đó cho chính công việc của bạn: tách những việc mang tính soạn khỏi những việc mang tính quyết, rồi xem phần nào AI chạm tới được, phần nào vẫn cần một con người chịu trách nhiệm.

Vì sao câu hỏi “AI có thay được PO không” khó trả lời?

Khó thứ nhất: thứ AI làm ra trông rất giống thứ PO làm ra. Một user story, một bản tóm tắt phản hồi, một danh sách ưu tiên. Nếu nhìn vai trò PO qua các tài liệu, bạn sẽ dễ kết luận AI đã làm được gần hết. Nhưng tài liệu chỉ là phần ghi lại. Phần quan trọng là ai đã chọn viết điều đó, dựa trên bằng chứng nào, và ai chịu trách nhiệm khi nó sai.

Khó thứ hai: Scrum Guide 2020 không định nghĩa PO bằng danh sách tài liệu. Hướng dẫn này nói PO chịu trách nhiệm (accountable) tối đa hóa giá trị của sản phẩm do Scrum Team làm ra, và nhấn mạnh PO là một người, không phải một ủy ban. PO cũng chịu trách nhiệm quản lý Product Backlog: phát triển và truyền đạt Product Goal, tạo và truyền đạt các hạng mục backlog, sắp thứ tự và giữ backlog minh bạch. Trang giới thiệu vai trò PO của Scrum.org cũng mô tả PO là người cân bằng nhu cầu của nhiều stakeholder và chốt quyết định về backlog sau khi nghe ý kiến các bên.

Scrum Guide còn nói PO có thể tự làm các việc trên hoặc giao cho người khác, nhưng dù thế nào PO vẫn chịu trách nhiệm. Theo cách nhìn của bài này, giao phần soạn cho công cụ AI cũng giống vậy: việc có thể chuyển đi, trách nhiệm thì không. Một công cụ không đứng ra trước stakeholder để giải thích vì sao tính năng này được làm trước tính năng kia.

Khó thứ ba: nỗi lo kéo người ta về hai phía. NIST, Viện Tiêu chuẩn và Công nghệ Quốc gia Hoa Kỳ, trong hồ sơ rủi ro AI tạo sinh, mô tả cả hai chiều. Một chiều là con người né AI không cần thiết và tự bỏ lỡ lợi ích của nó. Chiều kia là “automation bias”, tức tin máy quá mức, cho rằng nội dung AI tạo ra tốt hơn thực tế. NIST cũng xếp “confabulation”, tức AI tự tin đưa ra nội dung sai, vào nhóm rủi ro chính. Người mới dễ rơi vào một trong hai phía, vì chưa có trải nghiệm để biết ranh giới nằm ở đâu.

Cách tự trả lời: tách việc soạn khỏi việc quyết

Thay vì hỏi chung chung “AI có thay được PO không”, hãy hỏi cụ thể hơn: trong tuần này, việc nào của mình là soạn, việc nào là quyết? Việc soạn là biến thông tin đã có thành chữ, bảng, danh sách. Việc quyết là chọn điều gì đúng, điều gì làm trước, điều gì nói với ai, và chịu trách nhiệm cho lựa chọn đó.

Nhiều việc của PO có cả hai phần. Viết user story có phần soạn (câu chữ, cấu trúc) và phần quyết (người dùng nào, quy tắc nghiệp vụ nào, phạm vi tới đâu). Cách tách này giúp bạn dùng AI đúng chỗ mà không để nó lấn sang chỗ cần bạn.

Với phần soạn, nguyên tắc kiểm tra bản nháp AI đã có trong bài riêng về dùng AI trong công việc PO. Với dữ liệu, hãy đọc bài về những loại dữ liệu không nên đưa vào công cụ AI trước khi dán bất cứ thứ gì từ công việc.

• Dùng AI trong công việc PO: AI nháp, PO kiểm, PO quyết
• Dữ liệu nào không nên đưa vào công cụ AI

Việc nào của PO AI làm được, việc nào vẫn cần PO?

Bảng dưới đi qua các hoạt động gắn với vai trò PO trong Scrum Guide và trong công việc hằng ngày. Đây là cách nhìn của bài viết, không phải danh sách chính thức từ Scrum Guide.

Developers ở đây là cách Scrum Guide gọi những người trong Scrum Team trực tiếp làm ra sản phẩm, không chỉ người viết code. Điểm chung của cột “Vẫn thuộc về PO” là có người khác dựa vào câu trả lời của bạn để hành động. Khi Developers hỏi “làm phần này trước hay phần kia”, họ cần một người trả lời và đứng sau câu trả lời đó.

Scrum Guide viết rằng để PO thành công, cả tổ chức phải tôn trọng quyết định của PO. Sự tôn trọng đó gắn với một người có tên, có lịch sử giữ lời và có bối cảnh. Một công cụ có thể đưa ra phương án nghe hợp lý, nhưng không có lịch sử giữ lời với ai cả.

Vai trò PO có thể thay đổi thế nào khi có AI?

Phần này là nhận định của bài viết, không phải dự báo có số liệu. Khi phần soạn nhanh hơn, thời gian của PO có thể dịch sang ba việc: đặt vấn đề rõ trước khi soạn, kiểm tra kỹ hơn sau khi soạn, và quyết định nhiều hơn với lý do rõ hơn. Nói cách khác, giá trị của PO nằm ít hơn ở việc viết ra tài liệu, và nhiều hơn ở việc biết tài liệu đó có đúng không, có nên làm không.

Bốn kỹ năng này không mới. Chúng đã là phần khó của vai trò PO từ trước khi có công cụ AI. Điều thay đổi là khi phần soạn rẻ đi, những kỹ năng này lộ rõ hơn: hai PO cùng dùng một công cụ, nhưng người biết đặt vấn đề và biết kiểm sẽ ra kết quả khác hẳn người chỉ chép lại bản nháp.

• Nói không với stakeholder mà không mất lòng
• Product Owner thực sự làm gì mỗi ngày

Ví dụ: một tuần làm việc, AI chạm vào đâu?

Quay lại PO của Bếp Nhà. Bảng dưới là một tuần làm việc minh họa, từ ngày đầu tới ngày cuối tuần làm việc. Công ty của PO này đã có quy định cho phép dùng một công cụ AI cho tài liệu không chứa dữ liệu cá nhân. Mỗi dòng ghi phần AI đã giúp và phần AI không làm được.

Nhìn cả tuần, AI có mặt ở cả năm ngày, và giúp PO tiết kiệm thời gian ở phần soạn. Nhưng ở mỗi ngày, kết quả quan trọng nhất đến từ cột “Phần AI không làm được”: một nhóm phản hồi bị gộp sai, một con số bị điền sai, một từ hai bên hiểu khác nhau, một lựa chọn cần người đứng ra giải thích.

Ví dụ này cũng theo đúng phương pháp ở trên. Mỗi việc đều có phần soạn giao cho AI và phần quyết giữ lại. Dữ liệu đưa vào công cụ đã được làm sạch thông tin cá nhân, không chỉ bỏ tên mà cả mã đơn và địa chỉ, và nằm trong phạm vi công ty cho phép. Nếu công ty bạn chưa có quy định như vậy, hãy hỏi trước khi dùng.

• Dùng AI tóm tắt phản hồi khách hàng
• Kiểm tra số liệu AI phân tích

Mẫu tự đánh giá: việc nào của mình là soạn, việc nào là quyết?

Dùng checklist này với lịch làm việc thật của bạn trong một tuần. Mục tiêu không phải để chấm điểm, mà để thấy rõ bạn đang dành thời gian cho phần nào và phần nào cần làm kỹ hơn.

Tuần: ...........

Bước 1. Liệt kê 8 đến 10 việc chính trong tuần (kể cả họp, tin nhắn, tài liệu).

Bước 2. Với mỗi việc, trả lời:
[ ] Việc này chủ yếu là biến thông tin đã có thành chữ, bảng hay danh sách? (phần soạn)
[ ] Việc này cần mình chọn giữa các phương án hoặc chốt một điều là đúng? (phần quyết)
[ ] Nếu kết quả sai, mình là người phải giải thích với team hoặc stakeholder?
[ ] Việc này cần bối cảnh mà chỉ người trong công ty mới biết (chính sách, lịch sử, quan hệ giữa các bên)?
[ ] Việc này cần một cuộc nói chuyện trực tiếp với người khác?

Bước 3. Với phần soạn:
[ ] Công ty có cho phép dùng công cụ AI cho loại tài liệu này không?
[ ] Tài liệu có chứa dữ liệu cá nhân, hợp đồng hay số liệu nội bộ không? Nếu có, không đưa vào khi chưa được phép.
[ ] Mình đã có sẵn sự thật đã xác nhận trước khi nhờ AI soạn chưa?
[ ] Mình sẽ kiểm từng con số, quy tắc và kết luận với nguồn nào?

Bước 4. Với phần quyết:
[ ] Mình nói được lý do của quyết định này trong hai câu.
[ ] Mình nêu được cái giá của phương án không chọn.
[ ] Mình đã ghi lại quyết định và lý do ở nơi team xem được.

Bước 5. Nhìn lại cả tuần:
- Việc nào mình đang tự soạn mà có thể nhờ AI nháp trước?
- Việc quyết nào mình đang làm vội, cần thêm thời gian hoặc bằng chứng?
- Kỹ năng nào trong bốn kỹ năng (đặt vấn đề, kiểm chứng, quyết định có lý do, giữ niềm tin) mình muốn tập trước?

Câu hỏi “nếu kết quả sai, mình là người phải giải thích?” là câu dễ phân loại nhất. Khi câu trả lời là có, việc đó có phần quyết, dù trông nó giống một việc viết lách đơn giản.

Những lỗi người mới dễ mắc khi nghĩ về AI và vai trò PO

• Né hẳn AI vì sợ hoặc vì nghĩ dùng là gian lận. NIST cũng nhắc tới việc né AI không cần thiết khiến người dùng tự bỏ lỡ lợi ích. Nếu công ty cho phép, hãy thử với phần soạn và học cách kiểm.
• Để AI quyết thay. Lấy thứ tự ưu tiên hay kết luận của AI làm câu trả lời cuối mà không tự kiểm lý do. Đây là dạng tin máy quá mức mà NIST gọi là automation bias.
• Đánh giá vai trò PO qua số tài liệu làm ra. Viết được nhiều user story hơn chưa chắc là tạo ra nhiều giá trị hơn. Scrum Guide gắn trách nhiệm của PO với giá trị sản phẩm, không với số tài liệu.
• Đưa dữ liệu nhạy cảm vào công cụ để “cho nhanh”. Dữ liệu khách hàng, hợp đồng, số liệu nội bộ cần được công ty cho phép trước. Hỏi bộ phận pháp chế hoặc IT nếu chưa rõ.
• Lo về sự nghiệp theo tiêu đề báo. Một bài báo không biết công việc của bạn gồm những gì. Bảng tự đánh giá ở trên cho bạn câu trả lời sát thực tế hơn.
• Trình bày kết quả của AI như phán đoán của mình mà chưa kiểm. Nếu stakeholder hỏi “vì sao” và bạn không trả lời được, niềm tin mất đi nhanh hơn thời gian bạn tiết kiệm được.

Tóm tắt

• Theo Scrum Guide 2020, PO chịu trách nhiệm tối đa hóa giá trị sản phẩm và là một người, không phải ủy ban. Trách nhiệm đó không chuyển sang công cụ AI.
• AI giúp tốt phần soạn: nháp tài liệu, tóm tắt, gom nhóm, liệt kê phương án. PO giữ phần quyết: đặt vấn đề, kiểm chứng, đánh đổi, chịu trách nhiệm.
• Tự trả lời câu hỏi “AI có thay được mình không” bằng cách liệt kê việc thật trong tuần và gắn nhãn soạn hay quyết.
• Theo nhận định của bài này, vai trò PO có thể dịch về phía đặt vấn đề, kiểm tra và quyết định. Bốn kỹ năng đáng đầu tư: đặt vấn đề, kiểm chứng, quyết định có lý do, giữ niềm tin.
• Tránh cả hai phía: né hẳn AI, hoặc tin AI quá mức. Và luôn hỏi quy định công ty trước khi đưa dữ liệu vào công cụ.

Mình đang soạn thêm các tình huống PO khác theo cùng khung này, kèm mẫu dùng ngay. Nếu bạn muốn nhận khi có bài mới, đăng ký bản tin bên dưới.

• Nhận bài mới qua email

Câu hỏi thường gặp

AI có thay thế được Product Owner không?

Theo cách nhìn của bài này thì không, vì Scrum Guide 2020 giao trách nhiệm tối đa hóa giá trị sản phẩm cho một người cụ thể. AI làm nhanh phần soạn và tóm tắt, còn quyết định, đánh đổi và trách nhiệm với kết quả vẫn thuộc về PO.

Product Owner nên dùng AI vào việc gì?

Dùng AI cho các việc soạn: bản nháp user story, tóm tắt ghi chú họp, gom nhóm phản hồi, liệt kê phương án. Sau đó PO kiểm từng ý với nguồn thật trước khi dùng, và không đưa dữ liệu nhạy cảm vào công cụ khi công ty chưa cho phép.

PO cần học thêm kỹ năng gì khi có AI?

Bốn kỹ năng đáng đầu tư là đặt vấn đề rõ, kiểm chứng bằng chứng, ra quyết định kèm lý do đánh đổi, và giữ niềm tin với team cùng stakeholder. Theo cách nhìn của bài này, đây là những phần công cụ AI không làm thay được.

Nguồn kiểm tra

• Scrum Guide 2020: Product Owner
• Scrum.org: What is a Product Owner?
• NIST AI 600-1: Generative AI Profile

Bài liên quan

• Dùng Claude cho PO: việc nào giúp được, việc nào phải tự làm: AI soạn nháp rất nhanh. Bài này chỉ ra bốn lỗi cần soi và một checklist để kiểm tra trước khi tài liệu tới tay team.
• Dữ liệu nào không nên đưa vào công cụ AI ở công ty?: Sáu nhóm dữ liệu PO nên giữ ngoài công cụ AI, cách lọc từng đoạn trước khi dán, ví dụ ẩn danh một khiếu nại và checklist dùng ngay.
• Dùng AI tóm tắt phản hồi khách hàng: chỗ dễ sai và cách kiểm: Công cụ AI gom và gọi tên chủ đề rất nhanh, nhưng có thể bịa trích dẫn, làm mất tần suất và bỏ sót nhóm khách nhỏ. Bài này chỉ ra từng chỗ dễ sai và cách PO kiểm trước khi dùng bản tóm tắt để quyết định.
• Số liệu do AI phân tích: kiểm tra gì trước khi báo cáo: Cách PO kiểm tra con số do công cụ AI tính ra: đối chiếu tổng, soi mẫu số và kỳ, tự tính lại vài số quan trọng, rồi ghi rõ phần chưa chắc trong báo cáo.