Manajemen Pemangku Kepentingan: Seni Mengatakan Tidak

Pengembangan produk yang baik membutuhkan pengidentifikasian dan pengenalan pada tumpang tindih ajaib antara keinginan, kelayakan, dan kelangsungan hidup—tempat inovasi hidup. Manajer produk terus-menerus dalam posisi harus mempertahankan keseimbangan di antara domain-domain ini, melawan kekuatan yang bersaing untuk menarik produk terlalu jauh ke satu arah dengan mengorbankan yang lain. Ini berarti mengatakan tidak—berkali-kali dan kepada banyak orang—selama perjalanan pengembangan produk.

Di awal karir saya, saya mengerjakan sebuah proyek di bidang otomotif, mengembangkan aplikasi yang menggunakan pembelajaran mesin yang diinformasikan oleh data lingkungan dan perilaku pengguna untuk memberikan saran cerdas kepada pengemudi. Saat saya bergabung dengan tim, aplikasi sudah siap untuk diluncurkan dan manajemen sangat ingin merilisnya, tetapi saya segera menyadari bahwa itu masih jauh dari siap untuk diproduksi.

Meskipun aplikasi ini menarik secara visual, beberapa pertanyaan desain yang paling mendasar telah diabaikan, seperti "Masalah apa yang kita pecahkan, dan untuk siapa?" dan “Seberapa putus asa orang untuk menyelesaikan masalah ini?”

Aplikasi ini memiliki fitur yang akan menampilkan cuaca di tempat tujuan pengemudi. Dari kebiasaan pengguna dan data lalu lintas, algoritme dapat menyimpulkan ke mana arah tujuan pengemudi dan berapa lama waktu yang dibutuhkan untuk sampai ke sana, dan integrasi API cuaca sederhana menunjukkan prakiraan cuaca untuk tujuan pada saat kedatangan. Ini tampak seperti kasus penggunaan yang bagus, tetapi pada kenyataannya, tidak ada yang peduli. Ketika saya melakukan penelitian pengguna saya sendiri, termasuk survei berbayar dari pengemudi Eropa, tanggapannya adalah “Meh.” Itu bisa dibilang umpan balik terburuk yang bisa Anda dapatkan: Ini berarti produk Anda memecahkan masalah yang tidak relevan dan menunjukkan bahwa dimensi keinginan sangat rendah. Kelangsungan hidup kemudian menjadi penyebab yang hilang: Tidak mungkin membangun bisnis yang layak dengan produk yang tidak diinginkan siapa pun. Kami harus membuang semuanya.

Bagaimana ini bisa terjadi? Jawabannya rumit, tetapi bermuara pada fakta bahwa kata kritis tidak diucapkan ketika seharusnya: Tidak.

Kompetensi dan aset inti perusahaan adalah mesin inferensi pembelajaran mesin dan desain arsitektur yang sangat skalabel. Kepala ilmu data adalah pemangku kepentingan yang kuat yang ingin melihat mesin inferensinya digunakan dengan baik dalam aplikasi pelanggan. Pengaruhnya, sebagian, telah menghasilkan produk yang sepenuhnya berpusat pada teknologi. Pengembangan telah didorong oleh apa yang layak secara teknologi daripada apa yang diinginkan pelanggan.

Tampaknya tidak ada yang memberi tahu pemangku kepentingan ini tidak, dan jika mereka mencoba, itu tidak efektif.

Strategi Produk Berarti Mengatakan Tidak

Mengatakan tidak itu sulit. Orang tidak selalu suka mendengar kata itu, dan sering kali ada ketakutan bahwa mengatakannya akan merusak hubungan yang penting. Sebagai manajer produk, hubungan adalah inti dari peran kami, tetapi juga memastikan bahwa produk kami berhasil dan tetap seimbang.

Lantas, bagaimana cara menolak permintaan seseorang sekaligus menjaga hubungan tetap utuh? Saya merekomendasikan praktik ini:

• Siapkan diri Anda untuk sukses.
• Jangan katakan tidak terlalu cepat.
• Membingkai ulang permintaan.
• Mendorong iklim kontribusi.

Siapkan Diri Anda untuk Sukses

