Những tính năng chúng tôi đã xây nhưng quyết định gác lại: Bài học về việc ưu tiên sản phẩm
Cái bẫy của "feature factory"
Một trong những cạm bẫy phổ biến nhất trong phát triển sản phẩm là trở thành "feature factory" — đội ngũ liên tục xây tính năng mới, release đều đặn, nhưng sản phẩm không thực sự tốt hơn với người dùng. Số lượng tính năng tăng lên, nhưng tỷ lệ người dùng thực sự dùng chúng thì không.
Chúng tôi đã rơi vào bẫy đó ít nhất hai lần. Và mỗi lần là một bài học đắt giá — không phải về tiền, mà về thời gian và sự tập trung.
Tính năng thứ nhất: Bảng Gantt Chart
Khoảng 6 tháng sau khi ra mắt, chúng tôi nhận được nhiều yêu cầu về Gantt Chart — biểu đồ thanh ngang thể hiện timeline dự án mà nhiều công cụ project management nổi tiếng đều có. Nghe hợp lý: người dùng muốn, có sẵn ví dụ để tham khảo, đội dev có thể xây được.
Chúng tôi xây Gantt Chart trong 6 tuần. Xây xong rồi bắt đầu test với người dùng thực — và nhận ra một điều: chỉ một phần nhỏ người dùng thực sự cần nó, và trong số đó, hầu hết chỉ cần nó để trình bày cho sếp hoặc khách hàng, không phải để quản lý công việc hàng ngày.
Vấn đề thật sự của họ không phải là thiếu Gantt Chart — mà là thiếu cách trình bày tiến độ dự án cho bên ngoài một cách rõ ràng. Hai vấn đề đó cần hai giải pháp khác nhau, và Gantt Chart chỉ giải quyết một phần rất nhỏ của câu chuyện.
Chúng tôi gác tính năng này lại — không xóa, nhưng không ưu tiên cải thiện thêm. Điều đó giải phóng 6 tuần cho những thứ quan trọng hơn.
Tính năng thứ hai: AI tự động tạo task từ email
Ý tưởng nghe rất hay: AI đọc email đến, tự động nhận diện các yêu cầu và tạo task tương ứng, không cần người dùng làm gì. "Zero friction" hoàn toàn.
Chúng tôi xây prototype trong 4 tuần và test với một nhóm người dùng. Kết quả: AI tạo ra rất nhiều task — phần lớn là task mà người dùng không muốn tạo. Email "Cảm ơn anh đã chia sẻ tài liệu" tạo ra task "Chia sẻ tài liệu". Email mời họp tạo ra task "Tham dự họp". Cuối cùng người dùng phải dành thời gian xóa các task thừa — tốn thời gian hơn là tự tạo task từ đầu.
Vấn đề là chúng tôi đã giải sai bài toán. Người dùng không muốn AI xử lý tất cả email cho họ — họ muốn tự quyết định email nào cần tạo task, và chỉ cần bước đó đơn giản hơn. Kết quả là chúng tôi giữ lại luồng "chuyển email thành task bằng 1 thao tác" và bỏ phần AI tự động hoàn toàn — đơn giản hơn, nhưng người dùng hài lòng hơn nhiều.
Bài học rút ra
1. "Người dùng yêu cầu" không đồng nghĩa với "người dùng sẽ dùng"
Khi hỏi "bạn có muốn tính năng X không?", câu trả lời gần như luôn là "có". Nhưng khi thực sự dùng nó trong công việc hàng ngày, nhiều người nhận ra họ không cần đến nó thường xuyên như họ nghĩ. Sự khác biệt giữa "muốn" và "sẽ dùng hàng ngày" là khoảng cách mà nhiều sản phẩm thất bại trong đó.
2. Tính năng tốt nhất đôi khi là tính năng bạn không xây
Mỗi tính năng thêm vào là thêm complexity — cho người dùng phải học, cho đội dev phải maintain, cho hệ thống phải gánh. Sản phẩm tốt không phải là sản phẩm có nhiều tính năng nhất, mà là sản phẩm làm tốt nhất những thứ người dùng thực sự làm mỗi ngày.
3. Xây prototype nhanh và test trước khi commit
Bài học đau nhất từ Gantt Chart là chúng tôi đã xây hoàn chỉnh (6 tuần) trước khi test. Lần sau, với AI email automation, chúng tôi xây prototype trong 2 tuần và test ngay — phát hiện vấn đề sớm hơn và tiết kiệm được 2-3 tuần công sức.
Cách chúng tôi quyết định bây giờ
Trước khi commit xây một tính năng mới, chúng tôi tự hỏi 3 câu:
- Người dùng gặp vấn đề gì cụ thể? (không phải "họ muốn tính năng gì")
- Có bao nhiêu người thực sự gặp vấn đề này mỗi tuần?
- Nếu chúng tôi không xây tính năng này, họ đang giải quyết vẫn đề đó bằng cách nào?
Nếu không trả lời được câu 1 và 2 một cách cụ thể, chúng tôi chưa hiểu đủ về vấn đề để bắt đầu xây.