Tháng trước, một product designer khoe với tôi prototype mới của cô ấy. Cô dành hai tuần vibe-coding một công cụ theo dõi “thói quen viết nhật ký biết ơn mỗi ngày”.
Giao diện rất đẹp.
Có hiệu ứng confetti khi bạn duy trì được 7 ngày liên tiếp.
Thông báo nhẹ nhàng, tinh tế.
Rồi cô mang nó đi test với người dùng.
“Tôi không có thói quen viết nhật ký,” người đầu tiên nói.
“Viết nhật ký biết ơn nghe hơi… làm màu,” người thứ hai chia sẻ.
“7 ngày liên tiếp là gì?” người thứ ba hỏi lại.
Hai tuần xây dựng. Sai vấn đề.
Và cô chuẩn bị dành thêm vài tuần nữa để xây một thứ khác — có thể lại tiếp tục sai.
Cô gọi quá trình đó là “need-finding” (đi tìm nhu cầu).
Nhưng thực ra, nó không phải vậy.
Phân Biệt Rất Quan Trọng
Need-finding (tìm nhu cầu) xảy ra trước khi bạn có giải pháp.
Bạn lắng nghe mọi người kể về cuộc sống của họ, những bực bội, những cách họ tự xoay xở. Bạn đang tìm xem vấn đề nào thực sự tồn tại — đủ nghiêm trọng để họ phải tự giải quyết bằng Excel, Google Docs, ghi chú dán tường, hay đủ thứ chắp vá khác.
Validation xảy ra sau khi bạn đã có một giả thuyết.
Bạn đang kiểm tra xem giải pháp cụ thể của mình có giải quyết đúng một vấn đề có thật hay không.
Đưa cho ai đó một prototype hoàn chỉnh rồi nhìn họ nhún vai không phải là nghiên cứu người dùng.
Đó là một cách tốn thời gian và tiền bạc để phát hiện ra rằng bạn đoán sai.
Và khi họ nhún vai, bạn không biết mình nên giải quyết vấn đề gì thay vào đó. Bạn chỉ biết lần này mình đoán sai.
Vì Sao Vibe-Coding Khiến Mọi Thứ Tệ Hơn
Tôi hiểu. Vibe-coding rất đã.
Bạn mô tả ý tưởng. Code xuất hiện. Mọi thứ trông như đang tiến triển.
Cảm giác “mình đang build” đó rất dễ gây nghiện.
Nhưng nó cũng là cái bẫy.
Bạn đang tích lũy những thứ nhìn có vẻ như thành quả — nhưng có thể chẳng liên quan gì đến nhu cầu thật sự của ai cả.
Con đường nhanh thực sự lại không hào nhoáng:
Ngồi xuống với 5–10 người.
Hỏi họ về cuộc sống, công việc, những thứ làm họ khó chịu.
Im lặng và lắng nghe.
Và mỗi khi có điều gì đó đáng chú ý xuất hiện, hãy nói:
“Bạn kể rõ hơn được không?”
Đừng show sản phẩm.
Đừng pitch ý tưởng.
Chỉ lắng nghe.
Khi bạn nghe cùng một nỗi bực bội lặp lại từ nhiều người.
Khi bạn hiểu họ đang tự xoay xở ra sao.
Lúc đó mới bắt đầu xây.
Bạn sẽ build ít hơn.
Nhưng build đúng hơn.
Phỏng Vấn Người Dùng Thực Sự Là Như Thế Nào
Kỹ năng cốt lõi: coi buổi phỏng vấn là một cuộc trò chuyện, không phải bảng khảo sát.
Bản năng của chúng ta là viết sẵn câu hỏi rồi đi theo checklist. Nhưng giá trị thật nằm ở câu hỏi tiếp nối.
Khi ai đó nói:
“Tôi không dùng phần mềm quản lý công việc nào cả.”
Đừng chuyển sang câu hỏi tiếp theo.
Hãy hỏi:
“Vì sao vậy?”
“Bạn kể rõ hơn được không?”
Và bạn có thể phát hiện ra họ đã thử 3 công cụ rồi bỏ hết. Hoặc họ tự xây một hệ thống phức tạp trong Google Docs vì chẳng công cụ nào phù hợp.
Insight thật sự nằm ở phần đào sâu đó.
“Vấn Đề Đúng” Là Gì?
Cụm từ “tìm đúng vấn đề” nghe thì hay, nhưng hiếm khi được định nghĩa rõ ràng.
Thực tế, nó có nghĩa là:
-
Với UX: Một vấn đề người ta đủ quan tâm để họ đã chủ động tìm cách giải quyết.
-
Với Product: Một vấn đề người ta sẵn sàng bỏ tiền để được giải quyết.
-
Với Business: Một vấn đề đủ nhiều người gặp phải, công ty bạn có khả năng giải quyết, và phù hợp với thương hiệu cũng như năng lực của bạn.
Một vấn đề thỏa mãn cả ba điều này là hiếm.
Vì vậy, việc dành thời gian tìm nó trước khi bắt tay build là hoàn toàn xứng đáng.
Prototype vibe-coding có thể rất đẹp.
Nhưng nếu nó giải quyết một vấn đề không ai gặp phải,
hoặc một vấn đề không ai sẵn sàng trả tiền,
hoặc một vấn đề không phù hợp với bạn —
thì việc bạn build nhanh đến đâu cũng không còn quan trọng nữa.