Chuyển đến nội dung
28 tháng 8, 2026 · Chiến lược sản phẩm

Nói chuyện với người dùng trước khi dựng là lãng phí thời gian của tất cả

Bài viết này mô tả sản phẩm tại thời điểm xuất bản. Xem AI BuilderAgent Teams để biết các tính năng hiện tại.

Nói chuyện với người dùng trước khi dựng là lãng phí thời gian của tất cả

Phần lớn nghiên cứu người dùng trước khi ra mắt là màn kịch, và phần tệ nhất là cả hai bên đều biết lời thoại của mình. Bạn hỏi "bạn có sử dụng thứ như thế này không," và người ở đầu dây bên kia — người đang lịch sự, không có gì để mất, đang tưởng tượng về một sản phẩm chưa tồn tại — trả lời có. Bạn ghi lại đó là sự xác nhận. Không phải vậy. Đó chỉ là một người lạ đang lịch sự về một giả thuyết.

Tôi từng thực hiện các cuộc phỏng vấn này một cách nghiêm túc, vì mọi cuốn sách chiến lược sản phẩm đều khuyên vậy. Nói chuyện với năm mươi người dùng trước khi viết một dòng code. Tìm ra điểm đau. Xác nhận vấn đề trước khi tìm giải pháp. Nghe có vẻ kỷ luật, và trông đẹp trên bảng trắng. Nhưng kết quả thực tế của mười cuộc gọi khám phá là mười người nói cho bạn nghe những gì họ nghĩ bạn muốn nghe, được lọc qua ký ức mơ hồ của chính họ về một vấn đề mà họ chưa nghĩ tới kể từ khi cuộc gọi bắt đầu. Không ai cố tình nói dối bạn. Họ chỉ chưa có thông tin đó — vì thông tin đó chưa tồn tại cho đến khi sản phẩm tồn tại.

Điều mà các cuộc phỏng vấn không thể tạo ra

Điều bạn thực sự cần biết trước khi xây dựng là hành vi, không phải thái độ: liệu một người có mở lại ứng dụng này lần thứ hai không, liệu họ có trả tiền cho nó không, liệu họ có bị mắc kẹt ở màn hình thứ ba rồi bỏ cuộc không. Không điều nào trong số đó xuất hiện trong một cuộc trò chuyện. Nó xuất hiện trong bản ghi lại phiên sử dụng, biểu đồ tỷ lệ bỏ dở, phiếu hỗ trợ. Một người dùng có thể nói với bạn hoàn toàn chân thành rằng quá trình giới thiệu "rất hợp lý," rồi bỏ cuộc sau bốn mươi giây, vì tự báo cáo và hành vi là hai công cụ khác nhau đo lường hai thứ khác nhau.

Trước đây yếu tố kinh tế buộc phải theo thứ tự phỏng vấn trước. Nếu xây dựng một thứ mất tám tuần và ba kỹ sư, bạn không thể chấp nhận việc phát hiện ra nó sai sau khi phát hành — vì vậy bạn dồn rủi ro lên trước bằng các cuộc trò chuyện rẻ tiền và hy vọng chúng bắt được những sai lầm tốn kém. Sự đánh đổi đó hợp lý khi việc xây dựng là điểm nghẽn. Giờ thì không còn nữa. Một nguyên mẫu hoạt động được — xác thực thật, cơ sở dữ liệu thật, giao diện mà ai đó thực sự có thể nhấp qua — giờ đây là thứ bạn có thể xây dựng trong một buổi chiều với các công cụ phù hợp, bao gồm cả công cụ của tôi. Khi chi phí cho phiên bản đầu tiên giảm xuống mức đó, cuộc phỏng vấn không còn là cách giảm rủi ro rẻ tiền nữa mà trở thành bước tốn kém. Bạn đang trả bằng hàng tuần lịch trình để tránh một lần xây dựng chỉ tốn một cuối tuần.

~2 giờ là thời gian trung vị để một người xây dựng đơn lẻ trên BuildMidas đi từ ý tưởng viết ra đến một ứng dụng trực tiếp, có thể nhấp được — thường ít hơn thời gian cần để sắp xếp năm cuộc phỏng vấn người dùng

Điều tôi làm thay vào đó

Xây dựng phiên bản thật nhỏ nhất của ý tưởng, đưa nó cho ba đến năm người thực sự có vấn đề đó, và quan sát, đừng hỏi. Không phải "bạn nghĩ gì" — mà con trỏ của họ do dự ở đâu, họ đã nhấp vào cái gì mà không có tác dụng gì, họ đã cố làm gì mà sản phẩm hoàn toàn không hỗ trợ. Điều cuối cùng đó chính là vàng: thứ họ cố gắng làm mà không được nhắc trước là tín hiệu chân thực hơn bất cứ điều gì họ có thể đã nói với bạn trong một cuộc phỏng vấn giả định, vì đó là sở thích được bộc lộ thay vì sở thích được nói ra.

Điều này đảo ngược phễu nghiên cứu truyền thống, và đáng để nói rõ điều gì thay đổi:

