Kami terus berbicara tentang kualitas utama untuk manajer produk yang sukses, menurut tim produk Wrike. Di bagian keenam (!) Dari seri ini kita akan berbicara dengan Anton Stozhko. Anton telah bekerja sebagai manajer produk asosiasi selama 1,5 tahun, di mana ia pindah dari tim Dukungan Pelanggan.
- Hai Anton! Saya sarankan segera mulai dengan pertanyaan kunci: apa, menurut Anda, tiga kualitas utama dari seorang manajer produk yang ingin sukses dalam perannya?
- Yang paling atas adalah kemampuan untuk merencanakan dan memprioritaskan. Rencana dan prioritas bukanlah manajemen produk, tetapi budaya pribadi atau bahkan kebersihan. Rencana itu penting karena membantu memerangi hal yang tidak diketahui, dan sedikit yang menyukainya dan sebagian besar berusaha menghindarinya. Tetapi jika Anda ingin mengembangkan bisnis, Anda harus menghadapinya. Dan prioritas itu penting, karena tidak akan pernah ada sumber daya untuk melakukan segalanya sepenuhnya (kabar baik - ini tidak diperlukan). Hal utama adalah melakukan hal yang paling penting pada waktunya.
- Dan bagaimana Anda bisa mengembangkan keterampilan ini? Apakah mungkin untuk mengatakan bahwa mereka datang dari rasa tanggung jawab atas apa yang terjadi di tim Anda dan bisnis Anda?
"Yah, tentu saja bukan untuk semua yang terjadi, tetapi hanya untuk apa yang menjadi tanggung jawabmu." Anda dapat mengembangkannya, seperti yang lainnya - melalui pengulangan. Peringatan kecil: sulit untuk belajar bagaimana merencanakan dengan baik sampai Anda menjadi produk sendiri. Kebutuhan untuk kegiatan ini atau itu tidak terlalu terlihat, nilai sebenarnya tidak jelas. Wrike mengguncang saya dengan keras di sini: Saya menyadari bahwa tidak ada waktu pribadi seperti yang saya pikirkan, dan daftar tugas yang diprioritaskan cenderung tak terbatas. Di depan mata saya masih ada antrian permintaan di Dukungan, tempat saya mulai.
Untuk mengembangkan keterampilan ini, Anda perlu mencoba menerapkan prinsip-prinsip ini pada semua yang terjadi. Kasus untuk hari itu, rencana liburan, balasan pesan dari tiga atau empat saluran, rencana tim untuk kuartal tersebut. Selanjutnya, Anda perlu belajar bagaimana mentransfer keterampilan ke kegiatan orang lain: di tim dan perencanaan mereka, pada manajer produk dan visi mereka.
Saya perhatikan bahwa dorongan keren untuk perencanaan dan penentuan prioritas memberi kemampuan untuk pertama-tama membayangkan "keadaan sempurna". Ketika hal-hal dilakukan, keputusan dibuat, fitur disetrika, metrik dicapai. Setelah kondisi ideal terbentuk di kepala pada titik waktu tertentu, Anda bisa mulai melepas bola.
- Dan bagaimana cara melepasnya?
- Mengajukan pertanyaan, tentu saja. Ini hanya keterampilan kunci kedua - kemampuan untuk mengajukan pertanyaan kepada diri sendiri dan orang lain: "Apa yang Anda butuhkan agar ini terjadi?", "Apa yang hilang?", "Apa yang tidak dapat dipahami oleh seseorang tanpa konteks?". Pertanyaan besar dan tidak jelas mundur menjadi pertanyaan kecil dan spesifik. Sekali lagi, jangan menjawab sekaligus. Ingat prinsip pertama.
Pentingnya kemampuan untuk mengajukan pertanyaan mungkin ditulis di semua buku tentang produk, tetapi ada fokus besar pada pertanyaan "Mengapa?". Saya tidak akan berdebat - penelitian pelanggan adalah topik yang berguna, tetapi pertanyaan lain tidak kalah pentingnya. Para pemangku kepentingan sering tertarik pada “apa dan kapan?”, Tim tertarik pada “mengapa dan dalam urutan apa?”, Semua orang tertarik pada “apa dan mengapa?”.
Keunikan dari karya produk adalah bahwa di saku Anda tidak selalu ada lebih banyak jawaban daripada pertanyaan. Tetapi keinginan untuk menerima jawaban adalah rahasia perjuangan melawan rutinitas.
- Seberapa luas tugas yang dirumuskan di mana Anda perlu bekerja sebagai produk dari seorang oouner sebagai bagian dari strategi? Apakah Anda menyiarkan hanya visi umum atau beberapa hal yang lebih spesifik? Misalnya, adalah situasi yang khas ketika mereka menoleh kepada Anda: "Kami ingin bagian produk ini seperti ini". Dan kemudian Anda mengumpulkan satu tim dan berkata, "Guys, lakukan dengan cara ini."
- Saya punya metafora favorit tentang palu dan landasan. Di sini produk tinggal di mana mereka bertemu dan bunga api terbang. Palu adalah gerakan top-down. Di sini dan visi tingkat atas, dan strategi, dan OKR, dan kadang-kadang tugas yang sangat spesifik. Wawasan turun dalam berbagai bentuk dengan berbagai tingkat kepentingan dan kecanggihan. Ini semua keinginan. Landasan adalah gerakan bottom-up. Ini adalah basis kode, sumber daya, suasana hati orang-orang dalam tim, prioritas saat ini dan rencana yang ada. Itu adalah kenyataan. Ketika keinginan bertemu dengan kenyataan, kita harus mengelola keduanya.
Jadi jawaban untuk pertanyaan: "Bagaimana ini terjadi?" - "Dengan cara yang berbeda!"
Kebetulan Anda melepaskan ide dari manajer puncak dan memahami bahwa dalam beberapa aliran ada potensi nilai yang sangat besar. Tugas saya adalah mengidentifikasi nilai ini, memahami bagaimana mengintegrasikannya ke dalam alur kerja dan memeriksa apakah itu tidak mengganggu tugas-tugas prioritas yang ada.
Kebetulan tugas yang sangat spesifik turun, dan perlu diambil dan dilakukan.
Ngomong-ngomong, dalam arti yang mendalam, tugas yang ditetapkan langsung dari suatu ide, wawasan atau strategi hanya dibedakan berdasarkan tingkat perkiraan dan kecanggihannya.
- Dan katakan padaku, tolong, apa perbedaan antara produk dan produk rekanan dalam konteks Wrike?
- Pertama-tama, ini adalah tingkat keputusan yang Anda buat. Lihat: Saya datang dan menjadi Manajer Produk Asosiasi, dan manajer saya mengatakan kepada saya: "Mari kita membuat kalender agar agen pemasaran yang menggunakan Wrike merasa senang" (maksud saya fitur "Kalender" dalam produk Wrike). Dan saya menjawab: “Ya, jika kita melihat mereka, maka mereka seharusnya seperti itu. Seharusnya ada filter, kemampuan untuk membuat tautan eksternal untuk berbagi, dan banyak lagi. " Saya menjelaskan detail fitur yang belum ada, tetapi fitur itu sendiri sudah terjual. Untuk sesuatu, saya mendapat persetujuan, dan di suatu tempat saya menjawab pertanyaan tambahan.
Pada saat yang sama, bagaimana fitur akan berfungsi dan mengapa diperlukan - semua orang mengerti. Oleh karena itu, pada tahap ini Anda mendapatkan tugas dalam bentuk: "Ayo, lakukan." Manajemen operasional tim ada di tangan Anda, mengisi jaminan. Ini bukan komponen utama dari produk, tetapi titik keberangkatan yang sangat baik.
Isi backlog banyak yang tahu caranya. Tidak ada yang rumit dalam menulis tugas bagaimana fitur harus bekerja ketika Anda membuatnya, dan kemudian membicarakannya dengan pengembang. Semua yang mengikuti adalah masalah evaluasi dan perencanaan.
Semua yang saya jelaskan adalah level awal. Pada tahap pengambilan keputusan selanjutnya, Anda sudah memiliki pertanyaan lain. Bukan "fitur apa yang akan?", Tapi "apa yang harus saya lakukan?" Ini adalah pertanyaan yang saya tanyakan pada diri sendiri ketika saya mulai bekerja pada Cetak Biru (perhatikan - salah satu fitur baru dalam produk). Tidak ada yang memberi tahu saya: "Buat cetak biru dan putuskan akan jadi apa." Saya diberi tahu: “Ada masalah dengan pekerjaan yang berulang. Apa yang akan kita lakukan? "
Kemudian datang tingkat ketiga pengambilan keputusan. Di sini mereka tidak lagi menunjuk masalah untuk Anda, tetapi mengatakan: "Kami pikir mungkin ada masalah di suatu tempat di sini." Dan tugas Anda sudah menemukan masalah.
- Yaitu, pada level ketiga, Anda mulai dengan menyoroti masalahnya sendiri, lalu Anda sendiri yang mengusulkan solusi dan kemudian membawa semuanya sampai akhir?
- Ya. Dan bagi saya itu sudah terlihat seperti pekerjaan kelulusan. Ketika Anda melakukan riset sendiri, Anda memahami segalanya, berbicara dengan semua orang, menyatukan visi Anda dengan kenyataan, menunjukkan segalanya kepada semua orang, meyakinkan semua orang tentang segalanya. Ringkasnya, pada setiap tahap Anda selalu diberi semacam pengantar. Pertanyaannya adalah bagaimana mereka didefinisikan. Dan dengan setiap tingkat pengambilan keputusan yang baru, cakrawala yang luas menjadi semakin luas.
- Mengerti. Anda mengatakan bahwa pada tingkat cetak biru, dia sudah bekerja pada tingkat pengambilan keputusan kedua, dan pada yang ketiga dalam memecahkan masalah orientasi. Apakah ada level keempat, kelima, dan seterusnya? Atau masih ada akhirnya?
- Mungkin yang keempat adalah ketika Anda memiliki sekelompok manajer produk. Bekerja dalam tim scrum tidak lagi menjadi rutinitas Anda, dan Anda memiliki tim baru yang terdiri dari produk. Masing-masing dari mereka memiliki semacam visi dan masalah yang mereka coba selesaikan. Dan tugas Anda menjadi manajemen hasrat yang efektif dengan realitas dari masing-masing produk ini.
Artinya, pada dasarnya, penskalaan melangkah lebih jauh: jumlah cakrawala yang perlu dipeluk meningkat. Ini dimungkinkan berkat delegasi. Dan pada level keempat ini, Anda perlu memastikan bahwa mereka yang berada di posisi ketiga datang kepada Anda dengan proposal dan presentasi seperti itu, atas dasar di mana Anda dapat membuat keputusan atau memberikan saran agar roda berputar.
- Bagus Mari kita kembali ke pertanyaan awal. Anda telah menyebutkan rencana, penentuan prioritas dan kemampuan untuk mengajukan pertanyaan. Dan apa, menurut Anda, kualitas ketiga untuk manajer produk yang sukses?
- Seperti yang dikatakan oleh mentor saya: "Satu-satunya sumber daya produk adalah hubungan dengan orang lain," yaitu, komunikasi.
- Dan sebagai bagian dari keterampilan komunikasi, masalah apa yang harus Anda tangani setiap hari?
- Di tingkat harian, ada dua masalah umum: miskomunikasi dan underkomunikasi. Informasi tidak diterima dalam jumlah yang cukup atau diubah menjadi ganas. Akibatnya, gerakan ekstra dibuat, dan beberapa proses dihentikan. Koreksi keduanya adalah biaya tambahan.
Masalah-masalah ini mungkin relevan di tingkat mana pun. Semakin tinggi levelnya, semakin mahal perbaikannya. Contoh di dalam perintah scrum: seorang karyawan tidak ada dalam rencana, dan informasi tidak dikirimkan kepadanya, atau produk itu secara bengkok menentukan definisi selesai. Apa pun bisa terjadi. Akibatnya, sprint memiliki tugas yang tidak semua langkah telah selesai sehingga dapat diambil untuk pengembangan. Misalkan pengembangannya cukup sederhana: mereka mengimplementasikannya, dan kemudian ternyata itu mulai dilakukan terlalu dini atau tidak perlu dilakukan sama sekali. Tingkat kesenangan berikutnya adalah manajemen komunikasi antar tim atau departemen.
- Saya ingin mengajukan beberapa pertanyaan. Katakan, tolong, apakah latar belakang Anda awalnya asli atau tidak?
- Tidak. Saya tidak pernah menulis sederet kode dalam hidup saya. Yah, mungkin di BASIC di pelajaran ilmu komputer di kelas 6 100 tahun yang lalu. Dalam pekerjaan saya, ini bukan faktor kunci.
- Banyak orang tidak setuju dengan masalah ini. Apakah Anda berpikir bahwa memiliki latar belakang teknis akan membantu Anda menjadi manajer produk yang lebih baik?
"Ini akan membantu Anda tetap fokus pada urusan pengembang Anda." Jika ini membantu mereka, maka ini merupakan nilai tambah. Jika ini mencegah mereka atau Anda melakukan pekerjaan Anda lebih cepat dan lebih efisien, maka ini adalah minus. Bagaimanapun, produk tersebut bukanlah serigala tunggal. Saya suka pepatah dari Game of Thrones: Ketika musim dingin tiba, satu-satunya serigala mati tetapi paket bertahan. Ini tentang nilai permainan dalam suatu tim. Saya tidak perlu tahu JavaScript, tetapi mereka perlu tahu cara mengisi daftar belanjaan.
- Jika Anda tidak sepenuhnya memahami suatu topik, maka Anda mengajukan pertanyaan kepada tim Anda dan membuat keputusan berdasarkan jawaban mereka?
- Inilah yang sedang terjadi. Saya yakin bahwa kita sedang melakukan hal yang paling penting sekarang, dan saya tahu berapa harganya. Saya harus selalu mengingat dan menghubungkan kompleksitas dengan hasilnya.
Ini diatur pada setiap langkah dengan sistem keseimbangan yang aneh, di mana Anda harus melihat apakah terlalu mahal untuk mengambil langkah ini sehubungan dengan nilai yang akan keluar darinya, dan jika Anda tidak melewatkan langkah dari mana Anda bisa mendapatkan banyak nilai dan pada saat yang sama membuat itu murah. Poin penting di sini adalah saya menentukan jumlah nilai yang diperoleh - ini adalah saldo saya. Dan berapa biayanya, para pengembang menimbang. Kami berkomunikasi dan menentukan langkah mana yang harus diambil.
- Artinya, situasi berikut mungkin terjadi: Anda melakukan penelitian dan menemukan titik di mana nilainya sangat besar. Kemudian Anda datang dan memberikan masalah atau solusi yang dijelaskan, dan pengembang memberi tahu Anda bahwa beratnya terlalu besar dan tidak dapat dibandingkan. Maka Anda bisa menolak pekerjaan lebih lanjut tentang keputusan ini, bukan?
- Dalam situasi seperti itu, semua harapan adalah untuk pengembang, karena nilai unit tidak dapat diubah. Tapi mungkin ada peluang untuk mengubah biaya satuan.
Sering kali bermuara pada bagaimana Anda merumuskan masalah. Anda dapat mengatakan: "Kita perlu memastikan bahwa subtugas berulang dapat disalin dalam tugas yang berulang." Dan Anda bisa sedikit ke sisi lain: "Kami sedang mencoba menyelesaikan masalah ketika ada subtugas dan kami perlu membuatnya sehingga dibuat dan diingat dengan beberapa keteraturan dalam tugas induk."
Tugas yang dinyatakan tampak sangat mirip. Tetapi dalam kasus pertama, saya memberi tahu para pengembang bahwa mereka perlu memperbaiki mekanisme tugas berulang yang ada, dan dalam kasus kedua, saya tidak melakukan pembatasan seperti itu. Dan juga semantik. Bukan "perlu", tapi "kita". Ini bekerja dengan baik untuk menghasilkan masalah, dan bagaimana menyelesaikannya adalah area tanggung jawab tim. Ini adalah kebebasan kreatif mereka dan kemungkinan realisasi diri mereka.
- Dan jika mereka mengusulkan beberapa solusi untuk masalah tersebut, lalu siapa yang memperkirakan yang terbaik? Timlide?
- Saya menghargainya. Selain itu, jika saya tidak memiliki pemahaman tentang solusi mana yang lebih efektif, ini berarti bahwa saya tidak mengajukan pertanyaan yang diperlukan kepada tim. Ini, kebetulan, membawa saya ke topik yang sangat penting - tentang tim. Penting untuk menempatkan tim di atas tujuan.
Dalam kasus-kasus tertentu, tentu saja, pengecualian dapat dibuat. Misalnya, jika tenggat waktu yang sangat sulit ditetapkan, yang ditetapkan dari luar: pengembangan mendesak untuk klien besar, rilis untuk mitra strategis, dengan siapa Anda perlu menyinkronkan hasil integrasi dan sebagainya. Maka kita hanya perlu duduk dan melakukannya.
Tetapi lebih sering daripada tidak, Anda menyadari bahwa tenggat waktu sedikit lebih lembut daripada kereta pergi ke pertemuan. Maka Anda harus memilih sisi tim. Di Wrike, saya benar-benar merasakannya, karena lebih mahal untuk mengguncang tim daripada mengganti produk.