Pada awal proyek, penting bagi setiap orang untuk menyepakati visi bersama untuk keberhasilan produk (“Mengapa kita melakukan ini?”) dan pada seperangkat metrik yang akan digunakan untuk mengukur kemajuan (“Bagaimana kita mengetahui jika kita melakukannya dengan baik?”). Jika Anda tidak setuju seperti apa kesuksesan itu, hanya masalah waktu sebelum konflik muncul.

Sangat membantu untuk menggunakan kerangka kerja untuk mendokumentasikan tujuan dan memetakannya ke sesuatu yang terukur. Saya suka menggunakan versi longgar kerangka kerja HEART Google, yang mengatur pengalaman pengguna ke dalam kategori untuk Kebahagiaan, Keterlibatan, Adopsi, Retensi, dan Keberhasilan Tugas, dan kemudian mengartikulasikan tujuan, sinyal, dan metrik untuk masing-masing kategori tersebut. Sasaran membahas apa yang ingin Anda capai, sinyal memecah setiap sasaran menjadi tindakan pengguna, dan metrik melacak tindakan tersebut untuk mengukur kinerja Anda dengan cara yang dapat diukur.

Pada satu proyek aplikasi konsumen baru-baru ini, saya ingin melakukan uji coba terbatas untuk menentukan apakah pengguna menganggap prototipe kami berguna dan ingin terus berinteraksi dengannya; Saya berfokus terutama pada kategori Keterlibatan dari kerangka HATI. Saya kemudian harus mengidentifikasi sinyal dan metrik untuk melacak kemajuan menuju tujuan itu:

• Sasaran: Pengguna ingin berinteraksi dengan aplikasi dan terus menggunakannya.
• Sinyal: Pengguna sering membuka aplikasi.
• Metrik: Persentase pengguna yang membuka aplikasi setidaknya dua kali per hari.

Proses mengidentifikasi dan menyelaraskan tujuan ini mungkin tampak sederhana, tetapi tidak mudah. Dalam hal ini, melibatkan panggilan dengan klien dan tim penjualan kami, penelitian independen, dan beberapa lokakarya tim. Berdasarkan informasi yang saya kumpulkan dari penemuan ini, saya dapat mempresentasikan kerangka kerja HATI yang lengkap selama pertemuan awal dengan klien. Kami memeriksa semua item dan menyesuaikan jika diperlukan.

Memastikan bahwa semua pemangku kepentingan terlibat dalam proses penetapan tujuan sangat penting, dan membuat semua orang setuju tentang sinyal dan metrik apa yang perlu dilacak menghilangkan kebutuhan untuk mengatakan tidak berulang kali saat proyek berlangsung. Ini juga memberi Anda data untuk ditunjukkan jika seseorang mendekati Anda dengan permintaan yang berada di luar parameter rencana.

Jangan Katakan Tidak Terlalu Cepat

Bahkan ketika pemangku kepentingan utama menyetujui seperti apa kesuksesan itu dan jalan di depan tampak jelas, satu hal yang pasti: Seseorang, di suatu tempat, akan mendekati Anda dengan pertanyaan yang tak terduga.

Ketika itu terjadi, jangan katakan tidak terlalu cepat. Bahkan jika Anda yakin permintaan itu tidak masuk akal, menolaknya mentah-mentah akan menutup percakapan dan dapat merusak hubungan. Ini juga merusak proses penemuan produk. Sebagai manajer produk, kita perlu melihat gambaran lengkapnya, dan mendengarkan orang yang tidak setuju dengan kita akan mengurangi titik buta kita.

Anda masih bisa mengatakan tidak, tentu saja, tetapi Anda harus menghindari respons spontan. Itu mengarah pada diskusi biner yang merupakan hasil dari pemikiran hitam-putih, benar-salah, menang-kalah: Entah Anda menerapkan sesuatu atau tidak.

Untuk bergerak ke arah diskusi yang lebih efektif dan bernuansa, Anda perlu mengatur permintaan sesuai dengan kriteria yang disepakati yang telah Anda tetapkan sebagai bagian dari proses penetapan tujuan Anda.

