Dalam kebanyakan pasukan produk, backlog ialah tempat di mana kecemasan akhirnya hilang begitu sahaja. Segala yang masuk ke dalamnya pernah mendesak ketika ditambah — aduan pelanggan, permintaan jualan, ciri pesaing, idea dalaman. Enam bulan kemudian, semuanya masih ada, masih terasa mendesak, dan tiada siapa pasti apa yang patut dilakukan seterusnya.
Masalahnya bukan kekurangan alat. Terdapat berpuluh-puluh rangka kerja penentuan keutamaan: RICE, MoSCoW, Kano, ICE, pemarkahan berpemberat. Masalahnya ialah kebanyakan rangka kerja memerlukan ketepatan palsu — memberi angka kepada perkara yang tidak diketahui — sehingga ia nampak teliti, sedangkan hakikatnya hanya "mencuci" gerak hati melalui hamparan data.
Yang benar-benar berkesan lebih mudah: dua dimensi, dinilai dengan jujur, dan disiplin untuk bertindak atas keputusannya.
Penentuan keutamaan akhirnya terhimpun kepada dua soalan. Pertama: setakat mana perkara ini meningkatkan hasil yang kita pentingkan? (Impak.) Kedua: berapakah kos untuk menyiapkannya? (Usaha.) Selebihnya hanyalah penambahbaikan kepada dua soalan ini atau gangguan daripadanya.
Keyakinan kadangkala ditambah sebagai dimensi ketiga — "setakat mana kita pasti tentang impaknya?" — dan ia wajar diingat. Namun dalam amalan, kebanyakan pasukan tahu bila mereka sekadar meneka. Disiplinnya ialah melabel tekaan itu dengan jujur, bukan memarkahkannya pada skala 1–5 lalu memasukkannya ke dalam formula.
Bahagian yang sukar bukanlah memahami grid ini — tetapi bersikap jujur semasa mengisinya. Setiap pasukan ada ciri yang ingin dibina yang sebenarnya tergolong dalam "Perangkap Masa" tetapi terus dikelaskan semula sebagai "Pertaruhan Besar." Rangka kerja ini hanya berfungsi jika pasukan jujur tentang impak.
Impak ialah dimensi yang paling sukar dinilai oleh pasukan, kerana selalunya ia memerlukan ramalan masa depan. Godaannya ialah memarkahkannya secara berangka dan berasa saintifik. Pendekatan yang lebih baik bersifat kualitatif tetapi tersusun.
Tanya tiga soalan bagi setiap ciri yang dipertimbangkan:
Pasukan secara sistematik memandang rendah usaha. Ini terbukti — berkaitan dengan kekeliruan perancangan (planning fallacy) dan bias optimisme — dan lebih ketara bagi ciri yang menyentuh banyak sistem, memerlukan penyelarasan antara pasukan, atau melibatkan keupayaan yang belum pernah dibina oleh pasukan.
Dua amalan membantu. Pertama, sentiasa tanya pasukan kejuruteraan sebelum memarkahkan usaha, bukan selepas itu. PM yang menilai usaha secara sepihak hampir selalu memandang rendah. Kedua, gunakan konsep "unknown unknowns" (perkara yang kita tidak tahu bahawa kita tidak tahu) sebagai pengganda usaha yang jelas. Mana-mana ciri yang menyentuh bahagian kod yang baharu, API pihak ketiga, atau aliran pengguna yang sudah lama tidak diuji wajar diberi skor usaha 1.5x lebih tinggi daripada yang dicadangkan oleh kerja yang jelas kelihatan.
Kebanyakan kecemasan dalam backlog produk bukan kecemasan sebenar — ia hanyalah kebaruan. Seorang pelanggan mengadu minggu lalu, maka permintaannya terasa mendesak. Pesaing melancarkan sesuatu bulan lalu, maka menyamainya terasa kritikal. Tetapi kebaruan tidak sama dengan kepentingan, dan bertindak balas terhadap kebaruan ialah salah satu cara paling pasti untuk membiarkan kerja yang benar-benar penting terlepas.
Satu ujian praktikal: tanya diri anda sama ada anda masih menganggapnya mendesak jika anda mendengarnya enam bulan lalu dan bukan minggu lepas. Jika tidak, itu bias kebaruan, bukan keutamaan strategik. Catatkannya, nilai dengan tenang berdasarkan grid, dan tahan godaan untuk mempercepatkannya hanya kerana ia masih baharu.
Grid tidak selalu memberi jawapan yang jelas. Dua item berada dalam kuadran yang sama dengan skor yang hampir sama, dan anda tetap perlu memilih satu. Dalam keadaan ini, dua penentu seri berguna: penjajaran strategik (yang mana lebih mendekatkan anda kepada kedudukan yang diingini dalam 18 bulan?) dan kebolehbalikan (yang mana lebih sukar dibatalkan jika silap?). Pilih item yang lebih selari dengan strategi dan lebih mudah dibalikkan.