Mở đầu — vì sao bài này quan trọng
Có một sự thật khó chịu mà mọi AI Product Manager sớm muộn cũng phải đối mặt: phần lớn người dùng của bạn không hề biết họ cần AI, và càng không biết AI có thể giải quyết vấn đề gì cho họ. Họ chỉ biết họ đang khó chịu, đang mất thời gian, đang phải làm những việc lặp đi lặp lại — nhưng họ không thể tự gọi tên giải pháp.
Đây là điểm khác biệt căn bản giữa làm sản phẩm AI và làm sản phẩm phần mềm truyền thống. Với một tính năng thông thường, user thường mô tả khá rõ thứ họ muốn: "tôi muốn nút xuất file Excel", "tôi muốn lọc đơn hàng theo ngày". Còn với AI, nếu bạn hỏi "bạn muốn AI làm gì cho bạn?", câu trả lời thường là sự im lặng, hoặc tệ hơn — một mong muốn viển vông kiểu "tôi muốn một con AI tự động làm hết mọi việc".
Bài học hôm nay tập trung vào kỹ năng discovery (khám phá nhu cầu) dành riêng cho bối cảnh AI: làm sao để đào ra được những use case thật sự có giá trị từ chính người dùng, trong khi họ còn chưa hình dung nổi AI là gì. Đây là kỹ năng nền tảng — vì nếu bạn chọn sai bài toán ngay từ đầu, mọi công sức về RAG, prompt engineering, hay model selection ở các bài sau đều trở nên vô nghĩa. Build đúng cái không ai cần thì còn nguy hiểm hơn build sai cái có người cần.
Khái niệm cốt lõi
"Faster horse" problem — bẫy của giải pháp đã biết
Câu nói gắn với Henry Ford (dù có thể ông không nói y nguyên) tóm gọn vấn đề: "Nếu tôi hỏi khách hàng họ muốn gì, họ sẽ trả lời: một con ngựa chạy nhanh hơn." Khách hàng mô tả giải pháp họ đã biết (con ngựa nhanh hơn), chứ không mô tả công việc thật sự họ cần hoàn thành (đi từ A đến B nhanh và đỡ mệt hơn).
Trong AI, bẫy này còn nặng hơn. User thường nói:
- "Tôi muốn một chatbot" — nhưng cái họ cần là giảm thời gian chờ trả lời câu hỏi lặp lại.
- "Tôi muốn AI viết content tự động" — nhưng cái họ cần là không phải ngồi nhìn màn hình trắng mỗi sáng.
- "Tôi muốn AI dự đoán doanh số" — nhưng cái họ cần là biết tuần sau nên nhập bao nhiêu hàng để khỏi tồn kho.
Hai loại user và hai kiểu sai lệch
Khi làm discovery cho AI, bạn sẽ gặp hai nhóm user với hai kiểu sai lệch ngược nhau:
Nhóm chưa từng tiếp xúc AI — họ underestimate. Họ không tưởng tượng nổi AI có thể đọc hiểu một email lộn xộn rồi tự phân loại, nên họ không bao giờ đề xuất việc đó. Với nhóm này, bạn phải quan sát công việc thực tế của họ và tự nhận ra cơ hội, vì họ sẽ không nói ra.
Nhóm vừa mới biết ChatGPT — họ overestimate. Họ nghĩ AI là phép màu, đòi AI "tự động xử lý toàn bộ quy trình kế toán không cần con người". Với nhóm này, nhiệm vụ của bạn là kéo kỳ vọng về thực tế và tìm phần đáng giá nhưng khả thi để bắt đầu.
Phân biệt "pain" thật và "pain" giả
Một use case chỉ đáng làm khi nó chạm vào một pain point đủ lớn, đủ thường xuyên. PM giỏi luôn kiểm tra ba tín hiệu:
- Tần suất — việc này xảy ra mỗi ngày hay mỗi quý? AI tự động hóa một việc làm mỗi ngày sẽ tạo giá trị gấp bội.
- Mức độ đau — user có đang phải làm thủ công cực nhọc, hay chỉ hơi bất tiện?
- Bằng chứng hành vi — họ có đang tự chế ra giải pháp tạm (workaround) không? Người dùng copy-paste dữ liệu sang Google Sheet để tự xử lý, hay lập một file Word mẫu để đỡ phải viết lại — đó là vàng. Workaround là dấu hiệu mạnh nhất của một nhu cầu thật, vì user đã bỏ công sức để tự giải quyết.
Phân biệt AI-shaped problem và non-AI problem
Không phải pain point nào cũng nên giải bằng AI. Trong lúc discovery, hãy âm thầm gắn nhãn: vấn đề này có đặc tính của AI không? Đặc tính AI-shaped điển hình là: đầu vào lộn xộn, ngôn ngữ tự nhiên, nhiều biến thể; cần hiểu ngữ nghĩa chứ không phải so khớp chính xác; chấp nhận được câu trả lời gần đúng. (Khi nào nên và không nên dùng AI là chủ đề riêng của Bài 6 — ở đây bạn chỉ cần đủ nhạy để không bỏ sót cơ hội AI lẫn không nhồi AI vào chỗ một câu lệnh SQL giải quyết được.)
Tình huống thực tế
Ví dụ 1 — Sàn TMĐT nội địa và "con chatbot" hớ hênh
Một sàn thương mại điện tử tầm trung ở Việt Nam (giả định, quy mô khoảng 2.000 nhà bán) tới gặp team product với yêu cầu rõ ràng: "Làm cho chúng tôi một chatbot AI trả lời khách hàng." Ban lãnh đạo đã chốt ngân sách, thậm chí đặt deadline.
Thay vì lao vào build, PM dành một tuần ngồi cùng đội chăm sóc khách hàng (CSKH) và đọc 500 đoạn chat gần nhất. Phát hiện bất ngờ: 68% câu hỏi của khách không phải là câu hỏi cần "trò chuyện", mà là "đơn của tôi tới đâu rồi?" Khách không cần một con chatbot thông minh — họ cần biết tình trạng đơn hàng ngay lập tức mà không phải chờ nhân viên.
Bài học rút ra: underlying job ở đây là "giảm lo lắng về đơn hàng", không phải "có một con AI biết nói chuyện". Giải pháp tối ưu hóa ra đơn giản hơn nhiều — một widget tra cứu trạng thái đơn tự động, kèm AI chỉ để hiểu câu hỏi diễn đạt lung tung của khách ("hàng em sao lâu thế", "mã ABC123 giờ ở đâu"). Chi phí thấp hơn dự kiến, và chỉ số chờ trả lời giảm rõ rệt. Nếu PM nghe lời "làm chatbot" theo nghĩa đen, họ đã đốt ngân sách vào một con bot trả lời tự do — vừa tốn token, vừa dễ trả lời sai, lại không chạm đúng nỗi đau.
Ví dụ 2 — Phòng khám tư và cái workaround lộ ra nhu cầu
Một chuỗi phòng khám nhỏ ở TP.HCM than phiền chung chung: "Công việc giấy tờ nhiều quá." Đây là kiểu phàn nàn mơ hồ, không thể build gì từ đó. PM áp dụng kỹ thuật đi theo workaround: hỏi cụ thể "một ngày của chị mất thời gian nhất ở khâu nào?" và xin được xem tận mắt.
Hóa ra mỗi lễ tân đang giữ một file Excel tự chế để gõ lại thông tin bệnh nhân từ phiếu khám viết tay sang hệ thống — mỗi phiếu mất 3-4 phút, mỗi ngày khoảng 80 phiếu mỗi chi nhánh. Cái file Excel tự chế đó chính là bằng chứng hành vi của một pain thật, lặp lại hằng ngày, với đầu vào lộn xộn (chữ viết tay) — một bài toán cực kỳ AI-shaped.
Bài học rút ra: user mô tả triệu chứng ("giấy tờ nhiều"), nhưng cái workaround tự chế mới chỉ đúng vị trí cơn đau. Use case rõ ràng nổi lên: dùng AI trích xuất thông tin từ ảnh chụp phiếu khám, lễ tân chỉ cần xác nhận thay vì gõ lại. Tiết kiệm ước tính hơn 4 giờ công mỗi chi nhánh mỗi ngày. Quan trọng hơn: nhu cầu này do quan sát mà ra, user không hề tự đề xuất "dùng AI đọc chữ viết tay" — vì họ thuộc nhóm underestimate, không biết AI làm được điều đó.
Ví dụ 3 — Startup edtech và kỳ vọng AI "phép màu"
Một startup edtech Đông Nam Á (giả định) có nhà sáng lập vừa mê ChatGPT. Anh ấy yêu cầu: "Làm một AI gia sư tự động dạy toàn bộ chương trình, thay thế giáo viên." Đây là điển hình của nhóm overestimate.
PM không phản bác trực diện mà dùng kỹ thuật thu hẹp về khoảnh khắc cụ thể: "Khi nào học viên bỏ học nhiều nhất?" Dữ liệu cho thấy học viên rớt mạnh ở những bài tập khó, lúc nửa đêm, khi không có ai giải đáp thắc mắc tức thời. Đó mới là khoảnh khắc đáng giá.
Bài học rút ra: thay vì "thay thế giáo viên" (vừa bất khả thi về chất lượng, vừa rủi ro về niềm tin), use case khả thi và sắc bén là một trợ lý giải đáp tức thời cho bài tập, hoạt động 24/7, với giáo viên người vẫn phụ trách phần dạy chính. Kéo được kỳ vọng từ "phép màu thay thế con người" về "lấp đúng một khoảng trống cụ thể" chính là giá trị của discovery. Bắt đầu nhỏ, đúng chỗ đau, rồi mở rộng.
Hướng dẫn từng bước
Đây là quy trình discovery AI use case bạn có thể áp dụng ngay:
Bước 1 — Lập danh sách giả định, đừng lập danh sách giải pháp. Trước khi gặp user, viết ra các giả định: bạn nghĩ nỗi đau của họ là gì. Đây là thứ để kiểm chứng, không phải để khẳng định.
Bước 2 — Phỏng vấn về quá khứ, không hỏi về tương lai. Đừng hỏi "anh có muốn dùng AI để...?" (câu hỏi tương lai luôn cho câu trả lời lịch sự, vô giá trị). Hãy hỏi: "Lần gần nhất anh phải làm việc X là khi nào? Anh đã làm thế nào? Chỗ nào khó chịu nhất?" Hành vi quá khứ là dữ liệu thật.
Bước 3 — Đào "5 Whys" để chạm underlying job. Mỗi khi user nói ra một giải pháp ("tôi muốn chatbot"), hỏi "để làm gì?" liên tiếp cho đến khi chạm tới công việc cốt lõi không thể đào sâu hơn. Đó là JTBD thật.
Bước 4 — Săn workaround. Hỏi thẳng: "Hiện giờ anh đang tự xoay xở việc này thế nào?" Xin xem file, xem màn hình, xem quy trình tay. Mỗi workaround là một use case tiềm năng đã được user tự xác nhận là đáng để bỏ công.
Bước 5 — Gắn nhãn AI-shaped. Với mỗi pain point đào được, hỏi: đầu vào có lộn xộn/ngôn ngữ tự nhiên không? Có cần hiểu ngữ nghĩa không? Có chấp nhận gần đúng không? Nếu cả ba đều "có", đó là ứng viên AI mạnh.
Bước 6 — Chấm điểm và xếp ưu tiên. Với mỗi use case, chấm theo: tần suất × mức độ đau × tính khả thi AI × giá trị kinh doanh. Chọn ra một use case "đủ đau, đủ thường xuyên, đủ khả thi" để làm điểm khởi đầu — đừng tham lam ôm hết.
Bước 7 — Viết lại dưới dạng problem statement, chưa vội nói giải pháp. Ví dụ: "Lễ tân mất 4 giờ/ngày gõ lại thông tin từ phiếu viết tay; đầu vào là ảnh chữ tay, chấp nhận sai sót nhỏ có người xác nhận." Một problem statement tốt tự nó đã gợi mở giải pháp AI mà không cần bạn áp đặt.
Lỗi thường gặp & mẹo
Lỗi 1 — Hỏi user "anh muốn AI làm gì". Đây là câu hỏi tệ nhất trong discovery AI. User không biết AI làm được gì, nên họ sẽ bịa hoặc lặp lại từ khóa thời thượng. Mẹo: luôn hỏi về công việc và nỗi đau, không bao giờ hỏi về công nghệ.
Lỗi 2 — Yêu nghệ thuật, không yêu vấn đề. PM hứng thú với AI thường vô thức tìm chỗ để nhét AI vào, thay vì tìm vấn đề đáng giải. Mẹo: tự hỏi "nếu cấm dùng AI, vấn đề này có còn đáng giải không?" Nếu không, đó không phải pain thật.
Lỗi 3 — Nghe lời user theo nghĩa đen. "Làm chatbot" được hiểu là build chatbot — như ví dụ sàn TMĐT. Mẹo: luôn đào xuống một tầng dưới giải pháp user đề xuất.
Lỗi 4 — Chỉ phỏng vấn người ra quyết định, bỏ quên người thực thi. Sếp mô tả vấn đề theo góc nhìn chiến lược; nhân viên trực tiếp mới biết cơn đau hằng ngày nằm ở đâu. Mẹo: luôn dành thời gian quan sát người làm việc thật, ngồi cạnh họ một buổi còn giá trị hơn mười cuộc họp.
Lỗi 5 — Bỏ qua nhóm underestimate. Nếu chỉ build theo những gì user đề xuất, bạn sẽ mãi mãi bỏ lỡ những use case AI giá trị nhất — vì những use case ấy user không bao giờ tự nghĩ ra. Mẹo: dùng quan sát để tự phát hiện cơ hội, đừng đợi user gợi ý.
Mẹo tổng quát — "show, don't ask". Khi nghi ngờ một use case, dựng một prototype thô (kể cả làm tay giả lập kết quả AI) rồi cho user trải nghiệm. Phản ứng khi thấy tận mắt trung thực hơn nhiều so với câu trả lời khi được hỏi.
Bài tập thực hành
Hãy chọn một nhóm người dùng thật mà bạn có thể tiếp cận (đồng nghiệp một phòng ban, một tiểu thương, một bạn làm nghề khác) và thực hiện:
- Phỏng vấn quá khứ (30 phút): chọn một công việc lặp lại của họ. Hỏi về lần gần nhất họ làm việc đó, từng bước, và chỗ khó chịu nhất. Tuyệt đối không nhắc tới chữ "AI".
- Đào underlying job: với mỗi mong muốn họ nêu, hỏi "để làm gì?" ít nhất ba lần. Ghi lại JTBD cốt lõi bạn chạm tới.
- Săn workaround: yêu cầu họ cho xem cách họ đang tự xoay xở (file, ghi chú, quy trình tay). Chụp lại hoặc mô tả.
- Lập bảng chấm điểm: liệt kê 3-5 pain point đào được, chấm mỗi cái theo tần suất, mức độ đau, tính AI-shaped và giá trị. Chọn ra một use case ưu tiên.
- Viết problem statement: viết một câu duy nhất mô tả vấn đề ưu tiên theo mẫu ở Bước 7, không nhắc tới giải pháp.
Tóm tắt
- User thường không biết họ cần AI, và khi được hỏi sẽ mô tả giải pháp đã biết ("faster horse"), không phải công việc cốt lõi. Nhiệm vụ của PM là đào xuống tới underlying job bằng framework JTBD.
- Có hai nhóm user: underestimate (cần bạn quan sát để tự phát hiện cơ hội) và overestimate (cần bạn kéo kỳ vọng về thực tế và thu hẹp về khoảnh khắc cụ thể).
- Workaround tự chế là bằng chứng mạnh nhất của nhu cầu thật. Một use case đáng làm phải đủ tần suất × mức độ đau × tính AI-shaped × giá trị kinh doanh.
- Quy trình: phỏng vấn quá khứ thay vì hỏi tương lai → đào 5 Whys → săn workaround → gắn nhãn AI-shaped → chấm điểm ưu tiên → viết problem statement chưa vội nói giải pháp.
- Tránh năm cái bẫy: hỏi "anh muốn AI làm gì", yêu công nghệ hơn vấn đề, nghe lời theo nghĩa đen, chỉ phỏng vấn sếp, và bỏ quên nhóm underestimate. Khi nghi ngờ — show, don't ask.