Ngày 5 · Thiết kế sản phẩm AI

Ý chínhGiảng viên đặt câu hỏi xuyên suốt ngày học — vì sao một sản phẩm AI chạy đúng hôm nay có thể sai vào hôm sau dù không ai sửa một dòng code nào — và giới thiệu bốn phần của ngày: từ giả thuyết đến MVP, viết PRD cho một AI feature, đặt đúng kỳ vọng và niềm tin, và quyết định quyền tự chủ khi AI hành động. Nhấn mạnh rằng khác với phần mềm truyền thống, sai của AI là xác suất chứ không phải lỗi có thể fix một lần là xong, nên cách thiết kế sản phẩm phải đổi từ gốc.

Kỹ năngHọc viên biết mình sẽ đạt được gì sau ngày học, và vì sao góc nhìn "AI sai không phải bug" lại quan trọng.

Hình thứcVideo giảng viên, 3 phút.

Ý chínhLeap of faith là giả định quan trọng nhất trong một ý tưởng sản phẩm mà đồng thời có ít bằng chứng nhất — quy tắc là test giả định đó trước, thay vì test những gì đã biết chắc. Toàn bộ vòng đời sản phẩm cũ được thiết kế quanh giả định "build rất đắt"; khi AI làm build rẻ đi, mọi khâu trước build — nghiên cứu, viết spec, thiết kế — cũng phải đổi theo. Mô hình double diamond đã học ở Ngày 2 (khám phá — hội tụ — khám phá — hội tụ) không đổi, nhưng AI giúp cả ba khâu chạy nhanh hơn: nhiều ý tưởng hơn ở khâu mở, đồng thuận nhanh hơn ở khâu hội tụ, và giao được nhanh hơn ở khâu cuối.

Kỹ năngHọc viên xác định được giả thuyết nào cần test trước trong một ý tưởng sản phẩm, và giải thích được vì sao build rẻ đi làm đổi cả trình tự làm sản phẩm.

Hình thứcVideo 6 phút.

Ý chínhPrototype, Pilot, MVP, và POC là bốn từ hay bị dùng thay cho nhau nhưng khác nhau trên hai trục: mức độ hoàn thiện, và phạm vi test — một phần sản phẩm hay toàn bộ. Thang fidelity Sketch → Wireframe → Mockup → Prototype đi từ rẻ đến đắt; bậc thấp kiểm tra được luồng và tính năng, bậc cao kiểm chứng được cảm giác "như thật", và mỗi bậc trả lời đúng một loại câu hỏi khác nhau. Chọn sai bậc — ví dụ làm một bản hoàn thiện chỉ để hỏi một câu về luồng đơn giản — là công sức bỏ ra không đúng chỗ.

Kỹ năngHọc viên chọn được bậc fidelity phù hợp với câu hỏi cần trả lời, thay vì luôn làm bản hoàn thiện nhất có thể.

Hình thứcVideo 6 phút, có loạt hình so sánh cùng một sản phẩm qua bốn bậc fidelity.

Ý chínhHai cách giữ MVP rẻ: tạo nhiều biến thể (variations) để so sánh trước khi chọn một hướng, thay vì đầu tư sâu ngay vào một hướng duy nhất; và làm một lát cắt mỏng xuyên suốt toàn bộ luồng (thin slice), thay vì build hoàn chỉnh từng tầng một. Ở mô hình cũ, học được sau khi build xong — phản hồi đến lúc gần như đã hết đường lùi; ở mô hình mới, học xen kẽ trong lúc build — phản hồi đến khi vẫn còn dễ đổi hướng. MVP không phải một mảnh nhỏ của sản phẩm lớn, mà là một sản phẩm dùng được ở quy mô nhỏ — giống một tấm ván trượt vẫn "đi được" trước khi trở thành ô tô.

Kỹ năngHọc viên phân biệt được MVP đúng nghĩa với một mảnh sản phẩm dở dang, và áp dụng được một trong hai đòn bẩy khi lên kế hoạch build.

Hình thứcVideo 6 phút.

