Khi có một danh sách dài các tính năng, đội ngũ dễ rơi vào cảnh ai cũng muốn phần của mình được làm trước. Nếu không có cách chọn rõ ràng, phiên bản đầu tiên sẽ phình to và trễ hạn. Bài viết này đưa ra một khung đơn giản để bạn chọn đúng nhóm tính năng cho MVP.
Vì sao ưu tiên lại khó
Mỗi tính năng nghe đều hợp lý khi đứng riêng. Vấn đề là nguồn lực của phiên bản đầu tiên có giới hạn, mà mục tiêu thì phải thật hẹp: kiểm chứng một giả định với chi phí thấp nhất.
Khó khăn thường không nằm ở việc nghĩ ra tính năng, mà ở việc dám bỏ đi những thứ "hay ho nhưng chưa cần". Một khung ưu tiên rõ ràng giúp việc bỏ bớt trở thành quyết định dựa trên tiêu chí, không phải cảm tính.
Bắt đầu từ vấn đề, không phải danh sách tính năng
Trước khi chấm điểm bất kỳ tính năng nào, hãy quay lại câu vấn đề đã chốt ở bước xác định đúng vấn đề sản phẩm. Mọi tính năng chỉ có ý nghĩa khi nó giúp người dùng giải quyết đúng vấn đề đó.
Nếu chưa có câu vấn đề rõ ràng, đừng vội xếp hạng tính năng — bạn đang xếp hạng trên nền mơ hồ. Hãy chốt vấn đề trước, rồi mới đưa danh sách tính năng vào khung bên dưới.
Khung ba tiêu chí để chấm điểm
Với mỗi tính năng, hãy chấm theo ba tiêu chí đơn giản. Thứ nhất, mức độ quan trọng với vấn đề: nếu bỏ nó, người dùng còn nhận được giá trị không. Thứ hai, tần suất dùng: người dùng chạm vào nó mỗi ngày hay một lần mỗi tháng. Thứ ba, chi phí xây: mất vài ngày hay vài tuần để làm xong.
Tính năng đáng làm đầu tiên là tính năng quan trọng, dùng thường xuyên và rẻ để xây. Tính năng quan trọng nhưng đắt thì tìm cách cắt nhỏ; tính năng rẻ nhưng không quan trọng thì để sang các phiên bản sau.
Để dễ so sánh giữa các tính năng, hãy chấm mỗi tiêu chí theo ba mức: cao, trung bình, thấp. Tính năng đạt cả ba mức cao thì đưa ngay vào phiên bản đầu; đạt hai mức cao thì cân nhắc; còn lại thì xếp sau. Cách chấm thô này đủ để lọc ra nhóm tính năng thật sự cần thiết, mà không cần đến công cụ phức tạp.
Nhóm tính năng thành ba lớp
Lớp một là nhóm bắt buộc: nếu thiếu, người dùng không thể hoàn thành việc chính. Lớp hai là nhóm tăng giá trị nhưng có thể hoãn: làm sản phẩm dễ dùng hơn, nhưng không chặn luồng chính. Lớp ba là nhóm chỉ nên làm sau khi đã có người dùng thật phản hồi.
Phiên bản đầu tiên chỉ nên chứa lớp một, cộng thêm một phần nhỏ lớp hai nếu thật sự rẻ. Điều này cũng đúng với tinh thần của bài MVP cần nhỏ, nhưng vẫn phải có ích: nhỏ ở phạm vi, có ích ở giá trị.
Những tính năng nên bỏ cho phiên bản đầu
Bốn nhóm thường bị cắt đầu tiên: trang quản trị nội bộ, cài đặt và tùy chỉnh nâng cao, báo cáo chuyên sâu, và tích hợp với nhiều hệ thống bên ngoài. Chúng có ích về lâu dài, nhưng không giúp kiểm chứng giả định ban đầu.
Quy tắc đơn giản: nếu một tính năng chỉ phục vụ cho chính đội ngũ của bạn chứ không cho người dùng đầu tiên, hãy hoãn nó lại. Người dùng đầu tiên quyết định sản phẩm có đáng tiếp tục hay không, không phải đội ngũ.
Khi nghi ngờ một tính năng có nên giữ hay không, hãy đặt câu hỏi ngược lại: điều tồi tệ nhất xảy ra nếu bản đầu không có nó là gì. Nếu câu trả lời chỉ là "người dùng phải chờ thêm một bước làm tay", đó là dấu hiệu an toàn để hoãn.
Giữ thứ tự ưu tiên ổn định khi đội ngũ phản biện
Sau khi xếp hạng xong, sẽ có người muốn thêm lại tính năng đã bị cắt. Hãy giữ khung tiêu chí làm trọng tài: bất kỳ đề xuất bổ sung nào cũng phải vượt qua ba tiêu chí trên và đẩy một tính năng khác ra khỏi lớp một.
Điều này biến cuộc tranh luận từ "tôi thích tính năng này" thành "tính năng này có giúp kiểm chứng vấn đề không". Nếu đội ngũ cần người dẫn dắt bước này, dịch vụ tư vấn sản phẩm của Auranium giúp bạn thống nhất thứ tự ưu tiên trong vài buổi làm việc.
Kết luận
Ưu tiên tính năng không phải việc làm một lần rồi xong, mà là một thói quen lặp lại theo từng vòng phát triển. Bắt đầu từ câu vấn đề, chấm theo ba tiêu chí, rồi nhóm thành ba lớp — bạn sẽ có một phiên bản đầu tiên đủ nhỏ để ra mắt nhanh và đủ ích để người dùng ở lại.