Cách quyết định nên xây tính năng nào từ phản hồi người dùng (và bỏ qua tính năng nào)
Khi mọi người bắt đầu dùng app của bạn, các yêu cầu sẽ ùa về. Đây là một cách đơn giản để quyết định phản hồi nào đáng xây bằng công cụ tạo app bằng AI, cái nào nên gác lại, và cái nào nên lịch sự từ chối.
Vài tuần đầu sau khi mọi người bắt đầu dùng app của bạn thường khá yên ắng. Rồi tin nhắn bắt đầu kéo đến. “Bạn thêm chế độ tối được không?” “Sẽ tuyệt lắm nếu tôi có thể xuất ra PDF.” “Bạn đổi nút thành màu xanh được không?” “Chúng tôi rất cần tích hợp với công cụ chúng tôi đang dùng.” Chỉ trong vòng một tháng, bạn có một danh sách bốn mươi thứ, và một công cụ tạo app bằng AI sẵn sàng xây bất kỳ thứ nào trong số đó cho bạn chỉ trong một buổi chiều.
Vế cuối đó chính là cái bẫy. Khi xây mỗi tính năng đều rẻ và nhanh, câu hỏi khó không còn là “tôi có xây được không?” mà trở thành “tôi có nên làm không?” Nút thắt cổ chai chuyển từ đôi tay của bạn sang khả năng phán đoán của bạn, và chẳng ai phát cho bạn một cuốn cẩm nang về chuyện đó cả.
Bài viết này là một cách đơn giản để phân loại phản hồi đến thành ba nhóm — xây nó, gác lại, bỏ qua — mà không cần bạn có nền tảng về quản lý sản phẩm. Mục tiêu không phải là nói không với mọi người. Mà là đảm bảo những thứ bạn thật sự xây là những thứ thực sự đưa app của bạn tiến lên.
Vì sao “cứ xây thôi” không còn hiệu quả
Với mười tính năng đầu tiên, “cứ xây bất cứ thứ gì ai đó yêu cầu” là một chiến lược ổn. Bạn chưa có đủ người dùng để có những ý kiến trái chiều, và mỗi tính năng đều làm app hữu dụng hơn so với cái thứ trống trơn của tuần trước.
Nó hết hiệu quả vào khoảng lúc bạn có những người dùng thật sự, khác nhau. Một freelancer muốn một đằng, một agency nhỏ muốn ngược lại, còn một người ghé qua một lần thì muốn thứ mà cả hai người kia sẽ chẳng bao giờ dùng. Xây cả ba và app của bạn biến thành một ngăn kéo chứa đồ linh tinh — đầy thứ, khó tìm được cái gì, nặng nề để mang theo. Mỗi tính năng bạn thêm vào là một tính năng bạn phải giữ cho chạy mãi mãi, phải giải thích cho người dùng mới, và phải không làm hỏng khi bạn thay đổi thứ gì đó gần đó.
Một công cụ tạo app bằng AI làm chuyện này tệ hơn trước khi nó làm tốt hơn, vì nó gỡ bỏ cái phanh tự nhiên. Khi một tính năng tốn của lập trình viên hai tuần, bạn đã cân nhắc rất kỹ liệu nó có đáng hai tuần đó không. Khi nó chỉ tốn của công cụ hai mươi phút, bạn chẳng cân nhắc gì cả — bạn cứ thế gật đầu. Cái giá không hề biến mất. Nó chuyển từ “thời gian để xây” thành “sức nặng để mang”, và sức nặng thì khó thấy hơn.
Ba câu hỏi phân loại được gần như mọi thứ
Khi một yêu cầu đến, hãy cho nó đi qua ba câu hỏi theo thứ tự. Phần lớn mọi thứ tự phân loại được sau hai câu đầu.
1. Cái này có giúp ích cho những người tôi xây app này cho họ không? Bạn xây app cho một ai đó cụ thể — nhiếp ảnh gia chụp cưới, huấn luyện viên bóng đá thiếu nhi, người làm podcast độc lập. Một yêu cầu từ một trong những người này đáng giá hơn một yêu cầu từ ai đó tình cờ lạc vào và sẽ chẳng bao giờ quay lại. Nếu một tính năng giúp những người cốt lõi của bạn làm được điều chính họ tìm đến, nó được xếp lên gần đầu. Nếu nó giúp một người ghé qua mà không thực sự là người dùng của bạn, nó được xếp xuống gần cuối, dù họ có hỏi to đến đâu.
2. Thực tế sẽ có bao nhiêu người dùng nó? Không phải “ai yêu cầu nó” — mà ai sẽ thật sự dùng nó. Một người hỏi to không giống với mười người sẽ âm thầm hưởng lợi. Hãy thành thật ở đây, vì những yêu cầu ồn ào trông giống như những yêu cầu lớn, mà thường thì không phải. Một dấu hiệu hay: hỏi người đó hôm nay họ đang làm thế nào thay vào đó. Nếu họ có một cách xoay xở vụng về mà họ dùng hằng ngày, đó là một nhu cầu thật. Nếu họ “chắc thỉnh thoảng sẽ dùng”, thì đó chỉ là một thứ tốt-thì-có khoác lên một bộ đồ hóa trang.
3. Mang nó theo mãi mãi tốn của tôi cái gì? Một số tính năng thì nhẹ. Thêm một lựa chọn màu mới, đặt lại tên một nhãn, thêm một ô vào biểu mẫu — xây xong rồi quên đi. Một số tính năng thì nặng: bất cứ thứ gì dính đến thanh toán, bất cứ thứ gì gửi email đến người thật, bất cứ thứ gì thêm vào cả một khu vực mới với những quy tắc riêng của nó. Tính năng nặng không xấu, nhưng chúng phải xứng đáng với sức nặng của mình bằng cách vượt qua hai câu hỏi đầu một cách dư dả.
Ba nhóm
Cho các câu hỏi đó chạy qua và gần như mọi thứ sẽ rơi vào một trong ba chỗ.
Xây nó. Giúp ích cho những người cốt lõi của bạn, vài người trong số họ sẽ dùng nó, và cái giá để mang theo là hợp lý. Những cái này dễ. Cứ làm, và báo cho người đã yêu cầu — những người thấy ý tưởng của mình được hiện thực hóa sẽ trở thành những người dùng trung thành nhất của bạn, và là nguồn tốt nhất cho ý tưởng hay tiếp theo.
Gác lại. Ý hay đấy, nhưng hơi sớm, hoặc chỉ mới một người muốn, hoặc nó nặng và bạn còn chưa chắc. Đừng nói không và cũng đừng xây nó. Hãy ghi lại ở đâu đó mà bạn sẽ thật sự xem lại — một danh sách đơn giản, một ghi chú, một bảng. Nếu trong tháng tới có thêm ba người nữa hỏi cùng một thứ, thì nó tự thăng cấp lên nhóm xây và đã tự nói cho bạn biết rồi. Gác lại không phải là nghĩa địa; nó là phòng chờ.
Bỏ qua. Nó không phù hợp với mục đích của app, nó sẽ chỉ phục vụ đúng một người, hoặc nó sẽ làm app tệ hơn cho mọi người khác. Những cái này cần một lời từ chối lịch sự, thành thật. “Đó là một ý tưởng chu đáo, nhưng đây không phải thứ tôi định thêm vào — đây là điều tôi gợi ý thay thế” vừa giữ được mối quan hệ vừa bảo vệ được app. Nói không là một tính năng. Mỗi lần nói không là một lần nói có với việc giữ app đủ đơn giản để mọi người hiểu được.
Một ví dụ nhỏ
Một người chúng tôi quen điều hành một app đặt lịch cho giáo viên dạy nhạc, được xây hoàn toàn bằng một công cụ tạo app bằng AI. Trong một tuần, cô nhận được ba yêu cầu: một giáo viên muốn tự động nhắn tin nhắc nhở cho học viên, một phụ huynh muốn có cách xem tất cả các buổi học của con mình trong một màn hình, và một người muốn dịch app sang tiếng Latin “cho vui”.
Việc nhắc nhở vượt qua cả ba câu hỏi — người dùng cốt lõi, nhiều người trong số họ gặp cảnh học viên vắng mặt, và nhắn tin tuy nặng nhưng đáng làm. Xây. Màn hình cho phụ huynh là một ý hay từ một người, nên cô gác lại; hai phụ huynh nữa hỏi trong vòng ba tuần và nó tự thăng cấp. Việc dịch sang tiếng Latin nhận được một lời từ chối nhẹ nhàng. Không quyết định nào trong số đó cần đến một bảng tính. Chúng chỉ cần ba câu hỏi và sự sẵn lòng trả lời câu thứ ba một cách thành thật.
Phần không ai nói cho bạn
Phản hồi khó xử lý nhất không phải là những ý tưởng dở. Mà là những ý tưởng hay từ những người bạn quý mến, cho một app không thể là tất cả mọi thứ. Bỏ qua những thứ đó có cảm giác như đang làm người ta thất vọng. Không phải vậy đâu. Điều tử tế nhất bạn có thể làm cho những người dùng app của mình là giữ nó đủ tập trung để nó vẫn giỏi cái việc duy nhất mà họ đã tìm đến.
Lần tới khi các yêu cầu dồn lại, đừng mở công cụ tạo app bằng AI ra trước. Hãy mở danh sách của bạn, cho từng mục đi qua ba câu hỏi, và phân nó vào một nhóm. Việc xây giờ là phần dễ. Quyết định cái gì đáng xây mới là công việc thật sự — và đó là một công việc bạn có thể làm mà không cần viết một dòng code nào.