Bạn ra mắt một thứ gì đó, mọi người bắt đầu sử dụng, và trong vòng một tuần các tin nhắn bắt đầu đổ về. Một đánh giá một sao ghi "khó hiểu". Một tin nhắn riêng hỏi "có thể làm thêm X không". Một ticket hỗ trợ thực chất chỉ là ai đó than phiền về một nút bấm họ không tìm thấy. Đây là vấn đề tốt — nó nghĩa là mọi người đủ quan tâm để nói cho bạn biết có gì đó sai. Nhưng đây cũng là lúc hầu hết người xây dựng âm thầm khiến mọi thứ tệ hơn, vì biến một phản hồi thành một câu lệnh nghe có vẻ đơn giản, nhưng gần như chẳng bao giờ đơn giản.
Tôi đã chứng kiến rất nhiều sản phẩm trở nên tệ hơn sau khi ra mắt, chứ không tốt lên, và hiếm khi là vì phản hồi tồi. Đó là vì những gì xảy ra giữa lúc đọc tin nhắn và lúc gõ câu lệnh tiếp theo. Ba khuôn mẫu này lặp đi lặp lại nhiều lần.
Sai lầm một: xây dựng đúng những gì họ gõ
Một người dùng nói "tôi ước có nút chuyển chế độ tối ở header." Thế là bạn mở chat xây dựng và gõ: "thêm nút chuyển chế độ tối ở header." Công cụ làm đúng như vậy. Ticket đóng, đúng không?
Nhưng người dùng đó không thực sự muốn một nút chuyển ở header — họ muốn ứng dụng ngừng làm hại mắt họ vào ban đêm. Có thể họ muốn nó tự động theo cài đặt hệ thống và không bao giờ phải nghĩ đến nữa. Có thể vấn đề thực sự là nền của bạn trắng chói mắt, và nút chuyển kia chỉ là giải pháp tạm họ nghĩ ra vì không biết còn cách nào khác để yêu cầu. Người dùng rất giỏi mô tả triệu chứng nhưng lại không đáng tin khi kê đơn giải pháp, vì họ không biết cái gì dễ hay khó để xây dựng, và họ không nghĩ đến mười hai chỗ khác trong ứng dụng mà nút chuyển đó cần phải được áp dụng theo.
Hậu quả ở đây chồng chất dần. Bạn nhận năm yêu cầu tính năng trong một tuần, bạn triển khai cả năm theo nghĩa đen, và giờ bạn có một bảng cài đặt với nút chuyển chế độ tối, nút chuyển "chế độ gọn", nút chuyển "ẩn sidebar", và một ô tick "chế độ đơn giản" mâu thuẫn nửa vời với ba cái kia. Không ai yêu cầu một bảng cài đặt cả. Bạn vẫn xây dựng nó, từng yêu cầu theo nghĩa đen một, và giờ mỗi tính năng mới đều phải được kiểm tra với vô số tổ hợp trạng thái nút chuyển mà chẳng ai nhớ đã bật.
Yêu cầu là dữ liệu. Nó không phải là bản đặc tả. Công việc của bạn là bước diễn giải ở giữa, và bỏ qua bước đó là cách phổ biến nhất khiến phản hồi biến thành phình to tính năng.
Sai lầm hai: im lặng, rồi dồn hết vào một lần
Sai lầm ngược lại trông có vẻ kỷ luật khi nhìn từ bên ngoài. Bạn không phản ứng với mọi tin nhắn ngay khi nó đến — phần lớn là bản năng tốt. Nhưng rồi bạn để hai tuần ticket chất đống trong một bảng tính, và một sáng thứ Bảy nào đó bạn ngồi xuống viết một câu lệnh khổng lồ duy nhất: "sửa lỗi thanh toán, thêm tính năng xuất dữ liệu, làm lại luồng onboarding, sửa nav trên di động, và cập nhật nội dung trang giá."
Công cụ xây dựng sẽ cố hết sức, nhưng bạn vừa yêu cầu năm thay đổi không liên quan phải diễn ra trong một lần, trên một codebase mà năm thứ đó có khả năng chạm vào những file trùng nhau. Khi có thứ gì đó hỏng — và với một thay đổi lớn như vậy, thường sẽ có — bạn không thể biết yêu cầu nào trong năm cái đã gây ra. Lịch sử phiên bản của bạn chỉ hiện một diff khổng lồ duy nhất thay vì năm diff có thể xem xét riêng lẻ. Nếu bạn cần rollback lại bản sửa thanh toán vì nó gây ra một hồi quy, bạn cũng đang rollback luôn cả phần làm lại onboarding vốn đang chạy tốt. Bản ghi kiểm chứng cho lần chạy đó là một bức tường thay đổi mà không ai, kể cả bạn, sẽ đọc từng dòng.
Gộp lại nghe có vẻ hiệu quả. Nhưng thực ra nó là điều ngược lại ngay khi có bất cứ thứ gì trong lô đó bị lỗi, vì lúc này debug nghĩa là gỡ rối năm luồng thay vì theo dõi một luồng duy nhất.
Sai lầm ba: để tin nhắn ồn ào nhất định hình lộ trình sản phẩm
Đây là sai lầm khó nhận ra nhất trong lúc bạn đang mắc phải nó. Một người dùng gửi một email giận dữ, chi tiết, viết mạch lạc về một tính năng họ muốn. Nó được viết tốt, cụ thể, rõ ràng mất mười phút để soạn — và mười phút chú ý thật sự của ai đó nghe có vẻ xứng đáng với mười phút của bạn. Thế là bạn bỏ dở việc đang làm và xây dựng nó.
Trong khi đó bốn mươi người dùng thầm lặng khác gặp phải đúng bước đăng ký gây khó hiểu đó mỗi tuần và đơn giản là rời đi. Không ai trong số họ viết cho bạn một đoạn văn về việc đó. Họ không gửi gì cả — họ chỉ không quay lại, và sự im lặng đó chẳng bao giờ xuất hiện trong hộp thư đòi bạn phản hồi. Độ mới và số lượng từ ngữ không giống với mức độ quan trọng, nhưng chúng cảm giác giống vậy, đặc biệt vào lúc 11 giờ đêm khi một tin nhắn đang nằm trước mặt bạn còn bốn mươi lượt không chuyển đổi thì nằm trong một bảng phân tích bạn chưa mở ra.
| Sai lầm | Biểu hiện | Hậu quả |
|---|---|---|
| Triển khai theo nghĩa đen | Đưa nguyên văn từ người dùng đã dùng vào câu lệnh mà không xem xét lại | Phình to tính năng, các nút chuyển mâu thuẫn nhau, bảng cài đặt lan tràn |
| Gộp và dồn yêu cầu | Im lặng, rồi một câu lệnh khổng lồ gộp nhiều yêu cầu | Diff khó xem xét, khó rollback, hồi quy bí ẩn |
| Lộ trình theo tiếng nói ồn ào nhất | Phản ứng theo người gửi email gần nhất hoặc mạnh mẽ nhất | Chạy theo các trường hợp ngoại lệ trong khi điểm gây rời bỏ thực sự vẫn không được xử lý |
Prompt đúng thực sự trông như thế nào
Cách khắc phục không phải là một sơ đồ quy trình, mà là một thói quen: đọc tin nhắn, rồi tự hỏi điều gì thực sự nằm bên dưới trước khi động vào build chat. Khi người dùng yêu cầu dark mode xuất hiện, nhu cầu thực sự thường là "giảm mỏi mắt vào ban đêm", và câu trả lời rẻ hơn, tốt hơn thường là "tôn trọng cài đặt color scheme ở cấp hệ điều hành" — chỉ một dòng, không có UI mới, không có toggle nào phải bảo trì. Khi năm ticket xuất hiện trong một tuần, hãy tìm ra mẫu hình trước khi viết bất cứ điều gì: nếu ba trong số đó thực ra là cùng một sự nhầm lẫn được mô tả theo ba cách khác nhau, đó là một prompt, không phải ba.
Giữ mỗi thay đổi chỉ phục vụ một mục đích duy nhất, ngay cả khi bạn đang muốn tăng tốc. "Sửa lỗi checkout khiến người dùng khách mất giỏ hàng khi refresh" là một prompt bạn có thể kiểm chứng trong một lượt và rollback sạch sẽ nếu sai. Nó cũng cho bạn một version card có ý nghĩa sau sáu tuần, thay vì một dòng changelog chỉ ghi "various fixes".
Và hãy cân nhắc phản hồi theo mẫu hình, không theo mức độ cảm xúc. Một lời phàn nàn ngắn gọn, thẳng thắn mà ba người dùng khác cũng gặp phải xứng đáng được đưa vào prompt tiếp theo hơn là một yêu cầu hùng hồn từ ai đó mô tả một quy trình làm việc mà không ai khác sử dụng. Đây là lúc việc thực sự quan sát cách sử dụng — nơi mọi người bỏ cuộc, họ nhấp vào đâu trước khi rời đi — phát huy tác dụng, vì nó cho bạn biết đa số thầm lặng đang làm gì trong khi thiểu số ồn ào đang gửi email cho bạn.
Không có điều nào ở đây có nghĩa là bỏ qua những người dùng dành thời gian viết thư cho bạn. Nó có nghĩa là đừng để "ai viết cho tôi gần đây nhất và thuyết phục nhất" trở thành thuật toán quyết định điều gì sẽ được xây dựng tiếp theo. Tin nhắn là điểm khởi đầu của cuộc trò chuyện, không phải là ticket. Việc chuyển đổi từ những gì ai đó nói sang những gì bạn thực sự yêu cầu người xây dựng làm vẫn là việc của bạn, mỗi lần đều vậy.
