Mở đầu — vì sao bài này quan trọng
Trong các bài trước, bạn đã học cách phát hiện use case AI cùng người dùng (Bài 9) và đo lường thành công bằng metrics (Bài 10). Nhưng giữa "có ý tưởng tốt" và "có sản phẩm AI chạy thật trên production" là một khoảng cách rất lớn — và phần lớn dự án AI chết ở khoảng giữa đó. Lý do không phải vì công nghệ yếu, mà vì đội ngũ không có một lộ trình (roadmap) phù hợp với bản chất bất định của AI.
Roadmap cho sản phẩm AI khác hẳn roadmap phần mềm truyền thống. Với phần mềm thường, nếu bạn viết đúng code thì tính năng sẽ chạy đúng 100% như đặc tả. Với AI, bạn không bao giờ biết chắc mô hình có đạt độ chính xác cần thiết hay không cho đến khi thử thật với dữ liệu thật. Một chatbot có thể đạt 92% độ hài lòng trong demo nhưng tụt xuống 60% khi gặp tiếng Việt có dấu lẫn không dấu, viết tắt teen code, hay câu hỏi đa nghĩa. Vì vậy, roadmap AI phải được thiết kế để "mua thông tin về tính khả thi càng sớm càng tốt với chi phí càng thấp càng tốt".
Bài này dạy bạn cấu trúc một roadmap AI theo các giai đoạn (phases) rõ ràng, mỗi giai đoạn có mục tiêu, milestone, và tiêu chí dừng/đi (go/no-go) cụ thể. Đây là kỹ năng cốt lõi để một AI Product Manager thuyết phục được leadership rót ngân sách, giữ được kỳ vọng của stakeholder ở mức thực tế, và tránh đốt sáu tháng vào một thứ lẽ ra nên bị giết sau hai tuần.
Khái niệm cốt lõi
Roadmap AI là một chuỗi giảm bất định, không phải lịch giao tính năng
Hãy đổi tư duy: roadmap AI không phải là danh sách tính năng xếp theo quý. Nó là một chuỗi các "thí nghiệm" được sắp xếp để mỗi bước trả lời một câu hỏi rủi ro lớn nhất còn lại. Ở mỗi mốc, bạn tự hỏi: "Rủi ro nào có thể giết dự án này, và thí nghiệm rẻ nhất để kiểm chứng nó là gì?"
Có bốn loại rủi ro mà roadmap AI cần lần lượt hạ gục:
- Rủi ro giá trị (value risk): Người dùng có thực sự muốn thứ này không, ngay cả khi nó hoạt động hoàn hảo?
- Rủi ro khả thi kỹ thuật (feasibility risk): Mô hình AI có thể đạt mức chất lượng đủ tốt với dữ liệu hiện có không?
- Rủi ro khả dụng (usability risk): Người dùng có hiểu và tin tưởng kết quả AI để dùng được không?
- Rủi ro vận hành (viability risk): Chi phí token, độ trễ, và rủi ro pháp lý có cho phép vận hành bền vững không?
Các giai đoạn điển hình của một sản phẩm AI
Phase 1 — Exploration (Khám phá, 4–8 tuần). Mục tiêu: xác nhận rủi ro giá trị và rủi ro khả thi ở mức thấp nhất. Đây là giai đoạn của ba kỹ thuật quan trọng:
- Discovery interview: phỏng vấn 8–15 người dùng để hiểu thật sự nỗi đau, chứ không phải để bán giải pháp AI.
- Wizard of Oz / Magic Mock: giả lập sản phẩm AI bằng con người ngồi sau hậu trường. Người dùng tưởng đang nói chuyện với AI, nhưng thực ra một nhân viên đang gõ câu trả lời. Cách này cho bạn đo lường nhu cầu thật mà chưa cần xây mô hình.
- Capability prototype: một prototype kỹ thuật nhanh, thường dùng API có sẵn (GPT, Claude, Gemini) để kiểm tra xem mô hình có "đủ giỏi" cho bài toán không. Đây chỉ là thử nghiệm trong notebook, chưa có UI hoàn chỉnh.
Phase 3 — Scaling / Hardening (8–16 tuần). Khi MVP chứng minh được giá trị, bạn đầu tư vào độ tin cậy: guardrails, giám sát drift, tối ưu chi phí token, hạ tầng vận hành. Đây là lúc rủi ro vận hành (viability) trở thành trung tâm — một sản phẩm chạy tốt cho 100 người chưa chắc chạy nổi về mặt chi phí cho 100.000 người.
Phase 4 — Optimization / Expansion (liên tục). Sản phẩm đã ổn định, bạn tinh chỉnh: A/B test prompt, cân nhắc fine-tuning, mở rộng use case, cải thiện đơn giá mỗi request.
Milestone và tiêu chí Go / No-Go
Mỗi giai đoạn phải kết thúc bằng một milestone có tiêu chí định lượng để quyết định đi tiếp hay dừng. Đây là điểm khác biệt giữa một PM nghiệp dư và một PM chuyên nghiệp. Ví dụ:
- Kết thúc Phase 1: "Mô hình đạt ≥ 80% độ chính xác trên 200 mẫu thật, và ≥ 6/10 người phỏng vấn nói họ sẵn sàng trả tiền." Nếu không đạt → quay lại hoặc giết dự án.
- Kết thúc Phase 2: "Tỷ lệ chấp nhận đề xuất AI ≥ 60% trong beta, NPS ≥ 30."
Tình huống thực tế
Tình huống 1 — Tiki và trợ lý phân loại khiếu nại khách hàng
Giả định một sàn TMĐT lớn như Tiki muốn dùng AI để tự động phân loại và định tuyến hàng nghìn ticket chăm sóc khách hàng mỗi ngày. Thay vì lao thẳng vào xây hệ thống, đội PM chạy Phase 1 trong 5 tuần. Họ lấy 500 ticket lịch sử, ném qua API của một LLM với prompt phân loại, và đo: mô hình đạt 84% khớp với nhãn do nhân viên gán thủ công. Đồng thời, họ làm Wizard of Oz — cho một LLM gợi ý nhãn nhưng nhân viên vẫn duyệt — để xem nhân viên có chấp nhận gợi ý không. Kết quả: nhân viên đồng ý với 78% gợi ý.
Milestone Phase 1 đặt ngưỡng "≥ 80% độ chính xác". Mô hình đạt 84% nên qua được, nhưng đội phát hiện 16% sai chủ yếu rơi vào nhóm khiếu nại nhạy cảm (hoàn tiền, hàng giả) — đúng nhóm tốn kém nhất nếu phân loại sai. Bài học: họ điều chỉnh roadmap, quyết định để AI tự động xử lý nhóm ticket đơn giản và bắt buộc human-in-the-loop cho nhóm nhạy cảm ở Phase 2. Roadmap không bị giết, nhưng phạm vi được thu hẹp một cách thông minh nhờ dữ liệu thật.
Tình huống 2 — Một startup fintech Việt Nam đốt ngân sách vì thiếu milestone
Một startup cho vay tiêu dùng (gọi là FinViet) muốn xây mô hình AI dự đoán khả năng vỡ nợ từ dữ liệu phi truyền thống. Họ bỏ qua Phase 1, nhảy thẳng vào xây hệ thống production trong 6 tháng vì CEO tin chắc "AI sẽ thay đổi cuộc chơi". Họ không đặt milestone go/no-go nào.
Đến tháng thứ năm, khi ghép mô hình vào dữ liệu thật, độ chính xác chỉ nhỉnh hơn mô hình thống kê cũ có 2%, trong khi chi phí hạ tầng cao gấp ba và quy trình khó giải thích cho bộ phận tuân thủ. Dự án bị đóng băng. Bài học: nếu họ chạy một Phase 1 capability prototype trong 4 tuần với cùng dữ liệu, họ đã biết "AI không tạo đủ lợi thế ở đây" với chi phí 1/20. Roadmap thiếu milestone biến một dự án lẽ ra "thất bại rẻ" thành "thất bại đắt".
Tình huống 3 — Grab và bài toán scaling chi phí ở Phase 3
Giả định Grab triển khai một tính năng tóm tắt đánh giá nhà hàng bằng LLM. MVP (Phase 2) chạy mượt cho 5.000 người dùng nội bộ, tỷ lệ hài lòng cao. Nhưng khi PM tính toán cho Phase 3 — mở rộng ra hàng triệu người dùng khắp Đông Nam Á — đơn giá mỗi lần gọi LLM nhân với khối lượng tạo ra một con số chi phí hàng tháng vượt xa doanh thu tính năng mang lại.
Roadmap Phase 3 vì thế xoay quanh rủi ro vận hành: họ cache các bản tóm tắt (đánh giá nhà hàng ít thay đổi), chuyển truy vấn đơn giản sang mô hình nhỏ rẻ hơn, và chỉ gọi mô hình lớn cho nhà hàng có nhiều đánh giá mới. Kết quả: chi phí giảm khoảng 70% mà chất lượng cảm nhận gần như không đổi. Bài học: một milestone Phase 3 nên có tiêu chí kiểu "đơn giá mỗi request ≤ X đồng ở quy mô mục tiêu" — nếu không đạt, sản phẩm tốt vẫn có thể chết vì không bền vững về kinh tế.
Hướng dẫn từng bước
Bước 1 — Liệt kê và xếp hạng rủi ro. Viết ra bốn loại rủi ro (value, feasibility, usability, viability) cho use case của bạn. Với mỗi cái, đánh giá: "Nếu rủi ro này thành sự thật, dự án có chết không?" và "Kiểm chứng nó tốn bao nhiêu?". Rủi ro nào vừa chí tử vừa rẻ để test thì đẩy lên đầu roadmap.
Bước 2 — Thiết kế Phase 1 quanh rủi ro lớn nhất. Chọn kỹ thuật phù hợp: discovery interview cho rủi ro giá trị, capability prototype cho rủi ro khả thi, Wizard of Oz khi muốn đo nhu cầu mà chưa muốn xây. Giới hạn Phase 1 trong 4–8 tuần và một ngân sách nhỏ.
Bước 3 — Định nghĩa milestone go/no-go định lượng cho từng giai đoạn. Mỗi milestone phải có con số cụ thể, gắn với metrics từ Bài 10 (offline accuracy, acceptance rate, NPS, đơn giá). Viết ra trước khi chạy, và cho stakeholder ký nhận.
Bước 4 — Lập timeline theo giai đoạn, không theo tính năng. Trình bày roadmap dưới dạng "Phase 1: Exploration (T1–T2), Phase 2: MVP (T3–T5)…" thay vì một danh sách tính năng cứng nhắc. Điều này quản trị kỳ vọng rằng phạm vi có thể thay đổi dựa trên kết quả mỗi giai đoạn.
Bước 5 — Gắn vòng phản hồi sau mỗi milestone. Sau mỗi giai đoạn, họp review: dữ liệu nói gì? Đi tiếp, xoay trục (pivot), hay dừng? Ghi lại quyết định và lý do.
Bước 6 — Truyền đạt sự bất định một cách trung thực. Khi trình bày cho leadership, nói rõ "đây là roadmap giả định, các giai đoạn sau phụ thuộc vào kết quả go/no-go". Đừng hứa ngày ra mắt cứng cho một thứ chưa kiểm chứng khả thi.
Lỗi thường gặp & mẹo
Lỗi: Coi roadmap AI như roadmap phần mềm thường. Hệ quả là hứa ngày giao hàng cứng cho tính năng mà bản chất khả thi còn chưa rõ. Mẹo: luôn đặt một giai đoạn exploration trước khi cam kết bất cứ ngày ra mắt nào.
Lỗi: Bỏ qua Phase 1 vì "sếp đã tin chắc". Đây là cách đốt tiền nhanh nhất, như tình huống FinViet. Mẹo: đóng khung Phase 1 không phải là "trì hoãn" mà là "bảo hiểm rẻ" — chi vài tuần để tránh mất vài tháng.
Lỗi: Không có tiêu chí go/no-go định lượng. Không có ngưỡng số thì cả đội sẽ tự thuyết phục mình rằng kết quả "cũng ổn". Mẹo: chốt con số trước, và để một người ngoài đội (ví dụ data lead) làm trọng tài đánh giá.
Lỗi: Để rủi ro vận hành đến cuối mới phát hiện. Nhiều đội chỉ tính chi phí token và độ trễ khi sắp scale, lúc đó đã quá muộn. Mẹo: ước tính đơn giá mỗi request ngay từ Phase 1, dù chỉ là con số thô.
Mẹo cộng thêm: Với bối cảnh Việt Nam, hãy đưa rủi ro ngôn ngữ vào roadmap sớm — tiếng Việt có dấu/không dấu, từ địa phương, teen code có thể kéo tụt độ chính xác mà mô hình tiếng Anh không gặp. Đặt một milestone kiểm thử riêng trên dữ liệu tiếng Việt thật.
Bài tập thực hành
- Lập bản đồ rủi ro: Chọn một use case AI (thật hoặc giả định) trong lĩnh vực bạn quan tâm. Liệt kê bốn loại rủi ro và xếp hạng theo "mức chí tử × độ rẻ để kiểm chứng". Xác định rủi ro nào nên test trước.
- Thiết kế Phase 1: Cho use case đó, viết kế hoạch Phase 1 trong 6 tuần: dùng kỹ thuật nào (interview, Wizard of Oz, hay capability prototype), cần dữ liệu gì, và đo metric nào.
- Viết tiêu chí go/no-go: Soạn ngưỡng định lượng cho cả ba giai đoạn đầu. Ví dụ Phase 1 cần đạt độ chính xác bao nhiêu trên bao nhiêu mẫu; Phase 2 cần acceptance rate và NPS bao nhiêu.
- Trình bày roadmap: Vẽ một roadmap bốn giai đoạn dạng timeline (có thể dùng bảng đơn giản), nêu rõ milestone và rủi ro chính của từng giai đoạn, như thể đang thuyết phục leadership rót ngân sách.
Tóm tắt
Roadmap cho sản phẩm AI không phải là lịch giao tính năng, mà là một chuỗi thí nghiệm được sắp xếp để giảm bất định càng sớm, càng rẻ càng tốt. Bốn loại rủi ro — giá trị, khả thi, khả dụng, vận hành — quyết định thứ tự các giai đoạn. Một roadmap điển hình đi qua bốn pha: Exploration (khám phá, 4–8 tuần với discovery interview, Wizard of Oz, capability prototype), Validation/MVP, Scaling/Hardening, và Optimization/Expansion. Điều phân biệt PM giỏi là mỗi giai đoạn đều kết thúc bằng một milestone với tiêu chí go/no-go định lượng, được chốt trước khi chạy. Các tình huống Tiki, FinViet và Grab cho thấy: thu hẹp phạm vi thông minh nhờ dữ liệu thật, thất bại rẻ thay vì thất bại đắt, và kiểm soát chi phí vận hành ở quy mô lớn — đó là ba bài học sống còn khi xây roadmap AI.