Ở hầu hết các đội sản phẩm, backlog là nơi sự khẩn cấp đến để chết. Mọi thứ đi vào đó đều từng khẩn cấp vào lúc được thêm vào — một lời phàn nàn của khách hàng, một yêu cầu từ đội bán hàng, một tính năng của đối thủ, một ý tưởng nội bộ. Sáu tháng sau, tất cả vẫn còn đó, vẫn có vẻ khẩn cấp, và chẳng ai biết chắc nên làm việc nào tiếp theo.
Vấn đề không nằm ở việc thiếu công cụ. Có hàng chục khung ưu tiên: RICE, MoSCoW, Kano, ICE, chấm điểm có trọng số. Vấn đề là phần lớn các khung này đòi hỏi một kiểu chính xác giả tạo — gán con số cho những thứ chưa biết — khiến chúng trông có vẻ chặt chẽ, trong khi thực chất chỉ là đem cảm tính (gut feel) đi qua một bảng tính cho khoác vẻ khách quan.
Điều thực sự hiệu quả thì đơn giản hơn: hai chiều, được đánh giá thành thật, và kỷ luật hành động theo kết quả.
Việc ưu tiên rút gọn về hai câu hỏi. Thứ nhất: tính năng này cải thiện được bao nhiêu kết quả mà chúng ta quan tâm? (Tác động.) Thứ hai: chúng ta tốn bao nhiêu chi phí để triển khai nó? (Nỗ lực.) Mọi thứ khác hoặc chỉ là sự tinh chỉnh của hai câu hỏi này, hoặc là sự xao nhãng khỏi chúng.
Đôi khi người ta thêm Độ tin cậy làm chiều thứ ba — "chúng ta chắc chắn đến đâu về tác động?" — và nó đáng để lưu tâm. Nhưng trên thực tế, hầu hết các đội đều biết khi nào mình đang đoán. Kỷ luật ở đây là gắn nhãn cho phỏng đoán đó một cách thành thật, chứ không phải chấm nó theo thang 1–5 rồi đưa vào một công thức.
Phần khó không nằm ở việc hiểu cái lưới — mà ở việc thành thật khi điền vào nó. Đội nào cũng có những tính năng mình rất muốn xây, đáng lẽ thuộc nhóm "Hố đen thời gian" nhưng cứ bị xếp lại thành "Cược lớn". Khung này chỉ hiệu quả nếu đội có thể thành thật về tác động.
Tác động là chiều mà các đội thấy khó đánh giá nhất, vì thường phải dự đoán tương lai. Cám dỗ là chấm điểm bằng số và cảm thấy mình đang làm khoa học. Cách tiếp cận tốt hơn là định tính nhưng có cấu trúc.
Hãy đặt ba câu hỏi cho mỗi tính năng đang được cân nhắc:
Các đội thường xuyên đánh giá thấp nỗ lực một cách có hệ thống. Điều này đã được ghi nhận rõ — nó liên quan đến ngụy biện lập kế hoạch (planning fallacy) và thiên kiến lạc quan — và đặc biệt rõ với những tính năng chạm vào nhiều hệ thống, đòi hỏi phối hợp giữa nhiều đội, hoặc liên quan đến năng lực mà đội chưa từng xây dựng.
Có hai thực hành giúp ích. Thứ nhất, luôn hỏi đội kỹ thuật trước khi chấm điểm nỗ lực, đừng làm sau. Các PM tự chấm nỗ lực một mình hầu như luôn đánh giá thấp. Thứ hai, hãy dùng khái niệm "ẩn số chưa biết" (unknown unknowns) như một hệ số nhân nỗ lực tường minh. Bất kỳ tính năng nào chạm vào một phần mã nguồn mới, một API bên thứ ba, hoặc một luồng người dùng lâu rồi chưa được kiểm thử đều xứng đáng được điểm nỗ lực cao gấp 1,5 lần so với những gì công việc hiển nhiên gợi ra.
Phần lớn sự khẩn cấp trong backlog sản phẩm không phải khẩn cấp thật — mà là tính "mới xảy ra gần đây" (recency). Một khách hàng phàn nàn tuần trước, nên yêu cầu của họ có vẻ cấp bách. Một đối thủ ra mắt thứ gì đó tháng trước, nên đuổi theo họ có vẻ then chốt. Nhưng mới xảy ra gần đây không đồng nghĩa với quan trọng, và phản ứng theo sự mới mẻ là một trong những cách chắc chắn nhất để những việc thực sự quan trọng bị trượt đi.
Một phép thử thực tế: hãy tự hỏi liệu bạn có còn coi việc này là khẩn cấp không nếu bạn nghe về nó sáu tháng trước thay vì tuần trước. Nếu câu trả lời là không, đó là thiên kiến gần đây (recency bias) đang tác động, chứ không phải ưu tiên chiến lược. Hãy ghi nhận nó, đánh giá nó bình tĩnh theo cái lưới, và cưỡng lại sức hút của việc cho nó đi đường tắt chỉ vì nó còn mới.
Cái lưới không phải lúc nào cũng cho ra một đáp án rõ ràng. Hai hạng mục rơi vào cùng một góc phần tư với điểm số tương tự, và bạn vẫn phải chọn một. Trong trường hợp này có hai tiêu chí phân định hữu ích: mức độ phù hợp chiến lược (cái nào đưa bạn đến gần hơn nơi bạn muốn đứng sau 18 tháng?) và khả năng đảo ngược (cái nào khó hoàn tác hơn nếu hóa ra sai?). Hãy ưu tiên hạng mục phù hợp chiến lược hơn và dễ đảo ngược hơn.