Ý chínhHai ca minh hoạ việc test giá trị bằng tay trước khi có hệ thống: một dịch vụ giao đồ ăn ra mắt chỉ bằng một trang tĩnh liệt kê thực đơn quét tay và một số điện thoại đổ chuông thẳng vào máy của người sáng lập; một trợ lý ghi chú cuộc họp ra mắt với "bot AI" thực chất là người ngồi gõ tay hơn một trăm cuộc họp, để xác nhận có người sẵn sàng trả tiền trước khi build mô hình thật. Cả hai chỉ đầu tư vào AI sau khi đã có bằng chứng nhu cầu.

Kỹ năngHọc viên thiết kế được một cách test nhu cầu người dùng không cần AI thật, trước khi đầu tư vào build.

Hình thứcTương tác dự đoán rồi quan sát 4 phút trên hai ca cấu hình sẵn: học viên dự đoán có bao nhiêu người dùng thử và có ai trả tiền trước khi xem số liệu thật. Phương án thay thế: video kể hai ca liền mạch.

Ý chínhCông cụ dựng sản phẩm AI chia thành ba nhóm theo độ phức tạp của thứ cần dựng: nhóm dựng prototype đơn giản, nhóm dựng prototype nhiều tính năng và nhiều màn hình, và nhóm hướng tới ứng dụng nghiêm túc chuẩn bị đưa vào sản xuất. Không nhóm nào tốt cho mọi việc; chọn công cụ theo mục tiêu cần đạt, không theo mức độ đang được nhắc đến nhiều.

Kỹ năngHọc viên chọn được nhóm công cụ phù hợp với mục tiêu dựng sản phẩm, thay vì chọn theo công cụ đang phổ biến.

Hình thứcVideo 4 phút.

Ý chính3 câu kiểm tra: cách nhận diện leap of faith trong một ý tưởng, phân biệt MVP với một bản pilot, chọn đòn bẩy MVP phù hợp cho một tình huống cho sẵn.

Kỹ năngHọc viên tự kiểm tra ba ý chính của module.

Hình thứcQuiz 3 câu, chấm ngay, có giải thích khi sai.

Ý chínhCó AI trong tay dễ khiến người làm sản phẩm đi tìm chỗ để nhét AI vào, thay vì tìm đúng vấn đề của người dùng trước — như mang một cây búa đi tìm cái đinh. Cách làm ngược lại: hiểu sâu người dùng trước, brainstorm từ năng lực thật của AI sau, rồi chọn use case theo giá trị mang lại và lợi thế khó sao chép, không chọn theo mức độ đang được nhắc đến nhiều. Problem statement không được nhắc đến chữ AI — vấn đề của người dùng không phải là "đời tôi đang thiếu AI"; và một use case tốt đi qua ba bậc rõ ràng, từ tệ, đến ổn, đến tốt hơn nữa.

Kỹ năngHọc viên viết được một problem statement không nhắc AI, và chọn được use case theo giá trị thay vì theo công nghệ đang có sẵn.

Hình thứcVideo 8 phút, ví dụ một tính năng tóm tắt cuộc họp chạy xuyên suốt từ vấn đề đến use case.

Ý chínhGoals nên viết dưới dạng kết quả định tính (outcome), không phải giải pháp cụ thể; non-goals chặn tính năng phình to ngoài dự định; metrics chia ba tầng — mức dùng, chất lượng, và tác động — vì khách hàng lớn sẽ hỏi thẳng về hiệu quả đầu tư. User flow phải vẽ trọn luồng đầu-cuối kể cả các bước không có AI, và cân nhắc sáu kiểu người dùng có thể kích hoạt tính năng, thay vì mặc định luôn là một khung chat.

Kỹ năngHọc viên viết được goals, non-goals, và metrics ba tầng cho một AI feature, và vẽ được user flow đầu-cuối.

Hình thứcVideo 7 phút.

Ý chínhBốn mục cần thêm vào một PRD cho AI feature mà bản PRD truyền thống không có sẵn chỗ: dữ liệu đầu vào và ngữ cảnh, đặc tả đầu ra của model, cơ chế phản hồi, và ngưỡng chấp nhận chất lượng — ngưỡng này cao hay thấp tuỳ mức độ rủi ro của tính năng. Nguyên nhân gốc là sự không chắc chắn vốn là mặc định của AI chứ không phải trường hợp hiếm gặp, với ba loại lỗi khác nhau — kết quả dao động giữa các lần chạy, hành vi trôi dần theo thời gian, và lỗi ở tầng lập luận. Ba cách đổi tư duy khi viết spec: từ "kết quả mong đợi" sang "tỉ lệ đạt được"; từ "test case" sang "phân bố tình huống"; và từ "chạy được" sang "biết trước sẽ sai kiểu nào".

