Mình có một tật xấu khác nữa (ngoài FOMO về AI): mình lên kế hoạch quá kỹ.
Mỗi khi có ý tưởng mới — dù là một bài giảng mới, một dự án nhỏ, hay thậm chí một bài viết blog — mình sẽ dành 3 ngày lập kế hoạch. Vẽ sơ đồ. Liệt kê rủi ro. Tìm đọc 5 bài nghiên cứu liên quan.
Rồi sau 3 ngày… mình mệt quá. Và ý tưởng đó nằm yên trong một Google Doc mà mình không bao giờ mở lại.
Bạn có giống mình không?
“Nếu bạn không prototype, bạn đang làm sai”
Aparna Chennapragada — CPO của Microsoft, từng làm ở Google (Google Lens, Google Shopping) — nói thẳng trong Lenny’s Podcast:
“If you’re not prototyping and building to see what you want to build, I think you’re doing it wrong.”
Dịch nôm na: “Nếu bạn không thử làm ra thứ gì đó để xem mình thật sự muốn xây cái gì, bạn đang làm sai.”
Câu này đánh trúng mình vì nó đi ngược hoàn toàn với cách mình được dạy. Ở trường, mình học: lên kế hoạch → thực hiện → đánh giá. Một quy trình tuyến tính, gọn gàng, đẹp đẽ.
Nhưng với AI, quy trình đó… không work.
Tại sao kế hoạch “hoàn hảo” lại là kẻ thù?
Aparna giải thích một điều mà mình chưa bao giờ nghĩ tới: AI products không thể được thiết kế bằng spec trước. Bạn phải làm thử trước, rồi mới biết nó nên trông như thế nào.
Tại sao? Vì AI không predictable như phần mềm truyền thống. Bạn gõ 1+1 vào máy tính, nó ra 2. Mỗi lần. Nhưng bạn hỏi AI cùng một câu 3 lần, bạn được 3 câu trả lời khác nhau.
Thế thì làm sao bạn viết spec cho một thứ mà kết quả thay đổi mỗi lần?
Câu trả lời: bạn không viết spec. Bạn prototype.
Mình thử áp dụng điều này. Thay vì dành 3 ngày lên kế hoạch cho một bài giảng về essay writing có tích hợp AI, mình dành 30 phút ngồi thử. Mình mở ChatGPT và đóng vai học sinh. Mình hỏi nó những câu mà học sinh mình hay hỏi. Mình xem nó trả lời như thế nào.
30 phút đó cho mình nhiều insight hơn 3 ngày lên kế hoạch.
NLX: Khi ngôn ngữ trở thành giao diện mới
Aparna còn giới thiệu một khái niệm làm mình ngẫm nghĩ mấy ngày: NLX — Natural Language Interface.
“NLX is the new UX.” (Giao diện ngôn ngữ tự nhiên là trải nghiệm người dùng mới.)
Trước đây, khi bạn dùng một app, bạn nhấn nút, kéo menu, chọn option. Đó là UX truyền thống — giao diện đồ họa.
Giờ, bạn nói chuyện với app. Bạn gõ: “Tóm tắt email này” hay “Viết cho tôi một email trả lời lịch sự.” Đó là NLX.
Nhưng — và đây là phần hay — Aparna nói rằng conversation cũng có thiết kế. Nó không phải là “cứ để AI tự nói.” Cuộc hội thoại cũng có cấu trúc, có “grammar”, có nguyên tắc.
Mình liên tưởng ngay đến dạy học. Một buổi dạy kèm 1-1 với học sinh không phải là “nói tự do.” Nó có mở đầu (warm-up), có phần chính (practice), có kết (reflection). Nhìn qua thì đơn giản, nhưng thực ra mình đã thiết kế cuộc hội thoại đó cẩn thận.
AI product cũng vậy. Bạn không chỉ ném một chatbox vào app rồi gọi đó là “tích hợp AI.” Bạn phải thiết kế cuộc hội thoại — giống như thiết kế một bài giảng.
Bài học từ… stand-up comedy
Phần mình thích nhất trong podcast này là khi Aparna so sánh việc làm AI product với stand-up comedy.
Comedian không viết một set hoàn hảo rồi lên sân khấu. Họ đi đến những quán bar nhỏ, thử joke trước 20 người. Nếu không ai cười, họ sửa. Thử lại. Sửa lại. Thử lại.
Đó chính xác là cách bạn nên build AI product: thử nhỏ, đo phản ứng, sửa nhanh, lặp lại.
Và đó cũng chính xác là cách mình đang viết blog này. Bài viết đầu tiên của mình tệ lắm. Nhưng mình viết. Rồi sửa. Rồi viết bài khác. Mỗi bài tốt hơn bài trước một xíu.
💡 Insight: Đừng chờ cho đến khi bạn có kế hoạch hoàn hảo. Hãy làm một prototype — xấu cũng được, sai cũng được — rồi cải thiện từ đó. Bạn sẽ học được nhiều hơn từ 30 phút thử nghiệm so với 3 ngày lên kế hoạch.
Framework: Prototype trong 30 phút
Nếu bạn có một ý tưởng muốn thử với AI, đây là cách mình làm:
1. Đặt timer 30 phút — Không hơn. Giới hạn thời gian buộc bạn tập trung vào cốt lõi, không phải chi tiết.
2. Làm phiên bản xấu nhất có thể — Nghiêm túc. Đừng cố đẹp. Cứ chạy được là OK.
3. Cho một người thử — Chỉ MỘT người. Hỏi họ: “Cái này có giải quyết vấn đề gì cho bạn không?”
4. Ghi lại 3 điều bất ngờ — Luôn có ít nhất 3 thứ bạn không lường trước. Đó mới là data thật.
Mình áp dụng framework này cho bài giảng, cho tool nội bộ, thậm chí cho cách viết blog. Và mỗi lần, mình đều ngạc nhiên vì thực tế khác xa tưởng tượng.
Kế hoạch không sai. Nhưng kế hoạch không đủ.
Mình không nói bạn đừng bao giờ lên kế hoạch. Mình nói: đừng để kế hoạch thay thế hành động.
Aparna nói nếu bạn không prototype, bạn sẽ có “a Frankenstein product” — một sản phẩm chắp vá, không ra hình thù gì.
Nhưng mình nghĩ ngược lại: nếu bạn chỉ lên kế hoạch mà không prototype, bạn sẽ có không gì cả. Một Google Doc hoàn hảo mà không ai đọc.
Mình đã có quá nhiều Google Doc như vậy rồi. 😅
Bạn đang ấp ủ ý tưởng gì mà chưa thử? Hãy dành 30 phút hôm nay, làm một phiên bản xấu nhất có thể. Rồi hỏi 1 người: “Cái này có giải quyết gì cho bạn không?” Kết quả sẽ bất ngờ lắm đấy. ☕
