Mở đầu — vì sao bài này quan trọng
Có một sự thật mà nhiều PM né tránh: bạn không cần phải là "AI PM" để phải làm việc với đội kỹ sư AI. Trước đây, ranh giới khá rõ — chỉ những người làm sản phẩm machine learning (như feed cá nhân hóa của TikTok hay gợi ý sản phẩm của Shopee) mới phải ngồi cùng các data scientist. Nhưng ranh giới đó đang biến mất rất nhanh.
Khi AI "ăn dần" phần mềm (AI eats software), tính năng AI len lỏi vào mọi loại sản phẩm: một app fintech Việt Nam thêm chatbot tư vấn khoản vay, một sàn TMĐT thêm search ngữ nghĩa, một SaaS B2B thêm tính năng tóm tắt tài liệu. Nghĩa là dù bạn đang làm PM cho sản phẩm "bình thường", khả năng rất cao trong 12–18 tháng tới bạn sẽ phải viết spec cho một tính năng có chữ "AI" trong đó, và phải ngồi họp với những vai trò kỹ thuật mà bạn chưa từng làm việc cùng.
Vấn đề là: làm việc với đội kỹ sư AI khác về bản chất so với làm việc với đội kỹ sư phần mềm truyền thống. Phần mềm truyền thống mang tính tất định (deterministic) — input A luôn ra output B. Sản phẩm AI mang tính xác suất (probabilistic) — cùng một input có thể ra output khác nhau, và "đúng 85%" đã có thể là một thành công lớn. Nếu bạn mang tư duy "viết spec rồi nghiệm thu pixel-perfect" sang đây, bạn sẽ đụng tường liên tục, làm hỏng tiến độ và khiến đội kỹ sư AI mệt mỏi.
Bài này không dạy bạn cách xây mô hình AI. Bài này dạy bạn cách làm việc hiệu quả với những người xây nó — hiểu họ là ai, họ nói ngôn ngữ gì, và một PM cần điều chỉnh cách cộng tác ra sao để dự án AI về đích.
Khái niệm cốt lõi
Các vai trò bạn sẽ phải làm việc cùng
Đội kỹ sư AI không phải một khối đồng nhất. Đây là những vai trò bạn cần phân biệt được, vì mỗi người quan tâm đến những thứ rất khác nhau:
- ML Engineer (Machine Learning Engineer): Người đưa mô hình vào sản phẩm thực tế — tối ưu tốc độ, độ trễ (latency), chi phí phục vụ (serving cost). Họ quan tâm: "Mô hình này chạy production có chịu nổi tải không, mất bao lâu để trả kết quả?"
- Data Scientist / Research Scientist: Người nghiên cứu, thử nghiệm, đánh giá xem mô hình nào tốt cho bài toán. Họ quan tâm: "Phương pháp nào cho độ chính xác cao nhất trên dữ liệu của chúng ta?" Họ thường nói bằng ngôn ngữ thống kê (precision, recall, F1).
- Data Engineer: Người xây đường ống dữ liệu (data pipeline) — đảm bảo dữ liệu sạch, đầy đủ, chảy đúng chỗ. Trong dự án AI, "garbage in, garbage out" — không có data engineer tốt thì mô hình giỏi mấy cũng vô dụng.
- MLOps Engineer: Người lo việc triển khai, giám sát, và cập nhật mô hình sau khi lên production (mô hình có bị "trôi" — model drift — theo thời gian không).
- AI/Applied Engineer (thời LLM): Với các tính năng dùng mô hình ngôn ngữ lớn (như gọi API của OpenAI, Claude, Gemini), nhiều đội không train mô hình mà chỉ "ghép nối" — viết prompt, xây pipeline RAG, làm fine-tuning nhẹ. Vai trò này gần với software engineer hơn nhưng cần hiểu hành vi của LLM.
Ba thay đổi tư duy bắt buộc của PM
Thứ nhất — chấp nhận sự không chắc chắn. Trong dự án phần mềm thường, bạn có thể cam kết "tính năng X sẽ ra mắt ngày 15". Trong dự án AI, kết quả phụ thuộc vào việc mô hình có đạt ngưỡng chất lượng hay không — điều này có yếu tố nghiên cứu, không thể ép bằng deadline. PM phải quản lý timeline kiểu "có cổng kiểm tra" (gate) thay vì "đường thẳng".
Thứ hai — định nghĩa "đủ tốt" bằng số, không bằng cảm tính. "Chatbot phải thông minh" là một spec vô dụng. "Chatbot phải trả lời đúng ≥ 80% câu hỏi về chính sách đổi trả, đo trên bộ 200 câu test, với tỉ lệ bịa thông tin (hallucination) < 2%" mới là spec mà kỹ sư AI làm việc được. PM là người chịu trách nhiệm biến mong muốn kinh doanh thành các ngưỡng chấp nhận (acceptance threshold) đo được.
Thứ ba — hiểu đánh đổi (trade-off) thay vì đòi mọi thứ. Trong AI luôn có tam giác: độ chính xác — tốc độ — chi phí. Muốn mô hình thông minh hơn thường tốn tiền hơn và chậm hơn. PM là người ngồi giữa, quyết định "với use case này, ta ưu tiên cái gì". Đây chính là giá trị lớn nhất PM mang lại cho đội kỹ thuật AI.
Ngôn ngữ chung tối thiểu PM cần biết
Bạn không cần học toán, nhưng cần hiểu vài khái niệm để không "ngơ" trong phòng họp:
- Precision vs Recall: Precision = trong những cái mô hình báo "đúng", bao nhiêu thực sự đúng. Recall = trong tất cả cái đáng lẽ phải bắt được, mô hình bắt được bao nhiêu. Một bộ lọc spam ưu tiên precision (đừng chặn nhầm mail thật); một hệ thống phát hiện gian lận ưu tiên recall (đừng bỏ sót vụ gian lận).
- Ground truth / labeled data: Dữ liệu "đáp án chuẩn" để dạy và chấm điểm mô hình. PM thường phải tổ chức việc gán nhãn này.
- Baseline: Phương án đơn giản nhất để so sánh. Đôi khi một quy tắc "if-else" thủ công đã đủ tốt, không cần AI.
- Evaluation set (eval set): Bộ dữ liệu test cố định để đo chất lượng qua các phiên bản.
Tình huống thực tế
Tình huống 1 — Chatbot CSKH của một ví điện tử Việt Nam
Một ví điện tử (giả định tên "VPay", quy mô ~3 triệu người dùng) muốn ra mắt chatbot tự động trả lời câu hỏi CSKH để giảm 40% lượng ticket chuyển cho nhân viên. PM tên Linh, vốn quen làm tính năng giao dịch, lần đầu làm việc với đội AI.
Diễn giải: Linh ban đầu viết user story kiểu cũ: "Là người dùng, tôi muốn chatbot trả lời mọi câu hỏi của tôi." Đội AI lập tức phản hồi rằng spec này không thể nghiệm thu — "mọi câu hỏi" là vô hạn. Sau buổi làm việc, họ cùng nhau thu hẹp phạm vi: chatbot chỉ phủ 5 nhóm câu hỏi phổ biến nhất (chiếm 70% ticket), xây bộ eval 300 câu hỏi thật lấy từ lịch sử ticket. Họ thống nhất ngưỡng: tỉ lệ trả lời đúng ≥ 78%, và với câu ngoài phạm vi, bot phải chuyển cho người chứ không được bịa. Linh cũng đàm phán trade-off: dùng mô hình rẻ hơn cho 70% câu dễ, chỉ gọi mô hình đắt khi câu khó — giúp chi phí API giảm khoảng 35%.
Bài học: Phạm vi (scope) trong dự án AI phải được định nghĩa bằng dữ liệu thật và ngưỡng số, không bằng câu chữ mơ hồ. Và xử lý trường hợp "bot không biết" quan trọng ngang với trường hợp "bot biết".
Tình huống 2 — Đội AI và đội product "lệch pha" về timeline tại một startup logistics
Một startup logistics ở TP.HCM (giả định "GiaoNhanh") muốn dùng AI dự đoán thời gian giao hàng để hiển thị cho khách. PM hứa với ban giám đốc ra mắt trong 6 tuần. Đến tuần thứ 4, mô hình vẫn chỉ đạt sai số trung bình ±25 phút, trong khi kỳ vọng là ±10 phút.
Diễn giải: Vấn đề không phải đội kỹ sư yếu, mà PM đã cam kết deadline theo tư duy phần mềm tất định. Data scientist giải thích: độ chính xác bị giới hạn bởi chất lượng dữ liệu lịch sử — nhiều đơn cũ không ghi đúng thời điểm giao thực tế. Đây là vấn đề data engineering, không phải vấn đề "code nhanh hơn". PM phải quay lại ban giám đốc, trình bày trade-off: hoặc lùi 4 tuần để làm sạch dữ liệu, hoặc ra mắt phiên bản hiển thị "khoảng thời gian" (ví dụ "30–45 phút") thay vì con số chính xác. Họ chọn phương án thứ hai để kịp mùa cao điểm, rồi cải thiện sau.
Bài học: Khi mô hình không đạt, đừng vội ép kỹ sư. Hãy hỏi: nút thắt nằm ở dữ liệu, ở mô hình, hay ở kỳ vọng đặt sai? Phần lớn các "dự án AI thất bại" thực ra là kỳ vọng đặt sai chỗ ngay từ đầu, và đó là lỗi của PM chứ không phải kỹ sư.
Tình huống 3 — PM "dịch" giữa kinh doanh và kỹ thuật ở một sàn TMĐT khu vực
Một sàn TMĐT Đông Nam Á muốn thêm tính năng gợi ý sản phẩm bằng AI. Đội nghiên cứu hào hứng khoe mô hình mới đạt "precision tăng 4 điểm". Nhưng ban kinh doanh không hiểu con số đó nghĩa là gì, còn đội nghiên cứu không hiểu vì sao kinh doanh "không vui".
Diễn giải: PM đóng vai người phiên dịch. Cô quy đổi: "precision tăng 4 điểm" tương đương ước tính khách bấm vào gợi ý nhiều hơn ~6%, dự kiến tăng doanh thu thêm khoảng 2 tỉ đồng/quý. Ngược lại, cô mang nhu cầu kinh doanh về cho đội nghiên cứu: "Sếp cần thấy tác động lên giỏ hàng, không chỉ click — hãy thêm chỉ số đó vào báo cáo A/B test." Cô cũng yêu cầu đội kỹ thuật giải thích được vì sao mô hình gợi ý món đó (explainability), vì bộ phận pháp lý lo về minh bạch.
Bài học: Giá trị độc nhất của PM trong đội AI là dịch hai chiều — biến chỉ số kỹ thuật thành tác động kinh doanh, và biến mục tiêu kinh doanh thành chỉ số đo được. Không ai khác trong phòng làm được việc này.
Hướng dẫn từng bước
Đây là quy trình bạn có thể áp dụng khi bắt đầu cộng tác với một đội kỹ sư AI cho tính năng mới:
Bước 1 — Lập bản đồ vai trò và người chịu trách nhiệm. Trước buổi kickoff, xác định ai là ML engineer, ai là data scientist/data engineer, ai lo MLOps. Hỏi rõ: với tính năng này, nút thắt khả năng nằm ở đâu — mô hình, dữ liệu, hay hạ tầng?
Bước 2 — Định nghĩa bài toán bằng ngôn ngữ AI. Cùng đội biến mong muốn kinh doanh thành một bài toán cụ thể: đây là bài phân loại, dự đoán, sinh nội dung, hay xếp hạng? Output mong muốn là gì? Trường hợp sai thì hậu quả ra sao (sai kiểu nào tốn kém hơn)?
Bước 3 — Thống nhất chỉ số và ngưỡng chấp nhận. Cùng nhau chọn metric (precision/recall, sai số, tỉ lệ hallucination...) và đặt ngưỡng "đủ tốt để ra mắt". Luôn xác định một baseline để biết AI có thực sự tốt hơn cách đơn giản không.
Bước 4 — Đảm bảo có eval set và dữ liệu nhãn. Hỏi: ta sẽ đo chất lượng trên bộ dữ liệu nào? Ai gán nhãn đáp án chuẩn? PM thường phải tổ chức việc thu thập dữ liệu thật từ sản phẩm hiện có.
Bước 5 — Đàm phán trade-off rõ ràng. Ngồi với đội, quyết định thứ tự ưu tiên: chính xác, tốc độ, hay chi phí. Ghi lại quyết định này thành văn bản để sau không cãi nhau.
Bước 6 — Lập kế hoạch theo cổng (gate), không theo đường thẳng. Chia dự án thành mốc: đạt baseline → đạt ngưỡng trên eval → thử nghiệm A/B trên nhóm nhỏ → ra mắt rộng. Mỗi cổng có tiêu chí pass/fail rõ ràng.
Bước 7 — Lên kế hoạch cho vòng đời sau ra mắt. Hỏi MLOps: ta giám sát chất lượng mô hình thế nào khi đã chạy thật? Khi nào cần train lại? Nếu mô hình "trôi" thì cảnh báo bằng cách nào?
Lỗi thường gặp & mẹo
Lỗi 1 — Đối xử với dự án AI như dự án phần mềm thường. Đòi cam kết deadline cứng cho phần có yếu tố nghiên cứu sẽ làm hỏng cả niềm tin lẫn tiến độ. Mẹo: dùng ngôn ngữ "spike" — cấp cho đội một khoảng thời gian cố định để thử nghiệm khả thi, rồi mới cam kết lịch.
Lỗi 2 — Viết spec mơ hồ kiểu "phải thông minh / phải tốt". Kỹ sư AI không nghiệm thu được câu chữ. Mẹo: mọi yêu cầu chất lượng phải đi kèm con số và bộ dữ liệu để đo.
Lỗi 3 — Bỏ quên dữ liệu. PM hay tập trung vào mô hình mà quên rằng 70–80% công sức dự án AI nằm ở dữ liệu. Mẹo: hỏi sớm "dữ liệu của ta đủ và sạch chưa?" trước khi mơ về tính năng.
Lỗi 4 — Không thiết kế cho trường hợp AI sai. AI sẽ sai, đó là bản chất. Mẹo: luôn thiết kế "lối thoát" — fallback về người thật, thông báo độ tin cậy, hoặc cho người dùng sửa kết quả.
Lỗi 5 — Sa đà vào kỹ thuật, quên giá trị người dùng. PM dễ bị cuốn vào việc tăng vài điểm precision mà quên hỏi: người dùng có thực sự cảm nhận khác biệt không? Mẹo: luôn nối chỉ số kỹ thuật về một chỉ số sản phẩm/kinh doanh.
Mẹo vàng về giao tiếp: Hãy học vừa đủ thuật ngữ để hỏi đúng câu, nhưng đừng giả vờ là chuyên gia kỹ thuật. Đội AI tôn trọng một PM thành thật nói "tôi không rành phần này, giải thích giúp tôi" hơn là một PM ra vẻ biết rồi quyết sai.
Bài tập thực hành
- Bản đồ vai trò: Chọn một tính năng AI bạn quan tâm (ví dụ chatbot CSKH cho một shop trên Shopee). Liệt kê các vai trò kỹ thuật cần có (ML engineer, data scientist, data engineer, MLOps) và viết một câu hỏi cụ thể bạn sẽ hỏi mỗi người trong buổi kickoff.
- Viết lại spec mơ hồ thành spec đo được: Lấy yêu cầu "AI tóm tắt phải chất lượng tốt" và viết lại thành một acceptance criteria có metric, ngưỡng số, và mô tả bộ eval set (ít nhất 3 dòng).
- Phân tích trade-off: Cho tình huống một app đọc báo muốn AI gợi ý tin tức. Hãy viết một đoạn ngắn (~150 từ) lập luận: với use case này nên ưu tiên precision hay recall, ưu tiên tốc độ hay chi phí, và vì sao.
- Đóng vai người phiên dịch: Đội kỹ thuật báo "recall tăng từ 0.72 lên 0.81". Viết 2 phiên bản giải thích con số này: một cho CEO (ngôn ngữ kinh doanh) và một cho đội marketing (ngôn ngữ tác động người dùng).
Tóm tắt
- Bạn không cần là "AI PM" nhưng sẽ ngày càng phải làm việc với đội kỹ sư AI, vì AI đang len vào mọi loại sản phẩm.
- Phân biệt được các vai trò: ML engineer (đưa mô hình vào production), data scientist (nghiên cứu, đánh giá), data engineer (đường ống dữ liệu), MLOps (vận hành sau ra mắt) — để hỏi đúng người đúng câu.
- Ba thay đổi tư duy bắt buộc: chấp nhận sự không chắc chắn (probabilistic), định nghĩa "đủ tốt" bằng số, và hiểu trade-off chính xác – tốc độ – chi phí.
- Học vừa đủ ngôn ngữ chung (precision/recall, baseline, eval set, ground truth) để không bị "ngơ" trong phòng họp.
- Giá trị độc nhất của PM trong đội AI là dịch hai chiều: biến chỉ số kỹ thuật thành tác động kinh doanh, và biến mục tiêu kinh doanh thành chỉ số đo được.
- Lập kế hoạch theo cổng (gate) chứ không theo đường thẳng, luôn thiết kế lối thoát cho khi AI sai, và đừng bao giờ quên dữ liệu — nơi 70–80% công sức thật sự nằm.