Enam skema untuk membantu menjelaskan konsep manajemen produk

Beberapa gambar berguna untuk memahami dan menjelaskan ide-ide kunci dalam manajemen produk

Mereka mengatakan bahwa gambar bernilai ribuan kata, tetapi jujur ​​saja, saya pikir ini bahkan meremehkan: visualisasi membantu memberikan pemahaman umum tentang ide, menyederhanakan komunikasi dan menghilangkan sebagian besar nuansa yang melekat dalam bahasa tertulis dan lisan.

Saya ingin menunjukkan enam skema yang sering saya gunakan ketika mendiskusikan ide-ide yang berkaitan dengan manajemen produk. Mereka diterima dengan baik oleh penonton dan dengan sempurna menyampaikan esensi. Skema ini adalah:

• "Manajer Produk sebagai Hambatan."
  
• "Saluran Pengiriman Produk."
  
• "Air terjun kebuntuan klasik - Agile."
  
• "Ukuran inisiatif, risiko, dan keterlibatan kepemimpinan."
  
• "Bunker pengetahuan."
  
• Pentingnya Segmentasi.
  

Anda dapat menggunakannya dalam pekerjaan dengan cara apa pun yang Anda suka.

Diterjemahkan ke Alconost

“Manajer Produk sebagai Hambatan”

Salah satu kesalahan paling umum yang saya perhatikan dengan manajer produk adalah keinginan untuk berpartisipasi dalam semua diskusi. Ya, ini niat yang benar: Anda harus memahami segalanya untuk dapat menjawab pertanyaan apa pun tentang produk.

Sayangnya, pendekatan ini memiliki banyak kelemahan. Pertama, ini tidak praktis: Anda akan dengan cepat kelebihan informasi, yang akan berdampak negatif tidak hanya pada efektivitas tim, tetapi juga kesejahteraan Anda. Percayalah - saya mengalami ini pada diri saya sendiri. Kedua, Anda dengan demikian menghancurkan otonomi tim.

Manajer produk yang baik tahu kapan harus turun tangan, dan kapan lebih baik minggir - mereka akan berbicara dan mencari tahu sendiri. Tujuan menciptakan tim otonom adalah untuk menghilangkan sebanyak mungkin ketergantungan.

Perhatikan contoh pada gambar di bawah ini. Bayangkan situasi di sebelah kiri ketika pengembang web menanyakan algoritma pelacakan mana yang harus diterapkan, dan manajer produk beralih ke analis yang mengatakan bahwa Anda harus tetap menggunakan implementasi iOS. Kemudian manajer pergi ke pengembang iOS, menerima informasi yang diperlukan, dan kemudian kembali ke pengembang web dan menjelaskan semuanya kepadanya. Pendekatan ini tidak hanya menambah kerja ekstra untuk manajer produk, tetapi juga menunda penyelesaian masalah.

Bandingkan ini dengan contoh di sebelah kanan: pengembang web langsung menangani analis terlebih dahulu (siapa yang menjelaskan apa yang diperlukan), dan kemudian spesialis iOS (yang memberikan informasi yang diperlukan). Perhatikan betapa sedikit interaksi dalam kasus ini (panah merah).



Jika kita memperluas contoh kita dan menambahkan beberapa panah lagi (hijau dan biru), ini akan jauh lebih dekat dengan jumlah sebenarnya dari masalah yang secara simultan dipecahkan dalam tim. Jumlah interaksi tumbuh dengan cepat, dan semuanya terkait dengan manajer.



Cara menerapkan skema. Jika Anda terus-menerus bekerja terlalu keras, pikirkan apakah interaksi dalam tim sudah disesuaikan secara optimal: apakah Anda benar-benar harus hadir di setiap pertemuan? Apakah pekerjaan normal berlanjut saat Anda berlibur, atau apakah semuanya berhenti? Jika yang terakhir benar, maka Anda perlu secara sadar melakukan upaya yang akan menyederhanakan interaksi tanpa kehadiran Anda.

“Saluran Pengiriman Produk”

Ini adalah salah satu pola favorit saya: ini memungkinkan saya untuk menjelaskan konsep saluran produktivitas tim mengenai ukuran proyek yang sedang dikerjakan. Seringkali saya harus menghadapi kekecewaan baik dari mitra bisnis dan pengembang tentang waktu yang diperlukan produk untuk memasuki pasar: mereka berpikir bahwa pekerjaannya berjalan terlalu lambat.



Biasanya masalah ini disebabkan oleh fakta bahwa pekerjaan hanya dilakukan pada tugas-tugas besar (corong di sebelah kiri). Akibatnya, tim hanya dapat melakukan satu hal pada satu waktu. Pendekatan ini mungkin benar jika kami yakin bahwa fungsi tertentu pasti akan diminati - dan ini jarang terjadi. Jika ada sesuatu yang keluar dari jalur perakitan (dalam kasus kami, dari corong) dan ternyata tidak diperlukan, maka pada akhirnya Anda menghabiskan lebih banyak upaya untuk memahami hal ini daripada yang diperlukan.