Kỹ năngHọc viên viết được bốn mục spec riêng cho AI feature, và diễn đạt được yêu cầu chất lượng bằng tỉ lệ thay vì bằng đúng/sai tuyệt đối.

Hình thứcVideo 6 phút. Trên lớp, tương tác cặp tương phản 5 phút trên dữ liệu cấu hình sẵn: hai bản spec cho cùng một tính năng, một chỉ có mục PRD truyền thống và một có thêm bốn mục dành riêng cho AI — học viên chỉ ra điểm khác biệt sẽ gây tranh cãi nhất khi review. Phương án thay thế: làm một mình theo mẫu có sẵn.

Ý chínhLiệt kê trước các kịch bản lỗi bắt đầu từ việc trả lời một bộ câu hỏi cấu hình về tính năng — càng trả lời rõ, danh sách kịch bản lỗi cần test càng cụ thể. Một mô phỏng cho thấy chỉ đổi một dòng cấu hình, ví dụ khung giờ hoạt động của tính năng, đã làm ba kịch bản lỗi biến mất hoặc xuất hiện — bề mặt rủi ro không cố định mà phụ thuộc trực tiếp vào cấu hình đã chọn.

Kỹ năngHọc viên liệt kê được các kịch bản lỗi cần test từ một bộ cấu hình tính năng, thay vì đoán ngẫu nhiên.

Hình thứcTương tác mô phỏng 4 phút trên dữ liệu cấu hình sẵn: đổi từng cấu hình, dự đoán kịch bản lỗi sẽ đổi ra sao rồi quan sát kết quả thật. Phương án thay thế: video minh hoạ trước-sau của hai cấu hình.

Ý chínhBa mảng thường bị bỏ sót ở cuối PRD: quyền riêng tư và kiểm soát — công khai cho người dùng biết đang dùng AI, mặc định tắt các quyền nhạy cảm, có công tắc tắt khẩn cấp, và quy định thời gian lưu dữ liệu; phối hợp với đội kỹ thuật — tránh viết spec quá chi tiết đến mức trói tay việc triển khai; và kế hoạch ra mắt theo từng nhóm người dùng thay vì bật cho tất cả cùng lúc.

Kỹ năngHọc viên liệt kê được ba mảng cần thêm vào cuối PRD trước khi coi là hoàn chỉnh.

Hình thứcVideo 5 phút.

Ý chính3 câu kiểm tra: đặc điểm một problem statement đúng, mục nào PRD truyền thống thường thiếu cho AI feature, vì sao bề mặt rủi ro đổi theo cấu hình.

Kỹ năngHọc viên tự kiểm tra ba ý chính của module.

Hình thứcQuiz 3 câu, chấm ngay.

Ý chínhPhần mềm truyền thống cho cùng một input luôn ra cùng một output, và một lỗi tìm ra là sửa dứt điểm được. AI cho cùng input, cùng model, cùng cấu hình, nhưng có thể ra kết quả khác nhau giữa các lần chạy — kiểm thử không còn là đạt hay không đạt sau một lần chạy, và một lỗi xác suất chỉ có thể giảm bớt chứ khó sửa dứt điểm. Đây là nền cho toàn bộ phần thiết kế lấy con người làm trung tâm: 4 câu hỏi dẫn dắt phần còn lại của module là kỳ vọng đã đúng chưa, người dùng có biết AI làm và không làm được gì chưa, phản hồi khi AI sai ra sao, và vòng lặp học từ phản hồi thế nào.

Kỹ năngHọc viên giải thích được vì sao kiểm thử một tính năng AI không thể chỉ là đạt hoặc không đạt sau một lần chạy.

Hình thứcVideo 6 phút.

