Cara menolak permintaan fitur tanpa kehilangan pelanggan

Menutup lingkaran biasanya berarti memberi tahu seseorang bahwa permintaan mereka sudah dirilis. Separuh yang sulit, yang tidak dimiliki proses oleh kebanyakan sistem pelacakan sama sekali, adalah bilang tidak. Kebanyakan permintaan fitur tidak pernah dirilis, yang berarti sebagian besar penutupan lingkaran yang sebenarnya dihutangi produk kepada penggunanya adalah penolakan, bukan pengumuman, dan penolakan yang ditangani buruk lebih mahal biayanya untuk niat baik daripada yang akan dikeluarkan keheningan. Ditangani dengan baik, biayanya bisa hampir tidak ada, karena yang paling diinginkan yang meminta, kebanyakan waktu, adalah tahu bahwa mereka didengar, bukan fiturnya sendiri.

Mengapa menolak dengan baik sama pentingnya dengan merilis dengan baik?

Karena keheningan terbaca sebagai penolakan tanpa penjelasan, dan tidak yang dijelaskan terbaca sebagai perhatian. Yang tidak mendengar apa-apa berasumsi permintaannya diabaikan atau hilang, dan kedua kesimpulan itu mengajarinya berhenti repot-repot bertanya, yang merupakan hasil yang sama yang didapat produk dari penolakan sungguhan, hanya dicapai lebih lambat dan dengan lebih banyak kekesalan di sepanjang jalan. Balasan yang bilang tidak, dengan jelas dan dengan alasan, menutup lingkaran sama lengkapnya dengan fitur yang dirilis, dan melakukannya lebih cepat.

Apa yang membuat penolakan mendarat dengan buruk?

Hampir selalu tiga hal, dikombinasikan. Keumuman: “terima kasih atas masukan Anda” yang siap saji yang tidak merujuk pada apa yang sebenarnya diminta terbaca seolah tidak dibaca sama sekali, meski sebenarnya dibaca. Penundaan: penolakan yang datang enam bulan setelah permintaan, saat yang meminta sudah lupa pernah bertanya, terasa lebih buruk dari tidak yang cepat, karena menyiratkan permintaan itu dibiarkan tak tersentuh alih-alih dipertimbangkan dan ditolak. Dan alasan yang tidak kuat: “tidak ada di roadmap kami” tidak menjawab apa pun, sementara “ini akan memerlukan merancang ulang cara kerja izin, yang tidak kami rencanakan untuk disentuh tahun ini” memberi yang meminta sesuatu yang benar-benar bisa mereka evaluasi dan, jika cukup penting, diesk­alasi atau dihindari.

Apa yang seharusnya benar-benar dikatakan penolakan yang baik?

Empat hal, dalam urutan ini: pengakuan yang menyebutkan permintaan spesifik, bukan parafrase umum; alasan sebenarnya, dinyatakan dengan jujur bahkan ketika alasan jujurnya adalah “ini tidak cocok dengan arah produk” alih-alih alasan yang lebih halus; apakah pintunya tertutup atau hanya belum terbuka sekarang, karena itu butuh nada yang sangat berbeda; dan, ketika ada, alternatif yang menjawab kebutuhan mendasar meski bukan fitur yang diminta secara harfiah.

Hai Jamie,

Terima kasih atas permintaan menambahkan impor CSV massal untuk
undangan tim. Kami sudah meninjaunya, dan kami tidak akan
membangunnya: alur undangan kami dibangun di sekitar peninjauan
individual setiap anggota baru demi keamanan, dan impor massal akan
bertentangan dengan itu by design, bukan karena kelalaian.

Jika masalah sebenarnya adalah mengundang tim besar dengan cepat, API
mendukung undangan individual berbasis skrip, yang memberi Anda
hampir semua kecepatan tanpa melewati peninjauan: [tautan]. Beri tahu
saya jika Anda ingin bantuan menyiapkannya.

Perhatikan yang dilakukan ini yang tidak bisa dilakukan template: menyebut fitur sebenarnya, memberi alasan yang terkait dengan keputusan desain sungguhan alih-alih kebijakan samar, dan menawarkan jalan yang menyelesaikan masalah mendasar alih-alih hanya menutup tiket.

Apa bedanya ini dengan menutup lingkaran pada fitur yang dirilis?