Alasan mengapa dalam pendekatan yang fleksibel untuk pengembangan mereka cenderung membagi pekerjaan menjadi fragmen yang lebih kecil adalah karena hal itu memungkinkan Anda untuk dengan cepat mendapatkan hasil yang nyata dan berharga untuk bisnis, dan dengan risiko yang lebih kecil. Corong di sebelah kanan memberi lebih banyak ruang untuk bermanuver: tugas yang lebih kecil (titik biru) dapat melewati corong lebih cepat - yang berarti mereka akan diuji lebih cepat dalam praktik. Jika hasilnya berhasil, Anda dapat berinvestasi lebih banyak usaha (lingkaran merah muda). Jika hasilnya tidak memuaskan, kami beralih ke yang lain, tetapi kami membatasi sumber daya yang dialokasikan. Setiap tes dalam praktik memungkinkan Anda untuk meningkatkan sumber daya yang diinvestasikan. Sebagai hasilnya, kami memiliki banyak proyek kecil, beberapa yang sedang dan sangat sedikit. Dengan demikian, risiko berkurang dan laba atas investasi meningkat.

Cara menerapkan skema. Ingat apa yang harus Anda kerjakan dalam beberapa bulan terakhir (termasuk apa yang dijatuhkan). Apakah semua tugas besar dalam skala dan kompleksitas, atau apakah itu kombinasi dari berbagai tugas saat ini (baik pada satu topik dan berbeda)? Tetapkan ukuran untuk setiap tugas (misalnya, pada skala S, M, L) dan bayangkan seperti apa corongnya.

“Air terjun kebuntuan klasik - Agile”

Ada banyak contoh di Internet tentang topik ini, tetapi saya ingin menarik perhatian pada upaya yang dilakukan. Banyak perusahaan makanan tidak secara langsung mengatakan bahwa waktu tim juga merupakan investasi. Jika manajer produk memiliki laporan laba dan rugi dari gagasan mereka, mereka akan melihat bahwa upah sering kali merupakan item pengeluaran terbesar. Karena itu, Anda perlu mencari semua peluang untuk meningkatkan laba (pengembalian investasi).

Ketika sebuah tim memberikan pekerjaan dalam fragmen besar, kami berharap untuk mendapatkan efek langsung. Tetapi bahkan jika kita berasumsi bahwa kita segera merilis solusi sempurna tanpa masalah teknis (saya akan memberitahu Anda sebuah rahasia: ini sangat tidak mungkin), ternyata tim kami (jika Anda melihat timeline) melakukan investasi besar yang tidak berhasil (grafik di sebelah kiri).

Dengan merilis produk lebih sering, di bagian-bagian yang lebih kecil, Anda kehilangan pekerjaan Anda secara bertahap - dan mulai terbayar segera, karena Anda dapat belajar dari kesalahan lebih cepat dan memahami apa yang dibutuhkan dan apa yang tidak. Pada grafik kedua, nilai suatu produk untuk bisnis hampir selalu lebih tinggi daripada biaya usaha yang dikeluarkan - inilah yang harus Anda perjuangkan.



Cara menerapkan skema. Saya sering menggunakan grafik ini ketika saya perlu menjelaskan mengapa menambahkan hal lain ke fitur produk pada iterasi saat ini tidak selalu dalam kepentingan kita. Selain itu, dengan bantuan mereka, mudah untuk mengingatkan diri sendiri dan tim tentang sisi komersial masalah ini.

"Ukuran inisiatif, risiko dan keterlibatan kepemimpinan"

Bagan ini mencerminkan dua aspek. Di sebelah kiri adalah piramida inisiatif. Luasnya menunjukkan berapa banyak inisiatif yang dapat dikerjakan secara bersamaan: basis yang luas - banyak, yang sempit - sedikit. Pada saat yang sama, tugas dengan risiko lebih tinggi ada di atas (ada beberapa dari mereka), dan dengan risiko kecil - di bawah (ada lebih banyak dari mereka).



Di sebelah kanan adalah indikator keterlibatan manajemen. Semakin luas itu, semakin besar keterlibatan manajemen dalam pekerjaan diperlukan atau diharapkan - yaitu, dengan semakin banyak manajer dari peringkat yang lebih tinggi maka perlu untuk berkonsultasi. Semakin sempit indikator, semakin sedikit kebutuhan untuk merujuk pada "yang lebih tinggi".

