Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn đang làm discovery cho một tính năng "gợi ý món ăn" trên một app giao đồ ăn. Nếu đây là một tính năng truyền thống — ví dụ một nút "Đặt lại đơn cũ" — bạn validate khá đơn giản: user hiểu nút không, bấm vào có ra đúng đơn cũ không, đúng thì xong. Logic là deterministic: cùng một input luôn cho ra cùng một output, và bạn có thể kiểm tra đúng/sai một cách rạch ròi.
Nhưng "gợi ý món ăn" bằng AI thì khác hoàn toàn. Cùng một user, cùng một thời điểm, mô hình có thể gợi ý phở hôm nay và bún bò hôm sau. Không có khái niệm "đúng tuyệt đối" — chỉ có "đúng đủ tốt trong bao nhiêu phần trăm trường hợp". Và chất lượng gợi ý đó phụ thuộc nặng nề vào dữ liệu lịch sử đặt món mà bạn có. Nếu user mới toanh, chưa có lịch sử, mô hình gần như "mù".
Đây chính là lý do discovery cho sản phẩm AI/ML không thể copy nguyên si quy trình discovery truyền thống. Rất nhiều PM Việt Nam hiện nay đang bị cuốn vào làn sóng AI, hứa với sếp và nhà đầu tư về những tính năng "thông minh", rồi vỡ mộng khi mô hình chạy thật cho ra kết quả lúc hay lúc dở, không kiểm soát được. Bài này dạy bạn cách phát hiện sớm — ngay trong giai đoạn discovery — liệu một ý tưởng AI có khả thi không, dữ liệu có đủ không, và user có thực sự chấp nhận tính chất "lúc đúng lúc sai" của nó hay không. Làm tốt discovery ở đây giúp bạn tránh đốt hàng tỷ đồng vào một mô hình không bao giờ đạt chất lượng dùng được.
Khái niệm cốt lõi
Discovery cho AI/ML vẫn giữ nguyên mục tiêu cốt lõi: hiểu vấn đề của user, validate cơ hội. Nhưng có bốn đặc tính riêng khiến bạn phải thay đổi cách làm.
1. Output stochastic — không deterministic
Sản phẩm truyền thống có hành vi xác định: bạn viết if user bấm A thì hiện B. Sản phẩm ML cho ra output mang tính xác suất (stochastic) — mô hình trả về một dự đoán kèm độ tin cậy, và nó sẽ sai ở một tỷ lệ nào đó. Điều này có hai hệ quả lớn cho discovery:
- Bạn không validate "tính năng có hoạt động không" mà validate "tính năng đúng ở mức nào thì user còn chấp nhận được". Ngưỡng chấp nhận này (gọi là acceptable error rate) phải được khám phá từ user, không phải tự PM quyết.
- Bạn phải khám phá cost của lỗi. Một mô hình gợi ý nhạc gợi sai bài thì user chỉ skip — chi phí lỗi gần như bằng không. Một mô hình duyệt hồ sơ vay tiền dự đoán sai thì có thể từ chối oan một khách hàng tốt, hoặc giải ngân cho người không trả được — chi phí lỗi cực cao. Cùng một độ chính xác 90%, một bên dùng được, một bên là thảm họa.
2. Data dependent — chất lượng mô hình phụ thuộc dữ liệu
Đây là điểm chí mạng mà discovery truyền thống bỏ qua hoàn toàn. Với sản phẩm thường, bạn chỉ cần validate nhu cầu user và khả thi kỹ thuật. Với AI, bạn còn phải validate feasibility của dữ liệu trước khi cam kết bất cứ điều gì. Có ba câu hỏi sống còn:
- Dữ liệu có tồn tại không? Bạn muốn xây mô hình dự đoán user sắp rời bỏ (churn), nhưng công ty mới chạy 4 tháng, chưa đủ chu kỳ churn để mô hình học. Dữ liệu đơn giản là chưa có.
- Dữ liệu có đủ chất lượng không? Dữ liệu bẩn, thiếu nhãn (label), hoặc bị lệch (bias) sẽ cho ra mô hình tệ. "Garbage in, garbage out."
- Dữ liệu có tiếp tục sinh ra không? Mô hình cần được tái huấn luyện. Nếu nguồn dữ liệu là một lần rồi cạn, mô hình sẽ "già" đi và kém dần — gọi là model drift.
3. Hiệu năng không thể hứa trước
Với tính năng truyền thống, bạn cam kết được "tôi sẽ build cái này". Với ML, bạn không thể hứa "mô hình sẽ đạt 95% chính xác" cho đến khi thực sự train thử trên dữ liệu thật. Discovery vì thế phải bao gồm một bước feasibility spike: một thử nghiệm nhỏ, nhanh, train một mô hình thô trên dữ liệu hiện có để ước lượng trần hiệu năng (performance ceiling). Nếu mô hình thô đã cho kết quả tệ thảm, đừng mơ mô hình xịn sẽ cứu được.
4. UX phải thiết kế cho sự không hoàn hảo
Vì mô hình chắc chắn sẽ sai, discovery phải khám phá xem user phản ứng thế nào khi gặp lỗi, và họ cần "lối thoát" gì. Tính năng AI tốt luôn có cơ chế cho user sửa, bỏ qua, hoặc giành lại quyền kiểm soát. Đây là phần mà bạn validate bằng cách quan sát hành vi, không phải hỏi suông.
Tình huống thực tế
Ví dụ 1 — Tiki và bài toán gợi ý sản phẩm
Giả định một đội sản phẩm tại một sàn TMĐT lớn như Tiki muốn xây tính năng "gợi ý sản phẩm cá nhân hóa" trên trang chủ. Ý tưởng nghe rất hấp dẫn: tăng tỷ lệ chuyển đổi bằng AI.
Đội PM ban đầu định nhảy thẳng vào build mô hình deep learning. Nhưng người dẫn dắt discovery yêu cầu làm data audit trước. Họ phát hiện: 60% lượt truy cập trang chủ là từ user mới hoặc chưa đăng nhập — tức là không có lịch sử mua hàng nào để mô hình học. Đây là bài toán cold start kinh điển. Nếu xây mô hình cá nhân hóa phức tạp, nó sẽ "câm" với 60% lưu lượng.
Bài học rút ra: discovery dữ liệu đã cứu họ khỏi sai lầm. Thay vì một mô hình "xịn" chỉ phục vụ 40% user, họ chia bài toán: dùng một logic bán-thông minh (bestseller theo danh mục, theo khu vực) cho user mới, và mô hình cá nhân hóa cho user có lịch sử. Discovery ở đây không phải để xác nhận "AI có cần thiết không" mà để xác nhận dữ liệu có đủ nuôi AI cho đúng nhóm user mục tiêu không.
Ví dụ 2 — Một fintech Việt với mô hình chấm điểm tín dụng
Một công ty fintech (giả định, kiểu MoMo hoặc một ví điện tử cho vay tiêu dùng) muốn xây mô hình ML dự đoán khả năng trả nợ để duyệt khoản vay nhỏ tự động. Ở đây chi phí lỗi cực cao và bất đối xứng: duyệt nhầm một người không trả được tốn tiền thật, từ chối oan một khách tốt thì mất doanh thu và mất uy tín.
Trong discovery, đội đã làm hai việc quan trọng. Thứ nhất, họ phỏng vấn nhân viên thẩm định hiện tại (những người đang làm thủ công) để hiểu họ đang dùng tín hiệu gì để ra quyết định — đây chính là feature discovery cho mô hình. Thứ hai, họ chạy một feasibility spike trên 5.000 hồ sơ lịch sử đã có kết quả trả nợ thực tế. Mô hình thô đạt khoảng 71% — không đủ để tự động duyệt 100%, nhưng đủ để tự động duyệt nhóm "rõ ràng tốt" (chiếm 30% hồ sơ) và đẩy phần còn lại cho người thẩm định.
Bài học: thay vì hỏi "AI có thay được người không", discovery đã định hình lại thành "AI có thể gánh được phần nào của quy trình một cách an toàn". Họ cũng khám phá ngưỡng chấp nhận lỗi: ban lãnh đạo cho biết tỷ lệ nợ xấu chấp nhận được là dưới 3% — đây trở thành tiêu chí pass/fail rõ ràng cho mô hình, được xác định trong discovery chứ không phải sau khi build.
Ví dụ 3 — Chatbot chăm sóc khách hàng và bài học về kỳ vọng
Một startup SaaS Đông Nam Á muốn thay tổng đài bằng chatbot AI trả lời câu hỏi khách hàng. Trong discovery, thay vì build chatbot thật ngay, họ làm một thử nghiệm kiểu "Wizard of Oz" có ý đồ: cho khách chat, nhưng đằng sau là nhân viên thật trả lời, đồng thời ghi lại toàn bộ hội thoại.
Hai phát hiện quan trọng. Một là, có một nhóm câu hỏi lặp đi lặp lại (kiểm tra trạng thái đơn, đổi mật khẩu) chiếm 55% lượng chat — đây là vùng AI làm tốt. Hai là, 20% câu hỏi mang tính khiếu nại cảm xúc, và khi mô phỏng cho khách biết "đây là bot", họ phản ứng tiêu cực rõ rệt, đòi gặp người thật. Đội phát hiện cost của lỗi cảm xúc cao hơn nhiều so với họ tưởng.
Bài học: discovery đã giúp họ định nghĩa ranh giới của AI ngay từ đầu — tự động hóa nhóm câu hỏi giao dịch, và thiết kế cơ chế chuyển người thật mượt mà cho nhóm cảm xúc. Họ cũng học được rằng việc minh bạch "đây là AI" cần được test, không phải mặc định.
Hướng dẫn từng bước
Đây là quy trình discovery tôi khuyên bạn áp dụng cho mọi ý tưởng AI/ML:
- Bắt đầu từ vấn đề, không từ công nghệ. Câu hỏi đầu tiên không phải "ta dùng AI thế nào" mà "user đang đau ở đâu". Nhiều khi giải pháp tốt nhất lại không cần AI. AI phải là phương tiện, không phải mục tiêu.
- Xác định bản chất bài toán ML. Đây là dự đoán (prediction), phân loại (classification), gợi ý (recommendation), hay sinh nội dung (generation)? Mỗi loại có yêu cầu dữ liệu và rủi ro khác nhau.
- Làm data audit. Trả lời ba câu: Dữ liệu có tồn tại không? Đủ chất lượng và đủ lượng không? Có liên tục sinh ra để tái huấn luyện không? Nếu câu trả lời là không cho bất kỳ câu nào, hãy dừng lại và thiết kế cách thu thập dữ liệu trước.
- Khám phá cost của lỗi. Hỏi rõ: nếu mô hình sai, chuyện gì xảy ra với user? Lỗi false positive và false negative có hậu quả khác nhau không? Lỗi nào nghiêm trọng hơn? Điều này định hình cả tiêu chí thành công lẫn UX.
- Định nghĩa ngưỡng chấp nhận cùng user và stakeholder. Mô hình cần đúng bao nhiêu phần trăm thì tính năng còn có giá trị? Con số này phải đến từ thực tế kinh doanh, không phải kỹ thuật.
- Chạy feasibility spike. Train một mô hình thô, nhanh, rẻ trên dữ liệu hiện có để ước lượng trần hiệu năng. Đây là "smoke test" của thế giới AI. So sánh kết quả thô với ngưỡng chấp nhận ở bước 5.
- Validate UX của sự không hoàn hảo. Dùng prototype hoặc Wizard of Oz cho user trải nghiệm cả khi mô hình đúng lẫn khi sai. Quan sát họ phản ứng và cần "lối thoát" gì.
- Quyết định: build, định hình lại, hay dừng. Tổng hợp tín hiệu từ vấn đề, dữ liệu, hiệu năng thô và phản ứng UX để ra quyết định có cơ sở.
Lỗi thường gặp & mẹo
Lỗi 1 — Mê công nghệ, quên vấn đề. Rất nhiều đội bắt đầu bằng "sếp muốn có AI" rồi đi tìm chỗ nhét AI vào. Mẹo: luôn ép bản thân trả lời "nếu bỏ chữ AI ra, vấn đề user còn đáng giải không?". Nếu không, đừng làm.
Lỗi 2 — Bỏ qua data audit. Đây là lỗi đắt nhất. Đội build cả mô hình rồi mới phát hiện dữ liệu không đủ. Mẹo: làm data audit trước khi viết một dòng code mô hình. Coi dữ liệu như một "user" mà bạn phải phỏng vấn.
Lỗi 3 — Đặt kỳ vọng deterministic cho hệ thống stochastic. Hứa với sếp "AI sẽ luôn đúng" là tự đào hố. Mẹo: ngay từ discovery, giáo dục stakeholder rằng mọi mô hình đều có tỷ lệ sai, và việc của discovery là tìm ngưỡng sai chấp nhận được.
Lỗi 4 — Quên cold start và edge case. Mô hình chạy đẹp trên user có nhiều dữ liệu, nhưng "câm" với user mới. Mẹo: trong discovery luôn hỏi "mô hình hành xử thế nào với user/đầu vào chưa từng thấy?".
Lỗi 5 — Validate mô hình bằng metric kỹ thuật mà quên giá trị kinh doanh. Accuracy 95% nghe oai nhưng vô nghĩa nếu lớp quan trọng nhất lại bị đoán sai. Mẹo: luôn dịch metric kỹ thuật sang tác động kinh doanh thật.
Mẹo vàng: Trong AI discovery, hãy ưu tiên các phương pháp "fake the AI before you build it" — Wizard of Oz, Concierge, prototype giả lập output mô hình. Bạn học được phản ứng user thật với chi phí cực thấp, trước khi đầu tư vào hạ tầng ML đắt đỏ.
Bài tập thực hành
Chọn một ý tưởng tính năng AI/ML (của công ty bạn, hoặc giả định một app Việt như gợi ý phim, dự đoán giao hàng trễ, chấm điểm rủi ro). Hoàn thành bản "AI Discovery Canvas" gồm:
- Vấn đề & user: Mô tả nỗi đau của user mà không nhắc đến AI. Nếu không thể, ý tưởng cần xem lại.
- Bản chất bài toán ML: Đây là prediction, classification, recommendation hay generation?
- Data audit: Liệt kê dữ liệu cần có, đánh giá tồn tại / chất lượng / khả năng tái sinh. Ghi rõ rủi ro cold start.
- Cost của lỗi: Mô tả false positive và false negative gây hậu quả gì, lỗi nào nặng hơn.
- Ngưỡng chấp nhận: Mô hình cần đúng bao nhiêu phần trăm để có giá trị? Lấy con số từ logic kinh doanh.
- Thiết kế feasibility spike: Bạn sẽ train thử trên dữ liệu nào, đo bằng metric gì, so với ngưỡng nào?
- Plan validate UX: Bạn sẽ dùng Wizard of Oz hay prototype để test phản ứng user khi mô hình sai như thế nào?
Tóm tắt
Discovery cho sản phẩm AI/ML khác biệt cốt lõi ở bốn điểm: output mang tính xác suất chứ không xác định, chất lượng phụ thuộc nặng vào dữ liệu, hiệu năng không thể hứa trước khi train thử, và UX phải được thiết kế cho sự không hoàn hảo. Vì thế, ngoài việc phỏng vấn user như discovery truyền thống, bạn phải bổ sung ba việc: data audit để kiểm tra tính khả thi dữ liệu, khám phá cost của lỗi để định hình tiêu chí thành công và UX, và feasibility spike để ước lượng trần hiệu năng trước khi cam kết. Quy tắc xuyên suốt: bắt đầu từ vấn đề chứ không từ công nghệ, "phỏng vấn dữ liệu" nghiêm túc như phỏng vấn user, và "giả lập AI trước khi build AI" để học rẻ và nhanh. Làm đúng những điều này, bạn sẽ tránh được sai lầm phổ biến nhất của làn sóng AI hiện nay: đốt tiền vào một mô hình không bao giờ chạm tới ngưỡng dùng được.