Ý chínhNiềm tin của người dùng cần khớp với năng lực thật của hệ thống — tin quá mức khiến người dùng ngừng kiểm tra và gây nguy hiểm, tin quá thấp khiến người dùng bỏ luôn tính năng dù nó hoạt động tốt, cả hai đều là thất bại sản phẩm. Ba đòn bẩy để hiệu chỉnh: nói rõ ngay từ đầu AI làm được gì (expectation); cho người dùng thấy vì sao ra kết quả này (explainability); và cho người dùng sửa, hoàn tác, hoặc duyệt trước khi hành động được thực thi (control). Nguyên tắc chốt là giao diện không nên hứa hẹn nhiều hơn năng lực thật — lời hứa vượt quá năng lực làm niềm tin gãy rất nhanh một khi người dùng phát hiện ra.

Kỹ năngHọc viên áp dụng được một trong ba đòn bẩy để sửa một tình huống AI đang hứa quá năng lực.

Hình thứcVideo 7 phút.

Ý chínhNgười dùng không nên phải tự đoán năng lực của AI — ba cách làm rõ là giải thích trực tiếp, để lộ các nút điều khiển tương ứng với năng lực, và cho xem ví dụ input khả dụng ngay trên giao diện. Ngoài việc AI làm được gì, giao diện cũng cần chỉ rõ AI làm tốt nhất trong điều kiện nào và nên tránh điều kiện nào, kèm ví dụ cụ thể — nói chung chung rằng độ chính xác cao mà không nói rõ trong hoàn cảnh nào là một lỗi thiết kế. Khi AI không chắc, lựa chọn tốt hơn là hỏi lại để làm rõ ý người dùng thay vì cố hành động cho xong — bớt làm đi đôi khi lại là trải nghiệm tốt hơn.

Kỹ năngHọc viên thiết kế được một cách làm rõ năng lực AI trên giao diện, và nhận biết được tình huống nên để AI hỏi lại thay vì tự hành động.

Hình thứcVideo 6 phút.

Ý chính3 câu kiểm tra: khác biệt giữa kiểm thử phần mềm chạy theo luật và AI chạy theo xác suất, chọn đòn bẩy phù hợp cho một tình huống cho sẵn, khi nào nên để AI hỏi lại thay vì tự hành động.

Kỹ năngHọc viên tự kiểm tra ba ý chính của module.

Hình thứcQuiz 3 câu, chấm ngay.

Ý chínhTrực giác tự nhiên là "càng tự động càng tốt", nhưng ba lựa chọn — không làm gì, hỏi lại, hoặc tự hành động — không có lựa chọn nào mặc định tốt hơn lựa chọn nào. Quyền tự chủ nên được quyết định bằng tích của hai yếu tố: mức độ chắc chắn của AI và cái giá phải trả khi sai, không phải một mức cố định áp dụng cho mọi tính năng. Việc nào sai mà đắt — ví dụ xoá dữ liệu hay chuyển nhầm tiền — thì vùng AI được tự làm phải co rất hẹp, hệ thống nên chịu thêm một bước xác nhận để người dùng khỏi chịu hậu quả; việc nào sai mà rẻ và sửa được ngay — như gợi ý tự động hoàn thành — thì vùng tự làm có thể rộng hơn, vì AI được hành động không phải vì nó giỏi mà vì sai thì người dùng vẫn sửa với công sức thấp.

Kỹ năngHọc viên chọn được mức quyền tự chủ phù hợp cho một tính năng dựa trên độ chắc chắn và cái giá phải trả khi sai, thay vì mặc định chọn mức tự động cao nhất.

Hình thứcVideo 7 phút. Trên lớp, tương tác cặp tương phản 3 phút trên hai tình huống cấu hình sẵn: một tác vụ tự động hoàn toàn và một tác vụ tương tác từng bước, học viên so sánh tỉ lệ phải sửa lại giữa hai bên. Phương án thay thế: video minh hoạ hai tình huống nối tiếp.