Alih-alih bertanya kepada pemangku kepentingan, “Apakah fitur ini berharga bagi Anda?” tanyakan “Seberapa berharga fitur ini bagi Anda?” Percakapan yang dihasilkan akan memberi Anda informasi yang Anda butuhkan untuk berkolaborasi dalam daftar "keinginan", yang diurutkan berdasarkan kepentingannya. Sangat penting bahwa peringkat ini berkisar dari 1 hingga n, tanpa mengizinkan beberapa item berbagi tempat yang sama dalam hierarki. Ini memberi semua orang suara dalam proses penentuan prioritas dan membebaskan Anda dari keharusan menolak permintaan secara sepihak. Beberapa permintaan akan gagal saat grup menurunkannya demi permintaan yang lebih penting.

Membingkai ulang Permintaan

Permintaan yang awalnya tampak tidak masuk akal dapat memberikan hasil positif dengan beberapa rekayasa ulang yang halus. Pertama, dengarkan apa yang dikatakan. Benar-benar mendengarkan. Kesampingkan asumsi Anda dan cobalah untuk memahami dari mana orang lain itu berasal, dan kemudian temukan titik temu. Jika Anda menggali lebih dalam dengan menanyakan "Mengapa"—belum tentu lima kali yang pernah Anda dengar; dua sampai tiga biasanya sudah cukup—Anda mungkin menemukan faktor yang mendukung tujuan bersama.

Bahkan permintaan yang sangat masuk akal dapat mengambil manfaat dari penyelaman yang lebih dalam dan sedikit pembingkaian ulang. Saya ingat situasi di mana saya sedang mengerjakan alat intelijen bisnis untuk layanan mobilitas B2B. Klien saya meminta saya, secara tidak terduga, untuk menaikkan nomor pelanggan. Sementara motivasi untuk meningkatkan jumlah pelanggan yang membayar mungkin tampak jelas, saya ingin memastikan bahwa saya memiliki gambaran lengkapnya, jadi saya bertanya, “Mengapa?”

Ternyata produk yang dimaksud mendekati akhir siklus hidupnya, dan klien saya ingin memeras keuntungan terakhir sebelum menggantinya dengan produk baru. Dengan informasi ini, saya membingkai ulang permintaan menjadi “Bagaimana kami dapat meningkatkan pendapatan secara signifikan dalam jangka pendek sambil meletakkan dasar untuk peluncuran produk yang akan datang?”

Pada akhirnya, solusi terbaik adalah tidak repot dengan nomor pelanggan sama sekali tetapi lebih menyelaraskan harga dengan nilai. Pelanggan telah membayar langganan bulanan tetap, terlepas dari seberapa sering mereka menggunakan alat ini untuk transaksi pengendara. Namun, semakin banyak transaksi pengendara yang mereka proses, semakin banyak nilai yang mereka peroleh dari alat tersebut. Pelanggannya berkisar dari pengemudi taksi individu yang hanya melakukan beberapa transaksi bulanan hingga operator kargo multinasional—dengan lusinan anak perusahaan dan ribuan kendaraan—membuat ratusan ribu transaksi bulanan. Langganan bulanan tetap yang sama terlalu tinggi untuk klien kecil dan terlalu rendah untuk klien besar.

Dengan membuat penyesuaian harga kecil, kami meningkatkan pendapatan sambil melangkah ke struktur harga berjenjang (berdasarkan jumlah transaksi) untuk produk yang akan segera dirilis. Model baru ini mengurangi harga untuk sebagian besar pelanggan sambil meningkatkannya untuk pelanggan terbesar, yang telah diuntungkan secara tidak proporsional.

Dengan membingkai ulang permintaan dengan cara ini, Anda dapat menciptakan situasi yang saling menguntungkan. Orang yang mengajukan permintaan merasa didengar dan dihormati, dan Anda memperoleh wawasan yang dapat menambah nilai tanpa menggagalkan proses pengembangan produk.

Mendorong Iklim Kontribusi

Salah satu risiko terbesar dari mengatakan tidak adalah penolakan dapat merusak semangat keterbukaan dan kolaborasi yang Anda coba bina, baik di dalam maupun di luar tim Anda. Ide menginspirasi, apakah relevan atau tidak, dan hal terakhir yang ingin Anda lakukan adalah membendung aliran kreativitas dan komunikasi.

