Sau cuộc họp với khách hàng, sales thêm hai yêu cầu vào Google Sheet. Support chuyển tiếp một đoạn chat Zalo về lỗi hiện tại. Founder đề nghị giữ một tính năng từ quý trước vì đã từng hứa sẽ xem xét. Không hạng mục nào tự biến mất, trong khi năng lực engineering của tháng tới đã kín.
Vấn đề không nằm ở việc đội thiếu ý tưởng. Roadmap đang chứa nhiều cam kết có nguồn gốc và mức độ chắc chắn khác nhau, nhưng tất cả lại được trình bày như những việc sẽ làm.
Một roadmap chỉ có bước thêm, không có bước loại bỏ
Đầu vào không đồng nhất
Một yêu cầu có thể đến từ khách hàng đang trả phí, khách hàng tiềm năng, kế hoạch kinh doanh hoặc lỗi của quy trình nội bộ. Nếu chỉ lưu tên tính năng, đội sẽ mất bối cảnh: ai cần, cần để làm gì và điều gì xảy ra nếu chưa làm.
Quyết định bị trì hoãn
Product ngại xóa vì chưa có đủ dữ liệu. Sales hiểu việc xuất hiện trên roadmap là cam kết. Engineering phải ước lượng lại một danh sách dài dù nhiều mục chưa gắn với mục tiêu hiện tại.
Phân biệt backlog, roadmap và cam kết giao hàng
Backlog có thể chứa vấn đề, ý tưởng và yêu cầu cần nghiên cứu. Roadmap chỉ nên thể hiện các kết quả hoặc phạm vi mà đội đang chủ động cân nhắc theo một khoảng thời gian. Cam kết giao hàng cần chặt hơn nữa: đã có phạm vi, điều kiện nghiệm thu, nguồn lực và người duyệt.
Khi ba lớp này dùng chung một bảng, trạng thái dễ bị hiểu sai. Một ý tưởng vừa ghi nhận có thể xuất hiện cạnh hạng mục đang phát triển. Trước khi loại bỏ tính năng, đội nên sửa cấu trúc lưu trữ: nguồn yêu cầu, vấn đề cần giải quyết, nhóm người dùng, bằng chứng hiện có, trạng thái quyết định và ngày xem xét lại.
Bài quy trình ghi nhận yêu cầu tính năng để ưu tiên roadmap mô tả cách chuẩn hóa đầu vào trước bước đánh giá.
Dùng cùng một bộ câu hỏi cho mọi hạng mục
Một tính năng không nên được giữ chỉ vì người đề xuất có chức vụ cao hoặc khách hàng nhắc lại nhiều lần. Đội cần xem yêu cầu đó có phục vụ mục tiêu sản phẩm hiện tại hay không, bằng chứng nhu cầu mạnh đến đâu và tổng chi phí sau khi phát hành là gì.
Chi phí không dừng ở số ngày viết code. Cần tính cả thiết kế, kiểm thử, dữ liệu, phân quyền, tài liệu, hỗ trợ và việc duy trì các nhánh hành vi khác nhau. Với tính năng dành riêng cho một khách hàng B2B, đội còn phải xem khả năng tái sử dụng và tác động tới kiến trúc chung. Khi nào nên làm tính năng riêng cho khách hàng B2B? đi sâu vào quyết định này.
Quy trình rà soát và đưa tính năng ra khỏi roadmap
1. Khôi phục bối cảnh của yêu cầu
Product ghi người đề xuất, nhóm người dùng, vấn đề và bằng chứng. Mục không còn truy được bối cảnh sẽ quay về backlog.
2. Đối chiếu với mục tiêu hiện tại
Mỗi hạng mục phải chỉ ra mục tiêu mà nó hỗ trợ. Nếu mục tiêu đã đổi, đội không gán cho tính năng một lý do mới chưa được kiểm chứng.
3. Kiểm tra bằng chứng nhu cầu
Phân biệt lời đề nghị, hành vi lặp lại, hợp đồng và dữ liệu sử dụng. Một phản hồi đơn lẻ chưa đủ để cam kết xây.
4. Ước lượng trách nhiệm sau phát hành
Engineering và vận hành cùng xem phụ thuộc, dữ liệu, phân quyền, hỗ trợ và chi phí duy trì.
5. Chọn trạng thái và người có quyền chốt
Product đề xuất giữ, đưa về backlog, gộp hoặc loại bỏ. Người phụ trách mục tiêu kinh doanh chốt xung đột lớn, engineering xác nhận ràng buộc kỹ thuật.
6. Thông báo quyết định và điều kiện xem xét lại
Sales và support nhận lý do, ảnh hưởng tới khách hàng và điều kiện có thể mở lại.
Điểm số có thể hỗ trợ so sánh, nhưng không thay thế thảo luận. Đội phải thống nhất định nghĩa và dẫn nguồn cho nhận định về nhu cầu, chi phí và mức độ phù hợp với mục tiêu.
Khi nào nên loại bỏ, khi nào nên đưa về backlog?
Nên loại bỏ khỏi danh sách đang quản lý khi
- Yêu cầu trùng với hạng mục khác và không có khác biệt về kết quả.
- Vấn đề không còn tồn tại do quy trình hoặc sản phẩm đã thay đổi.
- Hạng mục mâu thuẫn với hướng sản phẩm đã được chốt.
- Chi phí duy trì vượt quá lợi ích dự kiến và không có điều kiện mới để đánh giá lại.
Nên đưa về backlog khi
- Vấn đề có thật nhưng chưa phục vụ mục tiêu trong giai đoạn hiện tại.
- Bằng chứng còn yếu và cần thêm phỏng vấn hoặc dữ liệu sử dụng.
- Đội đang chờ phụ thuộc kỹ thuật, pháp lý hoặc dữ liệu cụ thể.
- Có điều kiện xem xét lại rõ ràng và người chịu trách nhiệm theo dõi.
Giao tiếp quyết định mà không tạo cam kết mới
Sales cần biết trạng thái và cách xử lý tình huống khách hàng, không nhận một quý giao hàng khi chưa có quyết định. Nếu hạng mục từng được truyền đạt như cam kết, người có thẩm quyền phải xác định tài khoản bị ảnh hưởng, nội dung thông báo và phương án thay thế trước khi cập nhật roadmap công khai.
Duy trì nhịp rà soát theo năng lực thực tế
Đội nên rà soát khi mục tiêu quý thay đổi, năng lực engineering giảm hoặc trước lúc cam kết với khách hàng lớn. Cuộc họp chỉ cần tập trung vào roadmap và những yêu cầu mới có khả năng đổi thứ tự ưu tiên.
Đầu ra gồm phạm vi được giữ, mục chuyển trạng thái, người cần thông báo và điều kiện xem xét lại. Nếu nhiều yêu cầu vẫn cạnh tranh, cách tổ chức phiên ra quyết định sản phẩm hằng tuần giúp tách phần chuẩn bị dữ liệu khỏi cuộc họp chốt.
Dịch vụ Product Consultant của Auranium hỗ trợ founder và đội sản phẩm làm rõ mục tiêu, rà bằng chứng và đưa ra khuyến nghị độc lập trước khi tiếp tục đầu tư xây dựng.