Anda mungkin memiliki banyak tugas kecil - seperti memeriksa teks tertulis atau gambar yang diambil: mereka memiliki risiko yang sangat rendah, hasilnya dapat terus dioptimalkan. Di sini kepemimpinan tidak akan terlalu tertarik untuk berpartisipasi - dan tidak ada gunanya dalam hal ini. Tetapi tugas-tugas di puncak piramida akan memiliki risiko yang lebih tinggi (misalnya, itu bisa menjadi peluncuran produk yang sama sekali baru) - ini adalah di mana partisipasi dan dukungan dari kepemimpinan akan dibutuhkan.

Cara menerapkan skema. Dalam pengalaman saya, skema ini adalah alat yang sangat baik bagi para pemimpin dan tim itu sendiri: skema ini menjelaskan mengapa kepemimpinan harus dilibatkan dalam beberapa kasus, dan mengapa ini tidak boleh dilakukan dalam kasus lain.

Topik partisipasi manajer dalam pekerjaan agak rumit. Saya meninjaunya lebih detail dalam artikel Mengapa "Model Spotify" tidak menyelesaikan semua masalah .

"Bunker Pengetahuan"

Bagan ini adalah hasil dari pemeriksaan triwulanan terhadap situasi di tim tempat kolega saya bekerja. Ini adalah cara yang bagus untuk memvisualisasikan dampak isolasi departemen dan tim dalam kaitannya dengan berbagi pengetahuan. Tidak mungkin menjadi 100% berpengetahuan di semua bidang yang dipengaruhi oleh produk, tetapi jika Anda menyadari kurangnya pengetahuan, ini akan membantu untuk fokus pada komunikasi antar departemen.

Seorang karyawan individu biasanya berpengalaman dalam apa yang sedang dikerjakannya. Tetapi semakin jauh Anda dari orang lain, semakin tidak mereka sadari topik "Anda".



Cara menerapkan skema. Ingatkan diri sendiri dan orang lain bahwa pekerjaan dalam organisasi akan melambat karena fakta bahwa tidak ada yang bisa mengetahui segalanya, dan, yang lebih penting, jika ada konflik, maka salah satu alasan yang paling mungkin adalah kurangnya informasi, dan bukan niat jahat ( lihat artikel Kesalahpahaman, bukan niat jahat ).

Pentingnya Segmentasi

Salah satu kesalahan umum yang saya temui ketika perusahaan mempertimbangkan inisiatif dan percobaan adalah optimalisasi dengan nilai rata-rata, dan bukan berdasarkan segmen. Contoh favorit saya terdistorsi ke persepsi rata-rata: "Rata-rata, seseorang memiliki kurang dari dua kaki."

Jika hipotesis dan bidang cakupan menjadi terlalu luas, mereka secara alami membatasi dampak potensial dari tes ini. Faktanya, Anda berusaha memuaskan banyak orang pada saat yang bersamaan - dan ini sepertinya tidak berhasil. Dalam diagram di bawah ini, yang paling umum adalah kasus ketiga (di sebelah kanan), di mana tidak ada perubahan signifikan.

Berikut ini adalah tiga eksperimen hipotetis. Pada yang pertama kami naik, yang kedua - jatuh, yang ketiga tidak ada perubahan. Namun, seringkali, jika Anda mempelajari hasilnya, Anda dapat menemukan peluang potensial baru atau semacam keterbatasan. Dalam kasus pertama, meskipun percobaan secara keseluruhan berhasil, di segmen B Anda dapat melihat penurunan indikator - di sini perlu dipahami apa alasan terjadinya kemunduran, dan, mungkin, kecualikan ketika produk dirilis.

Mari kita lihat kasus ketiga. Secara umum, tidak ada perubahan signifikan, namun, ada hasil positif di segmen B dan C - dan mereka diimbangi oleh penurunan di segmen A dan D. Jadi, di sini kami juga menerima arahan yang dapat dipelajari lebih lanjut.

Cara menerapkan skema. Cobalah untuk merumuskan hipotesis yang lebih spesifik dan pelajari hasilnya untuk kemungkinan dan batasan tambahan. Mengenai masalah hipotesis dan eksperimen, saya sangat merekomendasikan membaca sesuatu dari Rick Hyam - lihat Pusat Eksperimentalnya . Buat arketipe melalui riset pengguna dan data demografis ( Nikki Anderson ) - ini akan membantu untuk lebih memahami segmen konsumen yang Anda targetkan.

Kesimpulan

Itu saja. Saya harap diagram dan diagram di atas membantu memvisualisasikan beberapa konsep dan menjelaskannya kepada orang lain!

Tentang penerjemah

Artikel ini diterjemahkan oleh Alconost.

Alconost melokalkan game , aplikasi , dan situs dalam 70 bahasa. Penerjemah asli bahasa, pengujian linguistik, platform cloud dengan API, pelokalan berkelanjutan, manajer proyek 24/7, segala format sumber daya string.

Kami juga membuat video iklan dan pelatihan - untuk situs yang menjual, gambar, iklan, pelatihan, permainan asah, penjelajah, trailer untuk Google Play dan App Store.

→ Baca lebih lanjut