Mekanismenya mirip, nadanya tidak. Menutup lingkaran umpan balik dengan pelanggan membahas kasus yang dirilis, di mana pesannya adalah kabar baik dan risiko utamanya adalah lupa mengirimnya. Penolakan adalah kabar buruk, atau setidaknya kabar yang tidak diinginkan, dan butuh lebih banyak perhatian pada alasan yang diberikan dan lebih sedikit otomatisasi dalam penyampaian: notifikasi fitur yang dirilis bisa berupa komentar siap saji yang dipicu perubahan status, tapi penolakan yang terbaca siap saji justru adalah mode kegagalan yang ingin dihindari seluruh pendekatan ini. Keduanya tetap berbagi satu syarat: permintaan asli harus tetap terhubung dengan yang mengajukannya, disiplin pelacakan yang sama yang dibahas pelacakan permintaan fitur, kalau tidak tak ada cara mengirim salah satu pesan itu secara individual.

Haruskah penolakan bersifat publik, seperti status di roadmap publik?

Biasanya bukan alasan spesifiknya, meski statusnya bisa. Roadmap publik membahas label status yang bisa dicek yang meminta tanpa bertanya lagi, dan status “ditolak” atau “tidak direncanakan” bisa jadi bagian dari sistem itu. Tapi alasan rinci, terutama saat menyentuh prioritas internal atau konteks yang kurang menyenangkan, biasanya lebih bernilai di balasan individual daripada di halaman status publik, di mana formulasi yang sama harus berfungsi untuk setiap pembaca alih-alih untuk satu orang yang benar-benar bertanya.

Apakah setiap permintaan yang ditolak pantas mendapat balasan individual?

Setiap permintaan dari orang yang disebutkan namanya dan bisa dihubungi, ya, setidaknya yang singkat. Permintaan bervolume tinggi, duplikat, atau anonim adalah pengecualian: mengelompokkan permintaan serupa dan membalas sekali per kelompok, atau memperbarui label status bersama, masuk akal ketika balasan individual sungguh tidak bisa diskalakan. Batas yang harus dijaga adalah “kami tidak bisa membalas semua orang secara individual” seharusnya menjadi batasan operasional sungguhan, dicek terhadap volume sebenarnya, bukan alasan default untuk melewatkan balasan yang hanya butuh dua menit.

FAQ

Lebih baik menolak cepat dengan alasan lemah, atau meluangkan waktu untuk yang baik? Cepat, dengan alasan jujur, mengalahkan keduanya jika terpisah. Balasan cepat dengan alasan sungguhan, meski singkat, mengungguli balasan lambat dengan yang dipoles; penundaannya sendiri adalah bagian dari yang merusak kepercayaan.

Haruskah penolakan pernah menjanjikan meninjau kembali permintaan nanti? Hanya jika itu sungguh mungkin dan ada mekanisme untuk benar-benar meninjaunya kembali, seperti label yang memunculkannya lagi di siklus perencanaan. “Akan kami pertimbangkan” yang samar tanpa mekanisme itu secara fungsional sama dengan keheningan, hanya dirumuskan lebih ramah.

Bagaimana jika alasan jujurnya adalah sesuatu yang tidak bisa dibagikan perusahaan, seperti kekhawatiran kompetitif? Katakan itu langsung alih-alih mengarang alasan yang lebih halus. “Kami tidak bisa membagikan alasan spesifiknya di sini, tapi ini bukan sesuatu yang kami rencanakan untuk dibangun” lebih jujur, dan lebih dihormati, daripada penjelasan karangan yang runtuh di pertanyaan lanjutan.

Apakah menolak permintaan berarti harus dihapus dari pelacakan? Tidak. Simpan, berlabel ditolak dengan alasannya, sehingga jadi bagian dari pola yang dijadikan acuan pengelompokan permintaan serupa berikutnya, dan sehingga konteks yang berubah nanti (integrasi baru, prioritas tim baru) bisa memunculkannya lagi alih-alih memulai evaluasi dari nol.

Klaim teknis dalam artikel ini belum ditinjau secara independen. Jika ada yang keliru, beri tahu kami dan kami akan memperbaikinya.

Terkait di changeloop: Dokumentasi developer, Perbandingan alat changelog