Mở đầu — vì sao bài này quan trọng
Năm 2023–2025, gần như mọi đội sản phẩm ở Việt Nam đều bị cuốn vào cơn sốt AI. Sếp xuống yêu cầu "thêm AI vào", nhà đầu tư hỏi "chiến lược AI của em đâu", và đối thủ vừa tung ra một con chatbot trên website. Trong áp lực đó, rất nhiều PM nhảy thẳng vào xây tính năng AI mà bỏ qua bước discovery — và đó là lúc tiền và thời gian bốc hơi nhanh nhất.
Vấn đề cốt lõi: discovery cho tính năng AI/LLM không giống discovery cho tính năng truyền thống. Khi bạn làm discovery cho một nút "Export PDF", người dùng biết rõ họ muốn gì và bạn dễ dàng hỏi về job của họ. Nhưng với AI, có ba điều đặc thù phá vỡ phần lớn quy trình discovery thông thường mà bạn đã học ở các bài trước:
- Người dùng thường không biết họ muốn AI — họ chỉ biết họ có một nỗi đau, chứ không nghĩ "à, mình cần một mô hình ngôn ngữ lớn".
- Niềm tin và hallucination — AI có thể bịa ra thông tin sai một cách rất tự tin. Đây là một rủi ro về niềm tin mà các tính năng deterministic (luôn cho kết quả đúng) không có.
- Mental model mới — người dùng quen click chuột, giờ phải học cách "ra lệnh bằng chữ" (prompt). Đây là một sự thay đổi hành vi lớn mà discovery phải nắm bắt.
Khái niệm cốt lõi
Đặc thù 1: Người dùng không tự nói ra rằng họ muốn AI
Đây là cái bẫy lớn nhất. Nếu bạn đi phỏng vấn và hỏi "Anh/chị có muốn một trợ lý AI không?", gần như ai cũng gật đầu — vì AI đang là từ khóa thời thượng, từ chối nghe có vẻ "lạc hậu". Câu trả lời đó vô giá trị (vi phạm thẳng The Mom Test mà bạn học ở Bài 2 và 13).
Nguyên tắc: AI là giải pháp, không phải job. Người dùng có một job-to-be-done (ví dụ: "soạn nhanh một email phản hồi khách hàng đang giận dữ"). AI chỉ là một trong nhiều cách giải job đó. Nhiệm vụ discovery là tìm ra job và mức độ đau của job, chứ không phải đi xác nhận rằng "AI hay đấy".
Điều này nghĩa là khi làm discovery cho AI, bạn vẫn dùng JTBD và switch story (Bài 4, 16) như bình thường — nhưng phải kỷ luật hơn trong việc không gợi ý từ "AI" trong câu hỏi. Để người dùng tự kể về workaround hiện tại của họ. Nếu workaround đó là copy-paste vào ChatGPT, hoặc thuê freelancer, hoặc làm thủ công 2 tiếng — đó mới là tín hiệu thật về job.
Đặc thù 2: Niềm tin, hallucination và "chi phí của sai sót"
Tính năng AI sinh ra (generative) có một thuộc tính nguy hiểm: nó có thể sai mà vẫn trông rất thuyết phục. Trong discovery, bạn phải đo một thứ mà tính năng truyền thống không cần đo: chi phí của một câu trả lời sai (cost of error) và ngưỡng tin tưởng (trust threshold) của người dùng trong từng ngữ cảnh.
Có hai loại bối cảnh:
- Bối cảnh khoan dung với lỗi (error-tolerant): viết nháp một caption Facebook, gợi ý ý tưởng brainstorm. Sai một chút không sao, người dùng tự sửa. AI lên ngôi ở đây.
- Bối cảnh không khoan dung với lỗi (error-intolerant): tư vấn liều thuốc, tính toán số tiền chuyển khoản, trích dẫn điều luật. Một lỗi = mất niềm tin vĩnh viễn hoặc hậu quả pháp lý.
Đặc thù 3: Mental model mới — prompt thay vì click
Với UI truyền thống, người dùng nhìn thấy các nút và biết hệ thống làm được gì (affordance rõ ràng). Với giao diện AI dạng chat/prompt, màn hình trống trơn — người dùng không biết nên gõ gì, gõ thế nào, và hệ thống có hiểu không. Đây gọi là vấn đề "blank canvas" (trang giấy trắng).
Discovery cho AI vì thế phải nghiên cứu thêm một lớp mà các bài trước không nhấn mạnh: người dùng diễn đạt ý định của họ như thế nào bằng ngôn ngữ tự nhiên? Họ dùng từ gì? Họ kỳ vọng AI hiểu được tới đâu? Khi AI hiểu sai, họ phản ứng ra sao — sửa lại prompt hay bỏ cuộc luôn?
Bộ công cụ discovery điều chỉnh cho AI
Tóm lại, ba kỹ thuật discovery riêng cho AI mà bạn nên thêm vào quy trình:
- "Wizard of Oz" sớm (sẽ học sâu ở Bài 49): cho người dùng tương tác với một "AI" mà thực ra là con người trả lời phía sau, để quan sát mental model và prompt thật của họ — trước khi tốn tiền build mô hình.
- Thu thập prompt thật: thay vì hỏi "anh muốn AI làm gì", hãy đưa cho họ một ô trống và bảo "anh thử gõ vào đây thứ anh muốn nó làm". Cách họ gõ tiết lộ rất nhiều.
- Đo ngưỡng tin tưởng: hỏi "nếu nó sai 1 trong 10 lần thì anh còn dùng không? 1 trong 100 thì sao?" để định lượng trust threshold cho từng use case.
Tình huống thực tế
Ví dụ 1: Fintech ví điện tử ở Việt Nam — "trợ lý chi tiêu AI"
Một ví điện tử (gọi là MoMoPay, giả định, ~5 triệu user hoạt động hàng tháng) muốn ra mắt "trợ lý tài chính AI" trả lời câu hỏi như "Tháng này tôi tiêu nhiều vào đâu?". Đội ban đầu định build thẳng chatbot.
PM dừng lại làm discovery 12 buổi phỏng vấn. Cô không hỏi "anh có muốn trợ lý AI không". Thay vào đó dùng switch story: "Lần gần nhất anh muốn biết mình tiêu tiền vào đâu, anh đã làm gì?". Kết quả: đa số người dùng tự cuộn lịch sử giao dịch, cộng nhẩm — mất 5–10 phút và thường bỏ cuộc. Job thật rất rõ và đau.
Nhưng phần quan trọng nằm ở đặc thù AI: khi cô đưa cho 12 người một ô chat trống (Wizard of Oz, cô tự trả lời phía sau), 9/12 người gõ những câu rất ngắn và mơ hồ kiểu "tiền", "tháng này", hoặc thậm chí gõ số tài khoản. Họ không biết phải prompt thế nào. Và khi cô (giả làm AI) cố tình trả lời sai một con số, 11/12 người lập tức nói "thế thì tôi không tin app này nữa, tiền bạc mà sai là chết". Cost of error cực cao.
Bài học: Job có thật và đau, nhưng giao diện chat tự do là sai. Đội pivot sang giao diện gợi ý có cấu trúc (các nút "Chi tiêu tháng này", "So với tháng trước") thay vì ô prompt trống, và mọi con số đều dẫn link tới giao dịch gốc để người dùng tự kiểm chứng — giải quyết cả vấn đề mental model lẫn vấn đề niềm tin. Tỷ lệ dùng thật cao gấp nhiều lần so với prototype chatbot ban đầu.
Ví dụ 2: SaaS chăm sóc khách hàng — AI soạn câu trả lời cho agent
Một startup SaaS Đông Nam Á làm phần mềm CSKH cho các shop thương mại điện tử. Họ muốn thêm tính năng AI tự soạn câu trả lời cho nhân viên trực chat. Giả định ROI rất hấp dẫn: tiết kiệm thời gian gõ.
Discovery hé lộ một điều bất ngờ. Khi phỏng vấn 8 trưởng nhóm CSKH, PM đo ngưỡng tin tưởng bằng câu hỏi: "Nếu AI soạn sẵn câu trả lời, anh chị muốn nó tự gửi luôn hay để nhân viên duyệt?". 8/8 người đều nói phải để nhân viên duyệt — vì một câu trả lời sai về chính sách đổi trả có thể khiến shop mất khách và bị review 1 sao. Đây là bối cảnh error-intolerant.
Quan trọng hơn, qua quan sát thực địa (field observation), PM phát hiện nỗi đau thật không phải "gõ chậm" mà là nhân viên mới không biết chính sách của shop nên trả lời sai. Tức là job thật là "trả lời đúng chính sách", không phải "trả lời nhanh".
Bài học: Giải pháp đúng không phải "AI tự động trả lời" mà là "AI gợi ý câu trả lời dựa trên chính sách của chính shop đó (RAG), luôn để con người bấm gửi". Discovery đã ngăn đội xây một tính năng auto-reply nguy hiểm và chỉ đúng được một nửa job.
Ví dụ 3: Cái bẫy "demo lung linh" của một edtech
Một edtech Việt Nam build tính năng "AI chấm bài luận tiếng Anh" cho học sinh. Demo nội bộ rất ấn tượng, sếp duyệt ngay. Nhưng họ bỏ qua discovery về niềm tin.
Khi ra mắt, học sinh dùng vài lần rồi bỏ. Phỏng vấn hậu kỳ (đáng lẽ phải làm trước) cho thấy: học sinh không tin điểm số AI vì nó không giải thích vì sao trừ điểm, và đôi khi chấm câu đúng thành sai (hallucination). Phụ huynh thì sợ con học sai theo AI.
Bài học: Một demo "wow" che giấu vấn đề niềm tin và hallucination. Nếu đội làm discovery về trust threshold trước, họ đã biết phải đầu tư vào phần giải thích (explainability) — chỉ rõ lỗi ở câu nào, vì sao — thay vì chỉ phun ra một con điểm. Niềm tin, chứ không phải độ chính xác của mô hình, mới là yếu tố quyết định adoption.
Hướng dẫn từng bước
Bước 1 — Bắt đầu từ job, cấm nhắc từ "AI". Dùng switch story và mom test để tìm job thật và workaround hiện tại. Tự đặt luật cho mình: trong toàn bộ buổi phỏng vấn không được nói chữ "AI", "chatbot", "tự động". Để người dùng tự kể.
Bước 2 — Xác định bối cảnh error-tolerant hay error-intolerant. Hỏi về hậu quả của một kết quả sai trong job đó. Đây quyết định toàn bộ thiết kế sau này (có cần human-in-the-loop không).
Bước 3 — Đo ngưỡng tin tưởng (trust threshold). Hỏi định lượng: "Sai bao nhiêu phần trăm thì anh ngừng dùng?", "Anh cần thấy gì để tin kết quả này?". Ghi lại con số cụ thể cho từng use case.
Bước 4 — Chạy Wizard of Oz để bắt mental model và prompt thật. Đưa người dùng một ô trống (hoặc một prototype giả), con người trả lời phía sau. Quan sát họ gõ gì, mong đợi gì, phản ứng ra sao khi sai. Đây là dữ liệu vàng cho thiết kế giao diện.
Bước 5 — Phân loại nhu cầu giải thích (explainability). Người dùng cần biết "vì sao AI ra kết quả này" tới mức nào? Cần dẫn nguồn không? Cần cho phép họ kiểm chứng không?
Bước 6 — Tổng hợp vào Opportunity Solution Tree. Đặt job/opportunity ở trên, rồi cân nhắc cả giải pháp AI lẫn non-AI dưới mỗi opportunity. Đừng mặc định AI là nhánh duy nhất — đôi khi một nút bấm thông minh giải job tốt hơn một LLM tốn kém.
Bước 7 — Quyết định mức độ tự động (automation level). Dựa trên cost of error + trust threshold, chọn một trong: AI gợi ý (con người quyết), AI làm rồi con người duyệt, hay AI tự động hoàn toàn. Ghi rõ lý do từ dữ liệu discovery.
Lỗi thường gặp & mẹo
Lỗi 1: Hỏi "anh có muốn AI không". Câu hỏi mồi điển hình, ai cũng gật. Mẹo: cấm tuyệt đối từ "AI" trong phỏng vấn discovery, chỉ hỏi về job và workaround.
Lỗi 2: Bị demo lừa. Một demo cherry-pick vài kết quả đẹp che giấu hallucination và vấn đề niềm tin. Mẹo: discovery phải đo trust threshold trước khi build, và luôn test với các trường hợp AI trả lời sai.
Lỗi 3: Bỏ qua mental model, ném cho người dùng một ô chat trống. Người dùng không biết prompt gì rồi bỏ. Mẹo: Wizard of Oz sớm để xem họ thật sự gõ gì; cân nhắc giao diện có cấu trúc (nút gợi ý) thay vì prompt tự do.
Lỗi 4: Coi AI là job thay vì giải pháp. Dẫn tới xây "AI cho có". Mẹo: trên OST, luôn để cả giải pháp non-AI cạnh tranh với giải pháp AI dưới cùng một opportunity.
Lỗi 5: Đánh đồng "mô hình chính xác hơn" với "người dùng tin hơn". Hai thứ khác nhau. Mẹo: discovery về explainability — đôi khi giải thích lý do quan trọng hơn tăng độ chính xác.
Lỗi 6: Bỏ qua cost of error theo ngữ cảnh. Cùng một AI nhưng đúng cho viết caption, sai cho tư vấn tài chính. Mẹo: phân loại error-tolerant vs intolerant cho từng use case riêng.
Mẹo cộng thêm: Khi phỏng vấn về AI, hãy luôn test cả tình huống "AI sai" trong prototype, không chỉ tình huống "AI đúng". Phản ứng của người dùng khi gặp lỗi mới là dữ liệu quan trọng nhất quyết định adoption dài hạn.
Bài tập thực hành
- Chọn một tính năng AI mà đội bạn (hoặc một sản phẩm bạn biết) đang muốn làm. Viết ra job-to-be-done thật đứng sau nó — không được dùng chữ "AI" trong câu mô tả job.
- Soạn 6 câu hỏi phỏng vấn tuân thủ mom test, trong đó: 2 câu về workaround hiện tại (switch story), 2 câu đo cost of error, 2 câu đo trust threshold (có con số định lượng). Tự kiểm tra: có câu nào mồi chữ "AI" không? Nếu có, sửa lại.
- Thiết kế một thử nghiệm Wizard of Oz đơn giản: bạn sẽ đưa người dùng cái gì, bạn (đóng vai AI) trả lời thế nào, và bạn sẽ cố tình trả lời sai ở điểm nào để quan sát phản ứng. Viết ra kịch bản 1 trang.
- Phân loại error context: liệt kê 3 use case của tính năng AI bạn chọn, đánh dấu mỗi cái là error-tolerant hay error-intolerant, và đề xuất mức automation phù hợp (gợi ý / duyệt / tự động) kèm lý do.
- (Nâng cao) Vẽ một nhánh Opportunity Solution Tree cho job ở bài 1, trong đó đặt ít nhất 1 giải pháp AI và 1 giải pháp non-AI cạnh tranh nhau dưới cùng một opportunity. Bạn sẽ chạy thử nghiệm gì để biết nên chọn nhánh nào?
Tóm tắt
Discovery cho tính năng AI/LLM dùng chung bộ công cụ bạn đã học (mom test, JTBD, switch story, OST), nhưng có ba điều đặc thù bắt buộc phải xử lý:
- Người dùng không tự nói họ muốn AI — AI là giải pháp, không phải job. Cấm nhắc từ "AI" khi phỏng vấn, để người dùng tự kể workaround thật.
- Niềm tin và hallucination — phải đo cost of error và trust threshold cho từng ngữ cảnh; phân loại error-tolerant vs error-intolerant để quyết định mức human-in-the-loop và nhu cầu giải thích (explainability).
- Mental model mới (prompt vs click) — dùng Wizard of Oz sớm để bắt cách người dùng diễn đạt ý định và phản ứng khi AI sai; cân nhắc giao diện có cấu trúc thay vì ô prompt trống.