Ý chínhKhi AI đã ra kết quả, người dùng cần hiểu vì sao hệ thống trả lời như vậy — giải thích tốt luôn gắn với một hành động tiếp theo cụ thể của người dùng, không chỉ là một câu diễn giải suông. Với hành động khó đảo ngược — đặt chỗ, thanh toán — AI có thể chuẩn bị sẵn nhưng người dùng phải duyệt trước khi thực thi; thêm một bước duyệt là ma sát tốt, không phải rào cản thừa. Ngưỡng chấp nhận không phải một tham số kỹ thuật cố định mà là một quyết định sản phẩm dựa trên việc báo nhầm hay bỏ sót gây hại nhiều hơn — không tồn tại một con số ngưỡng đúng cho mọi tính năng; người dùng cũng không cần thấy con số ngưỡng cụ thể, điều cần thấy là hệ thống cư xử khác nhau rõ rệt theo từng mức độ tin cậy.

Kỹ năngHọc viên thiết kế được một cơ chế duyệt trước khi thực thi cho hành động khó đảo ngược, và giải thích được ngưỡng chấp nhận nên dựa vào điều gì thay vì một con số cố định.

Hình thứcVideo 7 phút. Trên lớp, tương tác dự đoán rồi quan sát 3 phút trên dữ liệu cấu hình sẵn: cùng một kết quả ở ba mức độ tin cậy khác nhau, học viên dự đoán cách hệ thống nên cư xử trước khi xem đáp án. Phương án thay thế: video minh hoạ ba mức độ tin cậy nối tiếp.

Ý chínhKhi AI không hoàn hảo, sản phẩm không nên bắt người dùng làm lại từ đầu — nếu kết quả còn dùng được thì cho sửa trực tiếp, nếu vừa làm hỏng thứ có giá trị thì cho hoàn tác. Trạng thái lỗi là cơ hội kép: vừa giải thích lại AI làm tốt trong điều kiện nào để đặt lại kỳ vọng, vừa là lúc xin phản hồi vì chất lượng phản hồi lúc lỗi vừa xảy ra thường cao nhất. Khi AI không đủ khả năng xử lý, sản phẩm cần một lối thoát rõ ràng — chuyển sang người thật, gợi ý bước tiếp theo, hoặc cho người dùng tự chỉnh — lối thoát rõ ràng là một trụ cột của niềm tin, không phải một tính năng phụ.

Kỹ năngHọc viên thiết kế được ít nhất một cơ chế phục hồi — sửa, hoàn tác, hoặc lối thoát — cho một tình huống AI trả lời sai.

Hình thứcVideo 6 phút, bốn khuôn mẫu phục hồi minh hoạ bằng ví dụ liên tiếp.

Ý chínhNgày 2 đã định nghĩa báo nhầm (false positive), bỏ sót (false negative) và cặp tỉ lệ precision, recall; item này không định nghĩa lại mà áp hai khái niệm đó vào quyết định sản phẩm. Hai loại sai này gây hại khác nhau tuỳ tình huống — một bộ lọc thư rác báo nhầm làm mất một email quan trọng, trong khi một hệ thống sàng lọc y tế bỏ sót làm bỏ lỡ một ca cần điều trị; không có câu trả lời chung cho việc loại sai nào nên được ưu tiên giảm, quyết định phụ thuộc vào ai phải gánh hậu quả. Đây là bước đặt nền đầu tiên của việc đánh giá AI có hệ thống, chủ đề Ngày 14 sẽ đi sâu.

Kỹ năngHọc viên phân biệt được báo nhầm với bỏ sót trong một tình huống cho sẵn, và chọn được loại sai nên ưu tiên giảm kèm lý do.

Hình thứcVideo 6 phút. Trên lớp, tương tác dự đoán rồi quan sát 4 phút trên năm tình huống cấu hình sẵn: học viên dự đoán loại sai nên ưu tiên giảm cho từng tình huống trước khi xem đáp án và lý do. Phương án thay thế: quiz 5 câu tình huống.

Ý chính3 câu kiểm tra: cách tính quyền tự chủ từ độ chắc chắn và cái giá phải trả khi sai, vì sao cần bước duyệt cho hành động khó đảo ngược, phân biệt báo nhầm với bỏ sót trong một tình huống cho sẵn.

Kỹ năngHọc viên tự kiểm tra trước khi vào lab.

Hình thứcQuiz 3 câu, chấm ngay.