Phỏng vấn trướcXây dựng trước
Bạn đang đo lường điều gìÝ định được nêu ra ("Tôi có lẽ sẽ dùng cái này")Hành vi được bộc lộ (họ đã mở nó ba lần tuần này, hoặc không)
Chi phí khi saiThấp cho mỗi chu kỳ, nhưng bạn có thể sai suốt nhiều tháng qua hàng chục cuộc phỏng vấnMột chu kỳ xây dựng, sau đó dữ liệu sẽ nhanh chóng sửa sai cho bạn
Câu hỏi hay nhất nên đặt ra"Điều gì khiến bạn thấy khó chịu về cách bạn làm việc này hiện nay?""Cho tôi xem lần gần nhất bạn cố làm X ở đây"
Nó giỏi phát hiện điều gìLiệu vấn đề đó có thực sự tồn tại hay khôngLiệu giải pháp cụ thể của bạn cho vấn đề đó có hiệu quả hay không
Kiểu thất bạiAi cũng lịch sự, không ai thành thật, và bạn tự tin xây dựng sai thứBạn ra mắt một thứ còn thô sơ trước khi kịp gây dựng lòng tin, và nó để lại ấn tượng đầu xấu

Hãy để ý rằng hai hàng này không triệt tiêu lẫn nhau — chúng trả lời hai câu hỏi khác nhau. Phỏng vấn khá tốt trong việc xác nhận một vấn đề là có thật. Nhưng lại kém trong việc cho bạn biết giải pháp cụ thể của bạn có đúng hay không, vì giải pháp cụ thể đó chưa hề tồn tại để ai đó có thể phản ứng thành thật với nó. Đó là điểm khác biệt mà hầu hết lời khuyên "hãy nói chuyện với người dùng" thường lờ đi: đó thường là lời khuyên tốt cho việc khám phá vấn đề, nhưng là lời khuyên tồi cho việc kiểm chứng giải pháp, còn người ta thì lại áp dụng nó cho cả hai.

Một nhà sáng lập tôi quen đã thực hiện mười bốn cuộc phỏng vấn cho một công cụ lên lịch dành cho tiệm làm tóc. Mười ba người nói rằng vấn đề đặt lịch trùng là có thật và gây phiền toái. Cô ấy đã xây dựng nó. Mức độ sử dụng không nhích lên. Hóa ra các chủ tiệm ghét việc đặt lịch trùng về mặt lý thuyết nhưng đã tự xây những cách đối phó tạm bợ mà họ không muốn từ bỏ — điều mà không ai trong số họ nhắc đến, vì chẳng ai nghĩ đến việc mô tả cách họ đang xoay xở trừ khi bạn cho họ thấy một giải pháp thay thế và quan sát họ từ chối nó.

Chỗ nào những người phản đối có lý

Điều này không đúng trong mọi trường hợp, và tôi sẽ nói quá nếu giả vờ như vậy. Nếu việc xây dựng thực sự tốn kém để đảo ngược — phần cứng, một quy trình y tế phải tuân thủ quy định, bất cứ thứ gì kèm theo một đợt rà soát tuân thủ cho mỗi thay đổi — thì phép tính ưu tiên phỏng vấn trước lại quay trở lại đúng, bởi vì thế bất cân xứng về chi phí khiến việc xây dựng trước trở nên rẻ đơn giản là không đúng ở đó. Một bản thử nghiệm mà bạn có thể vứt bỏ trong một buổi chiều là một thứ hoàn toàn khác so với một thiết bị mà bạn đã làm khuôn đúc riêng.

Nơi khác mà nghiên cứu xứng đáng được thực hiện là bán hàng doanh nghiệp với chu kỳ dài. Nếu người mua của bạn là một hội đồng thu mua và chu kỳ bán hàng của bạn kéo dài bốn tháng, bạn không thể "cứ ra mắt rồi quan sát" để có được hợp đồng đã ký — bạn cần biết trước khi xây dựng liệu sản phẩm có vượt qua được một đợt rà soát bảo mật hay không, vì một thương vụ bị từ chối sau sáu tháng tốn kém hơn rất nhiều so với bất kỳ cuộc phỏng vấn nào. Và việc khám phá vấn đề thuần túy, được thực hiện sớm và ít tốn kém — ngồi cùng ai đó khi họ làm công việc thực tế của mình, chứ không phải yêu cầu họ tưởng tượng về một sản phẩm tương lai — thực sự bị đánh giá thấp và thực sự hữu ích. Tôi không phản đối việc nói chuyện với mọi người. Tôi phản đối việc coi một cuộc trò chuyện giả định lịch sự là bằng chứng, trong khi một bản dựng thô sơ nhưng thực tế đặt trước mặt cùng người đó trong mười phút sẽ cho bạn biết sự thật thay vì thế.

Chiến lược sản phẩm
Chia sẻXLinkedInFacebookRedditQuoraWhatsAppTelegramEmail
← Tất cả bài viết