Mở đầu — vì sao bài này quan trọng
Trong bảy bài trước, bạn đã học cách dùng AI như một trợ lý cho công việc PM: viết PRD nhanh hơn, phân tích thị trường sâu hơn, đọc dữ liệu thông minh hơn. Tất cả những thứ đó là AI giúp bạn làm việc. Bài 8 này lật ngược vấn đề: bây giờ bạn không dùng AI cho mình nữa, mà bạn xây dựng tính năng AI cho người dùng cuối của sản phẩm.
Đây là một bước nhảy lớn về tư duy, và cũng là nơi nhiều PM Việt Nam vấp ngã. Ban giám đốc đọc báo về ChatGPT, gọi bạn vào phòng họp và nói: "Sản phẩm mình cần có AI." Câu hỏi tiếp theo — "AI để làm gì, giải quyết vấn đề nào cho khách hàng?" — thường rơi vào im lặng. Nếu bạn không trả lời được câu đó, bạn sẽ tiêu vài tỷ đồng ngân sách để gắn một con chatbot vô dụng vào góc màn hình.
Một PM xây dựng tính năng AI không cần biết code, không cần huấn luyện mô hình, không cần hiểu toán học đằng sau transformer. Nhưng bạn bắt buộc phải hiểu: AI làm được gì, không làm được gì, khi nào nên dùng AI thay vì logic truyền thống, và cái giá phải trả là gì. Đó chính xác là phạm vi của bài này. Sau bài học, bạn sẽ có một khung tư duy để đánh giá bất kỳ ý tưởng "thêm AI" nào — và đủ tự tin để nói "không" khi cần.
Khái niệm cốt lõi
AI feature khác gì với AI làm trợ lý cho PM?
Khi bạn dùng ChatGPT để soạn PRD, bạn là người kiểm soát: bạn đọc kết quả, bạn sửa, bạn chịu trách nhiệm. Nếu AI sai, bạn phát hiện ngay vì bạn là chuyên gia trong lĩnh vực đó.
Nhưng khi bạn nhúng AI vào sản phẩm cho hàng nghìn người dùng, mọi thứ thay đổi. Người dùng không phải chuyên gia. Họ tin kết quả AI đưa ra. Họ không biết khi nào AI "bịa". Và lỗi không còn là chuyện riêng của bạn — nó là rủi ro thương hiệu, rủi ro pháp lý, đôi khi là rủi ro an toàn cho người dùng. Vì vậy, xây dựng AI feature đòi hỏi kỷ luật cao hơn nhiều so với dùng AI cá nhân.
AI làm tốt cái gì, dở cái gì?
Hãy ghi nhớ bảng phân loại này như kim chỉ nam. AI dựa trên mô hình ngôn ngữ lớn (LLM) làm tốt những việc:
- Hiểu và sinh ngôn ngữ tự nhiên: tóm tắt, dịch, viết lại, phân loại văn bản theo ý nghĩa.
- Xử lý dữ liệu phi cấu trúc: trích thông tin từ email, review, hợp đồng, ảnh chụp hóa đơn.
- Việc "mơ hồ", không có một đáp án đúng duy nhất: gợi ý, cá nhân hóa, sáng tạo nội dung nháp.
- Khớp ngữ nghĩa: tìm kiếm theo ý định ("áo cho tiệc cưới mùa hè") thay vì khớp từ khóa.
- Tính toán chính xác tuyệt đối: tính tiền, tính thuế, cộng giỏ hàng. Đừng bao giờ để LLM tính tổng đơn hàng — dùng code thường.
- Việc cần kết quả nhất quán 100%: cùng một đầu vào phải ra cùng một đầu ra mỗi lần (LLM có tính ngẫu nhiên).
- Quyết định có hậu quả nặng và không thể đảo ngược: duyệt vay, chẩn đoán y khoa, xóa dữ liệu — AI có thể hỗ trợ nhưng con người phải quyết.
- Việc có luật lệ rõ ràng, cứng nhắc: "Nếu tuổi < 18 thì chặn" — đây là
if/else, không phải việc của AI.
Nguyên tắc vàng: AI vs logic truyền thống
Đây là câu hỏi quan trọng nhất bài học. Trước khi gắn AI vào bất cứ đâu, hãy tự hỏi: "Vấn đề này có thể giải bằng quy tắc rõ ràng (rule-based) không?"
Nếu có — ví dụ "gửi email nhắc khi giỏ hàng bị bỏ quên sau 2 tiếng" — thì dùng logic truyền thống. Nó rẻ hơn, nhanh hơn, dễ debug, dự đoán được, và không bao giờ "bịa". Gắn AI vào đây là vẽ rắn thêm chân.
Nếu không — vì đầu vào quá đa dạng, mơ hồ, hoặc cần hiểu ngôn ngữ/hình ảnh — thì AI mới có đất diễn. Ví dụ: "phân loại 10.000 phản hồi khách hàng mỗi ngày theo cảm xúc và chủ đề." Viết rule cho việc này là bất khả thi; AI làm trong vài giây.
Một mẹo thực chiến: phần lớn tính năng tốt nhất là lai (hybrid) — AI lo phần mơ hồ, code thường lo phần chính xác. Ví dụ chatbot bán hàng: AI hiểu câu hỏi của khách, nhưng giá tiền và tồn kho lấy từ database qua code, không để AI tự "nhớ".
Ba kiến trúc AI feature phổ biến PM cần phân biệt
- Gọi API mô hình có sẵn (OpenAI, Claude, Gemini): nhanh nhất để triển khai, không cần đội ML. 90% tính năng AI của startup nên bắt đầu ở đây.
- RAG (Retrieval-Augmented Generation): AI trả lời dựa trên dữ liệu của riêng bạn (tài liệu nội bộ, catalog sản phẩm). Cần khi bạn muốn AI biết những gì mô hình gốc không biết.
- Fine-tuning / mô hình riêng: đắt, chậm, cần đội ngũ và dữ liệu lớn. Chỉ chọn khi đã chứng minh được giá trị và cần tối ưu sâu. Đa số PM sẽ không chạm tới mức này trong vài năm đầu.
Tình huống thực tế
Tình huống 1 — Tiki và bài toán phân loại review (làm đúng)
Một sàn TMĐT lớn tại Việt Nam (gọi tên giả định là sàn "MarketX", mô phỏng bối cảnh kiểu Tiki/Shopee) nhận khoảng 50.000 đánh giá sản phẩm mỗi ngày. Đội vận hành cần biết review nào tố cáo hàng giả, review nào phàn nàn giao hàng, review nào khen để đẩy lên top. Trước đây họ thuê 8 nhân viên đọc thủ công, xử lý chậm, mỗi review chờ tới 2 ngày.
PM đề xuất tính năng AI phân loại review tự động. Họ gọi API của một LLM, đưa vào từng review và yêu cầu trả về nhãn: chủ đề (giao hàng / chất lượng / hàng giả / dịch vụ) và cảm xúc (tích cực / trung lập / tiêu cực). Kết quả: 92% review được phân loại đúng, thời gian xử lý còn vài giây, đội người tập trung vào 8% ca khó.
Bài học rút ra: Đây là use case lý tưởng cho AI — đầu vào là ngôn ngữ tự nhiên đa dạng, không thể viết rule, và sai một chút cũng không gây hậu quả nghiêm trọng (review phân loại sai có thể sửa sau). PM đã chọn đúng loại việc để giao cho AI.
Tình huống 2 — Fintech và con chatbot tư vấn vay (làm sai rồi sửa)
Một fintech ở TP.HCM muốn tạo lợi thế bằng "trợ lý AI tư vấn khoản vay". Phiên bản đầu, đội kỹ thuật để chatbot tự trả lời mọi câu hỏi của khách, kể cả "với thu nhập 15 triệu tôi vay được bao nhiêu, lãi suất mấy phần trăm?". Chatbot tự tin đưa ra con số cụ thể — nhưng con số đó là AI bịa ra, không khớp với chính sách thực. Một khách hàng chụp màn hình câu trả lời "lãi suất 0,9%/tháng", đến văn phòng đòi đúng mức đó, dẫn tới khiếu nại và một bài đăng Facebook lan truyền.
PM phải làm lại theo kiến trúc lai. Sau khi sửa: AI chỉ làm nhiệm vụ hiểu câu hỏi và trình bày thân thiện; còn mọi con số (hạn mức, lãi suất, điều kiện) đều được tính bằng engine quy tắc của công ty và truyền vào cho AI đọc. Khi khách hỏi điều ngoài phạm vi, chatbot được lập trình để nói "Để được báo lãi suất chính xác, anh/chị vui lòng nhập hồ sơ" thay vì đoán bừa.
Bài học rút ra: Không bao giờ để AI tự sinh ra dữ liệu có hậu quả pháp lý/tài chính. Hãy tách bạch: AI lo ngôn ngữ, hệ thống lo sự thật. Và luôn thiết kế "đường lui" cho những câu AI không nên trả lời.
Tình huống 3 — Startup giáo dục và tính năng chấm bài tự luận (đánh giá đúng giá trị)
Một startup edtech Đông Nam Á (bối cảnh kiểu Indonesia/Việt Nam) có 200.000 học viên luyện viết tiếng Anh. Vấn đề: bài tự luận cần giáo viên chấm, mà giáo viên không đủ, mỗi bài chờ 3 ngày — học viên mất động lực.
PM cân nhắc: chấm tự luận là việc "mơ hồ", không có một đáp án đúng duy nhất, lại cần hiểu ngôn ngữ — đúng kiểu việc AI làm tốt. Họ xây tính năng AI chấm sơ bộ: chỉ ra lỗi ngữ pháp, gợi ý cải thiện câu, cho điểm ước lượng theo thang. Nhưng PM rất tỉnh táo về giới hạn: điểm AI chỉ là tham khảo, có dòng ghi rõ "đây là đánh giá tự động, điểm chính thức do giáo viên xác nhận", và học viên có thể yêu cầu giáo viên chấm lại. Kết quả: 80% bài được phản hồi tức thì, giáo viên chỉ review những bài học viên không hài lòng, thời gian chờ giảm từ 3 ngày xuống vài phút.
Bài học rút ra: AI feature thành công không phải là AI thay thế hoàn toàn con người, mà là AI gánh phần thô để con người tập trung phần tinh. Và việc truyền đạt giới hạn cho người dùng ("đây là đánh giá tự động") cũng quan trọng như chính tính năng.
Hướng dẫn từng bước
Đây là quy trình bạn có thể áp dụng cho mọi đề xuất "thêm AI vào sản phẩm":
Bước 1 — Bắt đầu từ vấn đề, không từ công nghệ. Viết ra vấn đề của người dùng trước, không được nhắc tới chữ "AI". Nếu không mô tả được nỗi đau cụ thể (ai, khi nào, đau cỡ nào), dừng lại — bạn đang giải pháp đi tìm vấn đề.
Bước 2 — Kiểm tra: rule-based có giải được không? Tự hỏi liệu một loạt if/else rõ ràng có xử lý được không. Nếu có, dùng nó. Chỉ chuyển sang AI khi đầu vào quá đa dạng/mơ hồ hoặc cần hiểu ngôn ngữ, hình ảnh, ngữ nghĩa.
Bước 3 — Đánh giá mức độ chịu lỗi (error tolerance). Hỏi: "Nếu AI sai 1 trong 10 lần, hậu quả là gì?" Nếu hậu quả nhẹ và sửa được (gợi ý sản phẩm, phân loại review) — AI rất hợp. Nếu hậu quả nặng và khó đảo ngược (giao dịch tiền, y tế) — bắt buộc có con người duyệt cuối.
Bước 4 — Chọn kiến trúc tối giản. Bắt đầu bằng gọi API mô hình có sẵn. Chỉ thêm RAG khi cần AI biết dữ liệu riêng. Tránh fine-tuning cho tới khi đã chứng minh giá trị.
Bước 5 — Thiết kế "đường lui" và guardrail. Định nghĩa trước: AI được phép trả lời gì, không được trả lời gì, và làm gì khi không chắc (chuyển người thật, hỏi lại, từ chối lịch sự). Phần dữ liệu nhạy cảm sẽ được đào sâu ở Bài 37, nhưng ngay từ đây bạn phải tính tới.
Bước 6 — Đặt thước đo chất lượng trước khi build. Xác định "thế nào là đủ tốt": độ chính xác bao nhiêu phần trăm thì chấp nhận được? Đo trên một tập dữ liệu thật trước khi tung ra toàn bộ người dùng.
Bước 7 — Ra mắt nhỏ, gắn vòng phản hồi. Bật cho 5% người dùng, thêm nút "kết quả này có hữu ích không?", thu thập case sai để cải thiện prompt. AI feature là sản phẩm sống, không phải build-một-lần-xong.
Lỗi thường gặp & mẹo
Lỗi 1 — Gắn AI vì sợ lạc hậu, không vì người dùng. "Đối thủ có AI nên mình cũng phải có." Đây là cái bẫy phổ biến nhất. Một chatbot vô dụng còn tệ hơn không có gì, vì nó làm xói mòn niềm tin. Mẹo: luôn bắt đầu từ vấn đề, và sẵn sàng kết luận "tính năng này không cần AI".
Lỗi 2 — Giao việc tính toán chính xác cho LLM. Để AI tính tổng giỏ hàng, tính thuế, đếm số ngày. Nó sẽ sai một cách ngẫu nhiên và khó lường. Mẹo: mọi con số có hậu quả phải do code tính, AI chỉ trình bày.
Lỗi 3 — Bỏ quên hallucination (AI "bịa"). AI luôn trả lời tự tin, kể cả khi sai. Người dùng thường không phân biệt được. Mẹo: với thông tin quan trọng, ràng buộc AI chỉ trả lời dựa trên dữ liệu bạn cung cấp, và hiển thị nguồn. (Bài 16 sẽ dạy sâu cách phát hiện hallucination.)
Lỗi 4 — Quên chi phí vận hành. Mỗi lần gọi API là tiền. Một tính năng "chat tự do" cho 100.000 người dùng có thể đốt hàng trăm triệu đồng/tháng. Mẹo: ước tính chi phí mỗi lượt gọi nhân với lưu lượng trước khi build. (Bài 38 chuyên về quản lý chi phí AI.)
Lỗi 5 — Không có phương án khi AI "sập" hoặc chậm. API bên thứ ba có thể lỗi, chậm, hoặc bị giới hạn. Mẹo: luôn thiết kế trạng thái dự phòng — thông báo lịch sự, hoặc rơi về luồng không-AI.
Mẹo lớn nhất: Hãy nghĩ về AI như một nhân viên thực tập rất giỏi ngôn ngữ nhưng hay tự tin sai và không có trách nhiệm pháp lý. Bạn sẽ giao cho thực tập sinh đó việc gì, và không giao việc gì? Câu trả lời đó chính là ranh giới tính năng AI của bạn.
Bài tập thực hành
- Phân loại use case. Lấy chính sản phẩm bạn đang làm (hoặc một app bạn dùng hằng ngày). Liệt kê 5 tính năng tiềm năng có thể "thêm AI". Với mỗi tính năng, đánh dấu: (a) rule-based có giải được không? (b) mức độ chịu lỗi cao hay thấp? Kết luận tính năng nào thực sự nên dùng AI.
- Viết một-trang đề xuất. Chọn một tính năng AI bạn cho là đáng làm nhất ở bài tập 1. Viết một trang gồm: vấn đề người dùng (không nhắc chữ AI ở đoạn này), lý do AI phù hợp hơn logic thường, kiến trúc chọn (API/RAG/fine-tune), guardrail và đường lui, thước đo "đủ tốt".
- Phản biện ngược. Lấy tình huống fintech ở trên. Liệt kê 3 câu hỏi của khách hàng mà chatbot tuyệt đối không nên tự trả lời, và viết câu "từ chối lịch sự + chuyển hướng" cho mỗi câu.
- Ước tính chi phí thô. Giả sử tính năng của bạn được 20.000 người dùng/ngày, mỗi người gọi AI trung bình 3 lần. Tra giá một mô hình bất kỳ và ước tính chi phí tháng. Con số đó có khiến bạn cân nhắc lại thiết kế không?
Tóm tắt
Xây dựng tính năng AI cho người dùng cuối là một kỹ năng PM khác hẳn với việc dùng AI làm trợ lý cá nhân — vì lúc này lỗi của AI trở thành rủi ro thương hiệu, pháp lý và trải nghiệm của hàng nghìn người không phải chuyên gia.
Bạn không cần biết code, nhưng phải nắm chắc bốn điều: AI làm tốt việc ngôn ngữ, phi cấu trúc, mơ hồ — và làm dở việc tính toán chính xác, nhất quán, hậu quả nặng. Câu hỏi sống còn trước mọi tính năng là "rule-based có giải được không?" — nếu có thì đừng dùng AI. Kiến trúc tốt nhất thường là lai: AI lo ngôn ngữ, code lo sự thật và con số. Và một tính năng AI thành công luôn đi kèm guardrail, đường lui, thước đo chất lượng, dự trù chi phí, cùng vòng phản hồi liên tục.
Hãy nhớ hình ảnh "thực tập sinh giỏi ngôn ngữ nhưng hay tự tin sai": nó sẽ giúp bạn quyết định nhanh việc gì nên — và không nên — giao cho AI. Ở các bài sau, bạn sẽ đào sâu từng mảnh: phát hiện hallucination (Bài 16), guardrail cho dữ liệu nhạy cảm (Bài 37), quản lý chi phí (Bài 38) và viết spec cho tính năng AI (Bài 54).