Mở đầu — vì sao bài này quan trọng
Có một cái bẫy mà gần như mọi AI Product Manager mới vào nghề đều rơi vào: nghĩ rằng vì AI đang "hot", vì sếp muốn gắn chữ AI lên slide gọi vốn, vì đối thủ vừa ra mắt tính năng chatbot, nên sản phẩm của mình bắt buộc phải có AI. Đây là tư duy ngược. Một PM giỏi không bắt đầu từ công nghệ rồi đi tìm vấn đề; họ bắt đầu từ vấn đề rồi mới hỏi: "Liệu AI có phải công cụ phù hợp nhất để giải bài toán này không?"
Bài học này dạy bạn một thứ tưởng đơn giản nhưng cực kỳ quyết định đến sự thành bại của sản phẩm: kỹ năng nhận diện khi nào nên dùng AI và khi nào KHÔNG nên. Đây không phải kỹ năng kỹ thuật, mà là kỹ năng phán đoán sản phẩm (product judgment). Nó giúp bạn tiết kiệm hàng trăm triệu đồng ngân sách kỹ thuật, tránh được những lời hứa với khách hàng mà bạn không thể giữ, và quan trọng nhất, giúp bạn nói "không" với AI một cách tự tin khi cần thiết.
Hãy nhớ: dùng AI sai chỗ không chỉ lãng phí tiền. Nó tạo ra trải nghiệm tệ, làm xói mòn niềm tin của người dùng, và đôi khi gây ra rủi ro pháp lý nghiêm trọng. Một quyết định "có nên dùng AI hay không" đứng đúng ngay từ đầu sẽ tiết kiệm cho bạn nhiều tháng đau khổ về sau.
Khái niệm cốt lõi
Trọng tâm của bài này là một bộ tiêu chí mà tôi gọi là AI Suitability Test — bài kiểm tra mức độ phù hợp của AI. Khi đứng trước bất kỳ tính năng nào, bạn hãy soi nó qua bộ lọc này trước khi quyết định.
Ba điều kiện khiến AI phù hợp
1. Bài toán có nhiều dữ liệu lịch sử (historical data).
AI, đặc biệt là machine learning, học từ dữ liệu. Nếu bạn không có dữ liệu — hoặc dữ liệu quá ít, quá nhiễu, không gắn nhãn — thì mô hình không có gì để học. Ví dụ: một sàn thương mại điện tử đã chạy 3 năm với hàng triệu giao dịch có thể xây hệ thống gợi ý sản phẩm rất tốt, vì lịch sử mua hàng chính là "giáo viên" của mô hình. Ngược lại, một startup mới ra mắt tuần trước, chưa có người dùng nào, thì việc cố xây "AI recommendation" là vô nghĩa — không có dữ liệu thì AI cũng bó tay.
Lưu ý quan trọng trong kỷ nguyên LLM (mô hình ngôn ngữ lớn): với các tác vụ ngôn ngữ chung như tóm tắt, dịch, trả lời câu hỏi, bạn có thể mượn dữ liệu khổng lồ mà các foundation model đã được huấn luyện sẵn. Nhưng nếu bài toán mang tính đặc thù của riêng doanh nghiệp bạn (ví dụ: dự đoán khách nào sắp rời bỏ dịch vụ viễn thông của bạn), thì bạn vẫn cần dữ liệu nội bộ chất lượng.
2. Pattern phức tạp, khó viết quy tắc (rule) thủ công.
Đây là tiêu chí dễ bị bỏ qua nhất. Nguyên tắc vàng: nếu bạn có thể giải bài toán bằng vài câu lệnh if-else đơn giản, thì đừng dùng AI. AI sinh ra để xử lý những pattern mà con người không thể viết hết thành quy tắc rõ ràng.
Hãy so sánh:
- "Nếu số tiền giao dịch lớn hơn 50 triệu thì cảnh báo" — đây là một rule. Không cần AI.
- "Phát hiện giao dịch gian lận dựa trên hàng trăm tín hiệu kết hợp: thời gian, địa điểm, thiết bị, hành vi bất thường so với thói quen từng người..." — pattern này phức tạp đến mức không ai viết nổi thành if-else đầy đủ. Đây mới là đất diễn của AI.
3. Chấp nhận được sự không hoàn hảo (tolerance for imperfection).
Đây là điều kiện quyết định mà nhiều người Việt mới làm AI hay xem nhẹ. AI về bản chất là xác suất, không phải tất định. Một mô hình đạt độ chính xác 95% nghĩa là cứ 100 lần thì sai 5 lần — và bạn thường không biết trước nó sẽ sai lúc nào.
Câu hỏi sống còn bạn phải tự hỏi: "Khi AI đoán sai, hậu quả là gì?"
- Gợi ý sai một bài hát trên Spotify? Người dùng bấm next, không ai chết. Tolerance cao — AI rất phù hợp.
- Tính sai số dư tài khoản ngân hàng, hay duyệt sai liều thuốc cho bệnh nhân? Hậu quả thảm khốc. Tolerance bằng không — tuyệt đối không giao cho AI quyết định cuối cùng mà không có con người kiểm soát.
Khi nào KHÔNG nên dùng AI
Gộp lại ba tiêu chí trên, bạn sẽ thấy rõ những trường hợp nên tránh xa AI:
- Khi cần độ chính xác tuyệt đối 100%. Tính toán tài chính, kế toán, pháp lý — hãy dùng công thức và logic xác định.
- Khi rule đơn giản đã giải quyết được. Đừng dùng dao mổ trâu để giết gà. Một câu if-else chạy nhanh hơn, rẻ hơn, dễ debug hơn AI gấp nhiều lần.
- Khi không có dữ liệu và không thể mượn từ foundation model.
- Khi cần khả năng giải thích minh bạch tuyệt đối mà bài toán lại đòi mô hình "hộp đen". Ví dụ một số quy định cho vay bắt buộc giải thích lý do từ chối — nếu mô hình không giải thích được, bạn vướng rủi ro pháp lý.
- Khi chi phí vận hành AI vượt xa giá trị mang lại. Gọi LLM tốn tiền theo token và có độ trễ. Nếu tính năng chỉ tiết kiệm cho người dùng 2 giây nhưng tốn 2.000 đồng mỗi lượt, hãy cân nhắc lại.
Tình huống thực tế
Ví dụ 1: Tiki và bài toán phân loại sản phẩm — đúng chỗ cho AI
Một sàn thương mại điện tử lớn như Tiki mỗi ngày có hàng chục nghìn sản phẩm mới được nhà bán đăng lên, kèm tiêu đề kiểu "Áo thun nam form rộng vải cotton 4 chiều mẫu 2026 SALE SỐC". Nhiệm vụ: tự động gán mỗi sản phẩm vào đúng danh mục (Thời trang > Áo nam > Áo thun).
Hãy soi qua AI Suitability Test:
- Dữ liệu lịch sử? Có — hàng triệu sản phẩm đã được gán nhãn danh mục trong nhiều năm. Quá đủ.
- Pattern phức tạp khó viết rule? Có. Bạn không thể viết if-else cho mọi cách nhà bán đặt tên sản phẩm lộn xộn bằng tiếng Việt. Từ "form" có thể là áo, "4 chiều" là loại vải...
- Chấp nhận sai sót? Có. Nếu phân loại sai 3%, nhà bán có thể sửa thủ công, hoặc đội kiểm duyệt rà soát. Không ai thiệt hại nghiêm trọng.
Ví dụ 2: Một fintech Việt và cái bẫy "AI duyệt vay"
Một startup fintech (gọi là Công ty V) muốn xây tính năng "AI tự động duyệt khoản vay tiêu dùng dưới 10 triệu trong 30 giây". Nghe rất ngầu, rất đáng để gọi vốn. Nhưng hãy phân tích kỹ.
- Dữ liệu? Có, họ có lịch sử khoản vay và tỷ lệ trả nợ. Tạm ổn.
- Pattern phức tạp? Có. Đánh giá rủi ro tín dụng đúng là bài toán nhiều biến.
- Tolerance for imperfection? Đây là chỗ chết người. Nếu AI duyệt sai cho người không đủ khả năng trả, công ty mất tiền thật và đẩy người vay vào nợ xấu. Nếu AI từ chối oan một khách hàng tốt, công ty mất doanh thu và có thể bị khiếu nại vì không giải thích được lý do.
Giải pháp đúng mà Công ty V cuối cùng chọn: dùng AI làm trợ lý chấm điểm, không phải người ra quyết định cuối. AI đưa ra điểm rủi ro và liệt kê các tín hiệu (credit scoring + giải thích), nhưng với các khoản nằm ở vùng "xám", con người vẫn duyệt cuối cùng. Đây gọi là human-in-the-loop — giữ con người trong vòng kiểm soát ở những điểm rủi ro cao.
Bài học: Khi hậu quả của một quyết định sai là nghiêm trọng và không thể đảo ngược, đừng để AI quyết định cuối cùng. Hãy dùng nó để hỗ trợ, tăng tốc, gợi ý — còn con người giữ vô lăng.
Ví dụ 3: Cái bẫy "dùng AI cho việc một dòng code làm được"
Một PM tại công ty SaaS nọ yêu cầu đội kỹ thuật xây "AI thông minh tự động điền tỉnh/thành dựa trên mã bưu chính người dùng nhập". Đội đã định tích hợp một LLM để "hiểu" mã bưu chính.
Khoan đã. Mã bưu chính Việt Nam có cấu trúc cố định và có sẵn bảng tra cứu chính thức. "70000" luôn là TP.HCM. Đây thuần túy là một phép tra bảng (lookup table) — một dòng truy vấn cơ sở dữ liệu giải quyết trong vài mili giây, chính xác 100%, miễn phí.
Nếu dùng LLM: chậm hơn hàng trăm lần, tốn tiền token mỗi lượt, và tệ nhất là có thể trả sai vì LLM đôi khi "bịa" (hallucinate). Đây là ví dụ kinh điển của việc lấy búa tạ đập hạt dẻ.
Bài học: Trước khi nghĩ đến AI, luôn hỏi: "Liệu một rule, một bảng tra, hay một công thức có giải quyết được không?" Nếu có, đừng đụng đến AI. Sự đơn giản là một dạng đẳng cấp kỹ thuật.
Hướng dẫn từng bước
Đây là quy trình bạn áp dụng mỗi khi đứng trước câu hỏi "có nên dùng AI cho tính năng này không":
Bước 1 — Mô tả bài toán bằng ngôn ngữ vấn đề, không phải ngôn ngữ giải pháp. Đừng viết "xây chatbot AI". Hãy viết "giúp khách hàng tự tìm câu trả lời cho 80% câu hỏi phổ biến mà không cần đợi tổng đài". Tách vấn đề ra khỏi công nghệ giúp bạn nhìn rõ.
Bước 2 — Chạy AI Suitability Test với ba câu hỏi.
- Tôi có dữ liệu (hoặc mượn được từ foundation model) không?
- Pattern có phức tạp đến mức không viết được thành rule không?
- Tôi có chấp nhận được khi AI đoán sai không?
Bước 3 — Đánh giá cái giá của sai sót (cost of error). Vẽ một ma trận đơn giản: khi AI sai, ai thiệt? thiệt bao nhiêu? có khắc phục được không? Nếu hậu quả nghiêm trọng và không đảo ngược, hoặc bạn dừng AI, hoặc bạn thêm human-in-the-loop.
Bước 4 — So sánh với phương án không-AI. Luôn nghĩ ra một giải pháp baseline bằng rule/heuristic/lookup. Nhiều khi baseline đã đủ tốt 90% mà rẻ hơn 100 lần. Nếu AI chỉ hơn baseline một chút mà tốn kém nhiều, hãy chọn baseline.
Bước 5 — Tính bài toán kinh tế thô. Ước lượng chi phí mỗi lượt (token, hạ tầng, độ trễ) nhân với số lượt dự kiến. Đặt cạnh giá trị mang lại. Nếu không dương rõ ràng, cân nhắc lại.
Bước 6 — Ra quyết định và ghi lại lý do. Viết một đoạn ngắn: "Chúng tôi dùng/không dùng AI cho X vì..." Tài liệu này cực kỳ quý khi sau này cần giải trình với sếp hoặc xem lại quyết định.
Lỗi thường gặp & mẹo
Lỗi 1 — "AI-first" thay vì "problem-first". Bắt đầu từ "ta phải có AI" rồi đi tìm chỗ nhét vào. Hậu quả là những tính năng AI vô dụng, không ai dùng. Mẹo: luôn để vấn đề dẫn dắt, công nghệ theo sau.
Lỗi 2 — Bỏ qua tiêu chí "tolerance for imperfection". Nhiều PM chỉ thấy AI làm được mà quên hỏi "khi sai thì sao". Mẹo: với mọi tính năng AI, viết ra kịch bản xấu nhất khi nó sai trước khi phê duyệt.
Lỗi 3 — Dùng AI cho việc rule giải quyết được. Tốn tiền, chậm, lại còn kém tin cậy hơn. Mẹo: ghi nhớ câu thần chú "nếu if-else làm được thì đừng gọi LLM".
Lỗi 4 — Quên chi phí và độ trễ. Một demo chạy mượt với 10 người dùng có thể đốt sạch ngân sách khi scale lên 1 triệu lượt/ngày. Mẹo: luôn nhân chi phí đơn vị với quy mô thật trước khi cam kết.
Lỗi 5 — Để AI quyết định ở vùng rủi ro cao mà không có con người. Mẹo: phân vùng — việc rủi ro thấp để AI tự chạy, việc rủi ro cao đặt human-in-the-loop.
Mẹo vàng: Một AI PM trưởng thành được đánh giá không phải bởi số tính năng AI họ ship, mà bởi số lần họ dũng cảm nói không với AI khi nó không phải lựa chọn đúng.
Bài tập thực hành
Hãy lấy giấy bút (hoặc mở một file) và làm bài tập sau. Mục tiêu là biến AI Suitability Test thành phản xạ.
Phần 1 — Phân loại nhanh. Với mỗi tính năng dưới đây, quyết định "Nên dùng AI" hay "Không nên dùng AI", và viết một câu lý do dựa trên ba tiêu chí:
- Tính tổng tiền giỏ hàng và thuế VAT.
- Gợi ý sản phẩm liên quan trên trang chi tiết sản phẩm.
- Kiểm tra mật khẩu người dùng nhập có đủ 8 ký tự không.
- Tự động viết tóm tắt cho một bài đánh giá sản phẩm dài của khách.
- Duyệt cấp tài khoản admin với toàn quyền hệ thống.
- Phát hiện bình luận spam/độc hại trong cộng đồng người dùng.
- Chạy đủ AI Suitability Test cho nó.
- Trả lời: "Nếu tính năng này đoán sai, hậu quả là gì và ai gánh chịu?"
- Đề xuất: có cần human-in-the-loop không, ở điểm nào?
Gợi ý đáp án Phần 1: các mục 1, 3, 5 thuộc nhóm KHÔNG nên dùng AI (cần chính xác tuyệt đối hoặc rule đơn giản giải quyết được); các mục 2, 4, 6 phù hợp với AI (pattern phức tạp, có dữ liệu, sai sót chấp nhận được).
Tóm tắt
- Đừng bao giờ bắt đầu từ "phải có AI". Bắt đầu từ vấn đề, rồi mới hỏi AI có phải công cụ đúng không.
- AI Suitability Test gồm ba điều kiện phải cùng thỏa: (1) có dữ liệu lịch sử hoặc mượn được từ foundation model, (2) pattern phức tạp khó viết thành rule, (3) chấp nhận được sự không hoàn hảo.
- Tiêu chí quan trọng nhất và hay bị quên nhất là tolerance for imperfection — luôn hỏi "khi AI sai thì hậu quả là gì?".
- KHÔNG dùng AI khi: cần chính xác 100%, rule đơn giản đã đủ, không có dữ liệu, cần minh bạch tuyệt đối mà mô hình không giải thích được, hoặc chi phí vượt giá trị.
- Ở vùng rủi ro cao, đừng để AI quyết định cuối — dùng human-in-the-loop.
- Đẳng cấp của một AI PM thể hiện ở việc biết nói "không" với AI đúng lúc, không phải ship thật nhiều tính năng AI.