Saya pernah bekerja dengan seorang insinyur QA junior yang memiliki banyak ide. Di hampir setiap pertemuan, dia mengajukan banyak pertanyaan dan memberikan saran secara sukarela. Solusinya sering kali bukan solusi yang dapat ditindaklanjuti, dan beberapa di antaranya dapat dianggap tidak membantu atau tidak relevan. Tapi komitmen dan antusiasmenya sangat berharga. Dia benar-benar berinvestasi dalam memberikan produk terbaik, dan kontribusinya memberi energi dan menginspirasi orang lain. Sikap seperti itu menular.

Anda ingin menciptakan lingkungan di mana orang merasa terdorong untuk berbagi pemikiran dan ide, dan dihargai karena melakukannya. Tim Anda harus dimotivasi oleh kemungkinan untuk memperbaiki hal-hal alih-alih berkecil hati dengan pemikiran diberhentikan, diabaikan, atau diejek. Menerapkan beberapa praktik sederhana dapat membantu memastikan keamanan psikologis tim Anda.

Akui ide dan permintaan secara terbuka. Ini membangun kepercayaan dan menunjukkan bahwa Anda menghargai saran dan berkomitmen untuk mempertimbangkannya. Siapkan kotak permintaan, atau halaman Confluence atau forum publik lainnya yang dapat diakses oleh semua pemangku kepentingan. Ketika sebuah permintaan masuk, log dan kirim pesan ke pemohon, berterima kasih atas kontribusi mereka.

Saya tahu ini mungkin terbukti kontroversial, tetapi terkadang saya membuka simpanan produk untuk semua orang. Ini bisa sangat membantu dalam mendorong keterlibatan dari tim produk, serta memungkinkan anggota tim seperti penguji QA dan desainer untuk mencatat hal-hal yang mereka temui. Aturannya sederhana: Siapa pun dapat menambahkan ke bagian akhir backlog, dan selama penyempurnaan (atau rapat mingguan lainnya) anggota tim membagikan apa yang telah mereka tambahkan dan menjelaskan alasannya. Hanya manajer produk yang dapat mengubah urutan masalah atau menghapus item. Banyak orang berasumsi bahwa memberi setiap orang tingkat akses ini akan menyebabkan kekacauan dan anarki, tetapi ternyata tidak. Saya sudah mencoba ini di organisasi dengan ukuran berbeda dan hanya gagal ketika orang terlalu malu untuk menyumbangkan ide mereka.

Setelah Anda menerapkan solusi atau merilis fitur yang bahkan secara kasar terkait dengan salah satu permintaan yang dicatat ini, beri kredit kepada pemohon secara publik. Ini sangat penting ketika solusinya bukanlah pemenuhan yang jelas dari permintaan asli tetapi lebih dari versi yang dibingkai ulang. Menunjukkan penghargaan untuk semua orang yang terlibat dalam kesuksesan menciptakan niat baik, membangun persahabatan, dan mendorong orang untuk terus berpartisipasi.

Menimbang Pro dan Kontra dari Mengatakan Tidak

Jika Anda meluangkan waktu untuk benar-benar mendengarkan dan memahami dari mana pemangku kepentingan berasal, Anda jarang perlu menolak proposal secara langsung. Mendengarkan secara aktif, komunikasi yang transparan, dan saling menghormati adalah unsur utama dalam menangani permintaan yang awalnya mungkin tampak bermasalah atau di luar jangkauan. Sering kali, seni mengatakan tidak tidak pernah benar-benar melibatkan mengatakan "Tidak."

Akan ada situasi di mana terbukti tidak mungkin menemukan titik temu, dan tidak langsung diperlukan untuk melindungi produk dan proyek. Dalam kasus lain, Anda mungkin dipaksa untuk menindaklanjuti hal-hal yang tidak Anda setujui. Sebanyak tugas Anda adalah untuk melindungi keseimbangan keinginan, kelayakan, dan kelangsungan hidup, ada dimensi keempat yang perlu dipertimbangkan: pragmatisme. Untuk menjaga segala sesuatunya tetap berjalan, kompromi adalah kuncinya, dan terkadang itu berarti menghindari kata tidak sama sekali.

Keindahan pengembangan produk Agile adalah bahwa sifat iteratifnya menawarkan banyak peluang untuk koreksi arah. Lagi pula, tujuannya adalah membangun-mengukur-belajar, bukan memperdebatkan-menyangkal-menggelincirkan.