Ý chínhGiảng viên trả lời câu hỏi mở đầu bằng bốn điểm chính: AI sai vì nó vận hành theo xác suất chứ không phải vì có một lỗi cần fix; PRD cho AI feature cần thêm bốn mục mà PRD truyền thống không có; niềm tin của người dùng được hiệu chỉnh bằng ba đòn bẩy kỳ vọng, giải thích, kiểm soát chứ không phải bằng cách giấu đi phần AI; và quyền tự chủ cùng cách phục hồi khi sai quyết định phần lớn trải nghiệm sản phẩm. Giới thiệu bước tiếp theo: SPEC nhẹ vừa hoàn thành trong lab hôm nay là điểm khởi đầu của hackathon Ngày 6.

Kỹ năngHọc viên tóm tắt được bốn điểm chính bằng ngôn ngữ của mình.

Hình thứcVideo giảng viên, 3 phút.

Ý chínhMở rộng cho item 4.1. Trực giác phổ biến là hệ thống càng tự động nhiều thì càng tốt, nhưng một phép so sánh cho thấy điều ngược lại: một tính năng tự động hoàn toàn nhưng người dùng phải sửa lại một nửa kết quả có trải nghiệm tệ hơn một tính năng chỉ cần 1, 2 lượt tương tác nhưng gần như không cần sửa gì. Mức độ tự động nên đo bằng thời gian hoàn thành và số bước thao tác thực tế, không đo bằng cảm giác "AI làm hộ được bao nhiêu".

Kỹ năngHọc viên đánh giá được một tính năng tự động theo thời gian và số bước thực tế, thay vì theo mức độ AI can thiệp.

Hình thứcVideo 4 phút, hai tình huống tự động và tương tác đặt cạnh nhau.

Ý chínhMở rộng cho item 4.2. Cùng một con số ngưỡng có thể đúng cho tình huống này và sai hoàn toàn cho tình huống khác — gợi ý sai một chữ trong câu trả lời có hậu quả rất khác với xoá nhầm một dòng dữ liệu, dù cùng mức độ tin cậy. Ba ví dụ ngưỡng khác nhau cho ba loại hệ thống minh hoạ rằng ngưỡng luôn là kết quả của hai yếu tố: mức độ nguy hại nếu sai, và khả năng của người đứng sau xử lý số lượng bị đẩy lên kiểm tra thủ công.

Kỹ năngHọc viên giải thích được ngưỡng chấp nhận của một hệ thống cụ thể nên dựa vào hai yếu tố nào.

Hình thứcVideo 4 phút, ba ví dụ ngưỡng khác nhau nối tiếp.

Ý chínhMở rộng cho item 4.4. Một cách "ăn gian" để đạt bỏ sót bằng không là chặn tất cả — không bỏ sót ca nào thật, nhưng đồng thời báo nhầm gần như toàn bộ, khiến hệ thống vô dụng trên thực tế. Một ví dụ y tế cho thấy nới ngưỡng để bắt hết ca nghi ngờ làm tỉ lệ báo nhầm tăng gấp đôi, kéo theo việc kiểm tra thêm và quá tải cho người xử lý phía sau — bài học là chọn ưu tiên báo nhầm hay bỏ sót luôn phải cân với khả năng xử lý phía sau, không chọn theo con số đẹp nhất trên giấy.

Kỹ năngHọc viên giải thích được vì sao một hệ thống bỏ sót bằng không chưa chắc là hệ thống tốt.

Hình thứcVideo 4 phút.

Ý chínhHọc viên chọn một ý tưởng AI feature — từ tình huống được cung cấp hoặc từ một nỗi đau đã quan sát — và viết một SPEC nhẹ áp dụng toàn bộ kiến thức trong ngày: problem statement không nhắc chữ AI, goals/non-goals/metrics ba tầng, bốn mục spec riêng cho hệ thống xác suất, ít nhất một quyết định về quyền tự chủ, và ít nhất một cơ chế phục hồi khi AI sai. SPEC nhẹ này là điểm khởi đầu cho hackathon Ngày 6 — nhóm sẽ dùng chính bản này để bắt đầu build.

Kỹ năngHọc viên viết được một SPEC nhẹ hoàn chỉnh cho một AI feature, đủ cụ thể để bắt đầu build ngay.

Hình thứcLab 90 phút tại lớp với người hướng dẫn, theo mẫu SPEC nhẹ có sẵn. Kèm mẫu SPEC nhẹ và danh sách ý tưởng gợi ý.