Mở đầu — vì sao bài này quan trọng
Nếu Bài 1 giúp bạn hiểu "AI PM là ai và làm gì", thì Bài 2 này trả lời câu hỏi thực tế hơn rất nhiều: "Làm thế nào để xây một sản phẩm AI cho ra hồn, thay vì chỉ gắn một con chatbot lên website rồi tự gọi mình là công ty AI?"
Đây là bài học mà tôi muốn bạn đọc kỹ nhất trong giai đoạn nền tảng, vì nó định hình toàn bộ tư duy của bạn về sau. Trong hai năm gần đây, tôi đã chứng kiến hàng chục đội ngũ ở Việt Nam và khu vực đốt sạch ngân sách quý vào những tính năng AI mà không ai dùng. Lý do gần như luôn giống nhau: họ bắt đầu từ công nghệ chứ không bắt đầu từ vấn đề của người dùng. Họ thấy ChatGPT viral, sếp hỏi "đối thủ có AI rồi, mình đâu?", thế là cả team lao vào "thêm AI" mà chẳng ai dừng lại hỏi: AI ở đây giải quyết nỗi đau cụ thể nào?
Bài này dạy bạn cách tiếp cận ngược lại — và đó là khác biệt giữa một sản phẩm AI tạo ra giá trị thật với một thứ đồ chơi demo đẹp rồi chết yểu. Sau bài này, bạn sẽ có một khung tư duy để quyết định khi nào nên xây tính năng AI, xây cho ai, và xây như thế nào để nó không sụp đổ khi gặp người dùng thật.
Khái niệm cốt lõi
Problem-First, không phải AI-First
Nguyên tắc số một, và nếu bạn chỉ nhớ một điều từ cả bài này thì hãy nhớ điều này:
- Cách sai (AI-First): "Hãy thêm AI vào sản phẩm của chúng ta."
- Cách đúng (Problem-First): "Người dùng đang vật lộn với vấn đề X → AI có thể giải quyết được vì lý do Y."
Nếu bỏ chữ "AI" ra mà tính năng vô nghĩa, thì bạn đang làm AI-First — và đó là dấu hiệu nguy hiểm.
AI có phù hợp với vấn đề này không?
Không phải vấn đề nào cũng nên dùng AI. AI (đặc biệt là các mô hình sinh — generative models) phù hợp nhất khi vấn đề có một hoặc nhiều đặc điểm sau:
- Dữ liệu đầu vào không có cấu trúc: văn bản tự do, hình ảnh, giọng nói, video — những thứ mà if/else truyền thống xử lý rất tệ.
- Không có một câu trả lời "đúng" duy nhất: viết tóm tắt, gợi ý nội dung, phân loại cảm xúc — chấp nhận được nhiều đáp án hợp lý.
- Quy mô lớn đến mức con người không làm xuể: duyệt 100.000 bình luận mỗi ngày để phát hiện nội dung độc hại.
- Cá nhân hóa sâu: mỗi người dùng cần một trải nghiệm khác nhau dựa trên hành vi của họ.
AI là tính năng xác suất, không phải tính năng tất định
Đây là điểm chuyển đổi tư duy quan trọng nhất khi bạn từ PM thường sang AI PM. Phần mềm truyền thống là tất định (deterministic): cùng một đầu vào luôn cho cùng một đầu ra. AI là xác suất (probabilistic): cùng một câu hỏi có thể cho hai câu trả lời khác nhau, và đôi khi sai.
Hệ quả thực tế:
- Bạn không thể hứa "đúng 100%". Bạn phải thiết kế sản phẩm để chấp nhận và xử lý cái sai.
- Trải nghiệm người dùng (UX) phải có cơ chế "thoát hiểm": nút sửa, nút báo sai, khả năng người dùng kiểm chứng kết quả.
- Việc đo lường chất lượng phức tạp hơn nhiều so với "pass/fail" thông thường (chủ đề này ta sẽ đào sâu ở các bài về metrics và evaluation sau).
Định nghĩa thành công TRƯỚC khi xây
Trước khi viết một dòng prompt nào, AI PM phải trả lời được: "Tính năng này thành công nghĩa là gì, đo bằng con số nào?" Nếu bạn không định nghĩa được ngưỡng chấp nhận (ví dụ: "chatbot phải trả lời đúng ít nhất 85% câu hỏi thường gặp, thời gian phản hồi dưới 3 giây"), thì bạn sẽ không bao giờ biết khi nào nên ship, khi nào nên dừng, và khi nào nên quay đầu.
Tình huống thực tế
Ví dụ 1 — Tiki và bài toán review sản phẩm (Problem-First làm đúng)
Giả sử đội sản phẩm của một sàn thương mại điện tử lớn như Tiki nhận thấy một vấn đề rất cụ thể qua dữ liệu: với những sản phẩm best-seller, mỗi mặt hàng có tới 3.000–5.000 đánh giá. Người mua than phiền họ "không có thời gian đọc hết", còn dữ liệu hành vi cho thấy 68% người dùng bỏ trang ở khu vực review mà chưa cuộn hết.
Đây là một bài toán Problem-First chuẩn mực:
- Vấn đề X: người mua bị quá tải thông tin, không rút được kết luận từ hàng nghìn review.
- Vì sao AI giải được (Y): dữ liệu là văn bản tự do, không có câu trả lời đúng duy nhất, quy mô quá lớn cho con người — đúng "vùng đất" của AI.
Bài học rút ra: họ không bắt đầu từ "ta phải có AI tóm tắt". Họ bắt đầu từ một nỗi đau đo được, rồi mới chọn AI làm công cụ. Và họ gắn tính năng với một metric kinh doanh, không phải với độ "ngầu" của công nghệ.
Ví dụ 2 — Startup fintech "thêm AI" vì sợ tụt hậu (AI-First làm sai)
Một startup fintech giả định ở TP.HCM gọi vốn vòng seed thành công. Nhà đầu tư trong buổi review hỏi: "Sao chưa thấy AI đâu?" Hôm sau, CEO yêu cầu team gắn một AI chatbot "tư vấn tài chính cá nhân" lên app trong 6 tuần.
Vấn đề: không ai định nghĩa được người dùng đang vật lộn với điều gì. Họ chỉ biết "cần có AI". Kết quả sau 3 tháng:
- Chatbot trả lời chung chung, đôi khi đưa lời khuyên tài chính sai — một rủi ro pháp lý cực lớn trong lĩnh vực tiền bạc.
- Chỉ 4% người dùng từng mở chatbot, và trong số đó hơn một nửa không quay lại lần hai.
- Chi phí token mỗi tháng đội lên vài nghìn USD trong khi không tạo ra doanh thu hay giữ chân được ai.
Ví dụ 3 — Grab và xử lý khiếu nại tự động (chấp nhận tính xác suất)
Grab giả định triển khai một hệ thống AI phân loại và xử lý sơ bộ hàng triệu khiếu nại từ tài xế và khách hàng mỗi tháng. Vì là bài toán xác suất, đội ngũ thiết kế rất khôn ngoan: AI không tự đóng case, mà chỉ phân loại ("hoàn tiền", "tranh chấp lộ trình", "thái độ tài xế") và đề xuất phương án. Những case AI tự tin cao (confidence trên ngưỡng) được xử lý tự động; những case mơ hồ được đẩy sang nhân viên.
Kết quả: 60% khiếu nại đơn giản được giải quyết tự động trong vài giây, nhân viên tập trung vào 40% case khó. Quan trọng hơn, vì họ chấp nhận rằng AI có thể sai, họ thiết kế sẵn cơ chế con người giám sát (human-in-the-loop) thay vì giao trọn quyền cho máy.
Bài học rút ra: sản phẩm AI tốt không cố che giấu sự không hoàn hảo của mô hình — nó thiết kế xoay quanh sự không hoàn hảo đó. Đặt AI ở vai trò "trợ lý đề xuất" thay vì "người quyết định cuối cùng" là một mẫu thiết kế an toàn và hiệu quả ở giai đoạn đầu.
Hướng dẫn từng bước
Đây là quy trình tôi khuyên bạn áp dụng mỗi khi đứng trước một ý tưởng "thêm AI":
- Viết phát biểu vấn đề trước khi nhắc tới AI. Hoàn thành câu: "Người dùng [ai] đang gặp khó khăn với [vấn đề gì], dẫn đến [hậu quả đo được nào]." Nếu bạn không điền nổi câu này bằng dữ liệu thật, hãy dừng lại — bạn chưa sẵn sàng.
- Kiểm tra "AI có phù hợp không". Đối chiếu vấn đề với bốn đặc điểm ở phần khái niệm (dữ liệu phi cấu trúc / không có đáp án duy nhất / quy mô lớn / cần cá nhân hóa). Nếu không trúng đặc điểm nào, khả năng cao một giải pháp không-AI sẽ rẻ và tốt hơn.
- Định nghĩa thành công bằng con số. Xác định một metric chính (north star nhỏ cho tính năng) và một ngưỡng chất lượng tối thiểu để được phép ship. Ví dụ: "giảm thời gian xử lý ticket trung bình từ 8 phút xuống 3 phút, độ chính xác phân loại ≥ 90%".
- Phác thảo trải nghiệm cho cả trường hợp AI SAI. Trước khi nghĩ tới mô hình nào, hãy vẽ ra: người dùng làm gì khi AI trả lời sai? Có nút sửa không? Có hiển thị độ tin cậy không? Có lối thoát về quy trình thủ công không? Đây là phần phân biệt amateur với chuyên nghiệp.
- Làm bản thử rẻ nhất có thể (thin slice). Đừng xây cả hệ thống. Hãy thử nghiệm trên một tập nhỏ (ví dụ một danh mục sản phẩm, một nhóm 100 người dùng) với cấu hình đơn giản nhất — thường chỉ là gọi một foundation model có sẵn qua API kèm prompt. Mục tiêu là kiểm chứng giả thuyết, không phải xây thành phẩm.
- Đo, học, rồi quyết định mở rộng hay quay đầu. So kết quả thực tế với ngưỡng ở bước 3. Nếu đạt, mở rộng dần. Nếu không đạt, đừng cố đấm ăn xôi — phân tích vì sao và sẵn sàng kết luận "AI không phải lời giải cho bài toán này".
Lỗi thường gặp & mẹo
Lỗi 1 — Bắt đầu từ công nghệ. "Mình vừa đọc về RAG, hãy tìm chỗ nào nhét RAG vào." Đây là AI-First trá hình. Mẹo: luôn để vấn đề dẫn dắt công nghệ, không bao giờ ngược lại.
Lỗi 2 — Hứa độ chính xác tuyệt đối. Marketing thích nói "AI của chúng tôi luôn đúng". Điều này tạo kỳ vọng mà sản phẩm xác suất không thể đáp ứng, và mỗi lần AI sai sẽ phá hủy niềm tin. Mẹo: định vị AI là "trợ lý giúp bạn nhanh hơn", không phải "thần thánh không bao giờ sai".
Lỗi 3 — Bỏ quên trường hợp thất bại. Demo lúc nào cũng đẹp vì người ta chọn input dễ. Người dùng thật sẽ gõ những thứ kỳ quặc nhất. Mẹo: dành ít nhất 30% công sức thiết kế cho "khi AI sai thì sao", không chỉ cho "happy path".
Lỗi 4 — Không có baseline để so sánh. Bạn không biết AI tốt hơn nếu không biết "không AI thì kết quả thế nào". Mẹo: luôn đo trạng thái hiện tại (quy trình thủ công, hoặc giải pháp đơn giản không-AI) làm mốc.
Lỗi 5 — Đánh đồng "demo chạy được" với "sản phẩm sẵn sàng". Khoảng cách giữa demo và production trong AI lớn hơn nhiều so với phần mềm thường, vì còn chuyện chi phí token, độ trễ, tính nhất quán và rủi ro nội dung sai. Mẹo: coi demo chỉ là bằng chứng giả thuyết, chưa phải vạch đích.
Mẹo vàng: mỗi khi ai đó đề xuất một tính năng AI, hãy hỏi câu này trong cuộc họp — "Nếu ta xóa chữ AI khỏi mô tả, tính năng này còn giải quyết vấn đề gì không?" Câu hỏi đơn giản đó đã cứu rất nhiều đội ngũ khỏi việc lãng phí cả quý.
Bài tập thực hành
Bài tập 1 — Lật ngược một ý tưởng AI-First. Lấy một ý tưởng kiểu "thêm AI vào sản phẩm" (của công ty bạn, hoặc tự nghĩ ra). Viết lại nó theo công thức Problem-First: "Người dùng [ai] đang vật lộn với [X], dẫn đến [hậu quả đo được]. AI giải được vì [Y]." Nếu bạn không điền nổi phần Y một cách thuyết phục, hãy ghi lại lý do — đó chính là bài học.
Bài tập 2 — Bảng kiểm "AI có phù hợp không". Chọn ba tính năng có thật trong một app bạn hay dùng (ví dụ: Shopee, MoMo, ZaloPay). Với mỗi tính năng, đánh giá xem nó có nên dùng AI không, dựa trên bốn đặc điểm đã học (dữ liệu phi cấu trúc / không có đáp án duy nhất / quy mô lớn / cần cá nhân hóa). Giải thích lựa chọn của bạn trong 2–3 câu mỗi tính năng.
Bài tập 3 — Thiết kế cho trường hợp sai. Với ý tưởng AI bạn vừa viết ở Bài tập 1, hãy phác thảo (bằng lời hoặc vẽ tay) trải nghiệm người dùng khi AI trả lời sai. Trả lời ba câu hỏi: (1) Người dùng nhận ra AI sai bằng cách nào? (2) Họ sửa hoặc thoát ra sao? (3) Hệ thống học được gì từ cái sai đó? Đây là kỹ năng phân biệt AI PM nghiệp dư và chuyên nghiệp.
Tóm tắt
- Problem-First, không phải AI-First: luôn bắt đầu từ nỗi đau đo được của người dùng, rồi mới chọn AI làm công cụ. Phép thử nhanh: xóa chữ "AI" đi, tính năng còn ý nghĩa không?
- AI không phù hợp với mọi vấn đề. Nó mạnh ở dữ liệu phi cấu trúc, bài toán không có đáp án duy nhất, quy mô lớn và cần cá nhân hóa. Với bài toán có quy tắc rõ ràng cần độ chính xác tuyệt đối, hãy dùng giải pháp truyền thống.
- AI là tính năng xác suất, không tất định. Sản phẩm tốt được thiết kế để chấp nhận và xử lý cái sai, không cố giả vờ AI luôn đúng. Đặt con người vào vòng lặp khi rủi ro cao.
- Định nghĩa thành công bằng con số trước khi xây, và luôn có baseline để so sánh.
- Quy trình sáu bước: phát biểu vấn đề → kiểm tra độ phù hợp → định nghĩa metric → thiết kế cho trường hợp sai → thử lát mỏng rẻ nhất → đo và quyết định.