Siklus Hidup Produk: Perjalanan Fitur Produk

Ini adalah posting keempat dari seri lima bagian yang saya tulis dengan tujuan untuk membantu calon produk memasuki dunia Manajemen Produk.

Dalam posting terakhir saya , saya memecah disiplin Manajemen Produk menjadi empat bagian dengan tujuan untuk membantu calon Manajemen Produk memahami lintasan karir mereka dalam suatu perusahaan atau secara umum. Dalam posting ini, saya akan berbicara tentang perjalanan hidup fitur produk, dari ide hingga pengabaian, untuk membantu calon Manajemen Produk mendapatkan perspektif 360 derajat tentang apa yang melibatkan peran Manajer Produk.

T – 30 hari

Dikatakan bahwa kebutuhan adalah ibu dari penemuan. Itu benar-benar kasus di mana kelahiran fitur produk terlibat. Semuanya dimulai dengan beberapa tingkat ketidaknyamanan.
Beberapa karyawan di perusahaan menghadapi ketidaknyamanan dalam mencapai salah satu tugas sehari-harinya – mungkin basis pengguna telah meningkat dan dia tidak dapat mengelolanya dengan proses lama. Beberapa eksekutif di perusahaan melihat lembar excel dan berpikir bahwa perusahaan kehilangan terlalu banyak uang karena, katakanlah, banyaknya pembatalan produk. Atau mungkin pesaing meluncurkan fitur produk yang menyebabkan pelanggan meninggalkan produk perusahaan tersebut. Seseorang yang melihat saluran konversi pemasaran melihat penurunan yang tinggi pada tahap tertentu dan merasa bahwa pengoptimalan itu dapat membantunya mencapai target triwulanannya. Atau bisa juga 100 alasan berbeda dari tingginya jumlah keluhan pelanggan untuk masalah umum hingga fitur baru yang diminta oleh mayoritas pengguna yang disurvei minggu sebelumnya. Intinya adalah – semuanya dimulai dengan beberapa tingkat ketidaknyamanan.

Sekarang, ketidaknyamanan ini dibawa ke pemberitahuan Manajer Produk; atau mungkin Product Manager yang pertama kali memperhatikan. Ini adalah titik yang memulai rantai peristiwa yang mungkin mengarah pada kelahiran fitur baru.

T – 25 hari

Sudah waktunya bagi Manajer Produk untuk memikirkan pernyataan masalah. Dia pergi dan berbicara dengan pelanggan atau pemangku kepentingan internal yang melaporkan ketidaknyamanan dan kemudian mereka yang benar-benar mengalaminya; semua dengan satu tujuan – untuk memastikan bahwa dia telah mengidentifikasi 'akar' pernyataan masalah. Jika tahap ini dianggap enteng atau Manajer Produk tidak menghabiskan cukup waktu untuk hal ini, maka fitur produk yang lahir rapuh, terdistorsi, dan menemui ajalnya dengan cukup cepat.
Setelah Manajer Produk mengidentifikasi pernyataan masalah inti, dia memutuskan apakah itu layak untuk dipecahkan. Apakah ketidaknyamanan itu benar-benar besar atau agak dilebih-lebihkan atau lebih buruk, hanya dibuat-buat? Apakah pemecahannya benar-benar menambah nilai signifikan bagi pelanggan dan/atau perusahaan? Bukankah penyelesaiannya akan memberikan hukuman yang signifikan pada pelanggan dan/atau perusahaan? Apakah ada cara untuk mengatasi masalah ini dengan sedikit perubahan dalam proses atau melalui aktivitas apa pun yang tidak memerlukan perubahan produk – misalnya mengganti vendor, menegosiasikan harga yang lebih baik dari vendor yang ada, mendapatkan perangkat lunak pihak ketiga untuk menyelesaikan masalah, mempekerjakan karyawan tambahan, perubahan konten, grafik, tombol ajakan bertindak, dll?

Pada dasarnya, jika ada cara kita bisa mendapatkan nilai tambah yang serupa dari metode yang tidak melibatkan perubahan produk, maka kita akan melakukannya dengan mengubah apa pun dalam produk – apakah itu berarti menambah atau menghapus. Setelah Manajer Produk yakin bahwa memecahkan pernyataan masalah akan memberikan nilai yang signifikan dan perubahan tingkat produk akan memberikan lebih banyak ROI (mempertimbangkan nilai waktu, uang, dan upaya v/s) daripada perubahan tingkat non-produk, benih-benih yang baru fitur produk ditanam.

T – 15 hari

Jika Manajer Produk memiliki pengalaman sebelumnya, dia mungkin mengusulkan solusi berdasarkan pengalaman itu. Namun, itu mungkin bukan solusi terbaik dalam semua kasus.
Jika pernyataan masalah memerlukan solusi yang sangat teknis, Manajer Produk mendiskusikan hal yang sama dengan pengembang dan manajer teknik dan menerima saran mereka tentang cara terbaik untuk melakukannya. Jika solusinya memerlukan perubahan tingkat desain, pimpinan UX mungkin akan dimintai pendapat. Bisa jadi Manajer Produk dan orang UX mengatur sprint desain dan memilih solusi yang diterima dengan baik oleh pengguna sebenarnya dari fitur itu. Terkadang masalahnya benar-benar terkait bisnis dan karenanya memerlukan persetujuan dari manajemen senior.
Jadi, ada beberapa cara solusi bisa diselesaikan. Namun begitu, Manajer Produk bertanggung jawab untuk mengubah solusi teoretis tersebut menjadi fitur produk yang aktif.

T = 0 (alias lahirnya fitur produk)

Ketika solusi tertentu diidentifikasi, Manajer Produk, bekerja sama dengan tim terkait, membuat garis besar dasar solusi. Ini mungkin atau mungkin tidak termasuk prototipe solusi. Kadang-kadang itu hanya lembar excel dasar dengan kondisi 'jika-maka' yang ditulis kapan harus menunjukkan CTA tertentu kepada pengguna, dll.
Manajer Produk memasukkan solusi ke dalam kata-kata dalam PRD (Dokumen Persyaratan Produk) yang relevan. Jika fiturnya kecil, mungkin hanya satu paragraf di PRD yang ada untuk fitur yang lebih besar. Terkadang fiturnya sangat besar sehingga membutuhkan PRD lengkap hanya untuk merincinya dengan benar. PRD dijalankan oleh tim yang relevan dan Manajer Produk memastikan bahwa ada konsensus luas mengenai fitur tersebut.

T + 15 hari

Fitur kecil mungkin memerlukan waktu kurang dari satu hari untuk dibekukan. Fitur-fitur besar, terkadang, membutuhkan waktu lebih dari 30 hari untuk mendapatkan persetujuan semua orang.
Mari kita ambil rata-rata 15 hari untuk mengatakan bahwa ini adalah waktu ketika fitur yang baru lahir diperkenalkan kepada para pengembang. Desain yang tepat dan serah terima PRD terjadi di mana pengembang yang mengerjakan proyek diberi tahu tentang 5W (Apa, Mengapa, Kapan, Di mana, Siapa) dan kasus uji (bagaimana fitur harus berperilaku atau tidak berperilaku setelah dirilis) .
Bersama dengan manajer teknik, jadwal rilis yang tepat diputuskan untuk fitur dengan tenggat waktu kapan pengembangan akan berakhir saat pengujian akan dimulai, kapan bug yang dilaporkan akan diperbaiki, dan tanggal rilis final. Kemudian seluruh timeline dibagi menjadi sprint terukur (biasanya 15 hari). Setelah pengembang puas, pengembangan dimulai.

T + 30 hari

Sprint 1 berakhir. Salah satu bagian dari fitur produk diluncurkan. Ini mungkin belum menghadapi pelanggan, tetapi sebagian besar tim saat ini mengikuti metodologi Agile untuk pengembangan perangkat lunak – artinya kami membangun secara bertahap dan berulang. Jadi, daripada membangun fitur besar dalam 6 bulan dan merilis sekaligus, kami memecah semuanya menjadi bagian-bagian independen yang dapat berfungsi sendiri (sekumpulan Cerita Pengguna) dan dengan cepat siap untuk ditinjau dan diulang.
Manajer Produk memastikan bahwa jadwal rilis berada di jalurnya melalui pertemuan scrum harian dan diskusi dengan manajer teknik terkait yang mengerjakan proyek tersebut. Jika ada penundaan, jadwal akan disesuaikan, atau sebagian kecil fitur dihilangkan untuk memastikan rilis tepat waktu. Setelah setiap sprint, kemajuan yang dibuat dipresentasikan kepada Manajer Produk dan pemangku kepentingan terkait dalam sebuah pertemuan, dan setelah persetujuan dirilis.
Satu Tahun Program Manajemen Produk UpGrad

T + x hari

Setelah 'n' jumlah sprint, pengembangan selesai dan seluruh fitur keluar. Pelanggan tidak perlu menggunakan fitur ini hanya ketika dirilis sepenuhnya. Mereka bisa menggunakannya sejak rilis di akhir sprint 1 itu sendiri. Setiap rilis siklus sprint berikutnya hanya membuat fitur lebih kuat dan membuatnya lebih dekat dengan apa yang dimaksudkan.
Meluncurkan fitur itu sendiri adalah sebuah seni dan melibatkan banyak langkah yang akan kita lewati dan hanya berasumsi bahwa setelah banyak permainan drum dan dada berdebar, telah diumumkan kepada dunia bahwa sebuah fitur telah dirilis. Ini mungkin serumit Siaran Pers lengkap dengan CEO sendiri yang berbicara tentang peluncuran baru, atau mungkin hanya sesuatu yang mengirim surat ke departemen tertentu yang akan menggunakan fitur tersebut dan mungkin memintanya di posisi pertama. Jadi sekarang fitur tersebut sudah ada, mari beri nama fitur ini – Mr. Feature.

T + y hari

Bahkan setelah rilis final, terkadang ada yang salah. Mr. Feature, yang dulunya berkilau dan berharga, mungkin tidak lagi sama dan mungkin ada beberapa alasan untuk itu. Fase dalam siklus produk ini adalah tentang mendukung produk. Suatu hari rilis lain dibuat yang menyebabkan Mr. Feature tampil dengan cara yang tidak diinginkan (alias menjadi buggy) atau mungkin fitur lain dihapus yang memiliki beberapa ketergantungan pada Mr. Feature dan ini menyebabkan perilaku buggy. Bisa juga ketika fitur tersebut dibuat, kita meremehkan jumlah pengguna yang akan menggunakannya atau tidak merencanakan semua kasus penggunaan dan sekarang fitur tersebut tidak dapat ditingkatkan ke banyak pengguna atau kasus penggunaan ini.

Ini dilaporkan oleh tim penguji dalam tinjauan berkala mereka, atau dilaporkan oleh beberapa anggota tim yang baru saja menemukannya saat menggunakan fitur itu sendiri. Dalam hal fitur yang dihadapi pelanggan, keluhan ini mungkin datang dari pelanggan produk yang sebenarnya dan dikomunikasikan kepada Manajer Produk melalui tim Pengalaman Pelanggan.

Manajer Produk mencoba memahami akar penyebab bug dan, menurut prioritas, menjadwalkan perbaikan untuk siklus rilis berikutnya – ini dapat ditambahkan dalam sprint saat ini jika prioritas tinggi atau bahkan sprint berikutnya. Setelah bug diperbaiki dan dirilis, Mr. Feature hidup untuk melihat hari lain, meskipun dalam bentuk yang diperbarui – Mr. Feature 2.0 – terima kasih kepada Manajer Produk dan tim teknik. Pujian!

T + z hari

Dikatakan bahwa semua hal baik harus berakhir. Sayangnya, begitu juga dengan Mr. Feature, apa pun versinya – mungkin Mr. Feature 9.263.75! Itu berarti Mr. Feature telah menjalani hidup yang panjang dan bahagia, tetapi sekarang ujung jalan telah tiba.
Mungkin karena berbagai alasan. Sebuah fitur baru datang yang membuat kebutuhan Mr Feature sama sekali berlebihan. Mungkin juga sesuatu yang ekstrem – seperti perusahaan memutuskan bahwa meskipun fitur tersebut menambah nilai bagi penggunanya, itu tidak lagi masuk akal secara ekonomi bagi mereka.

Apa pun alasannya, dikomunikasikan kepada Manajer Produk (atau dia yang memulai diskusi) bahwa layanan Mr. Feature tidak diperlukan lagi. Sekarang, meski memilukan, Manajer Produk memiliki tugas untuk mengistirahatkan Mr. Feature. Meskipun, sebelum itu, dia perlu memastikan beberapa hal seperti memberi tahu pengguna yang menggunakan Fitur Tuan bahwa itu tidak akan tersedia dari tanggal tertentu, fitur baru berfungsi dengan baik sebelum menghapus Fitur Tuan, tidak ada yang lain flow akan terpengaruh saat Mr. Feature hilang, dan seterusnya.

Jadi, sekarang saatnya mengucapkan RIP untuk Mr. Feature. Dalam karir manajemen produk Anda, Anda harus melakukan ini beberapa kali. Tapi ingat, akhir dari satu fitur adalah awal dari yang lain dan siklus terus berlanjut. Begitulah kehidupan manajemen produk!

Pelajari Kursus Manajemen Produk secara online dari Universitas top dunia. Dapatkan Master, PGP Eksekutif, atau Program Sertifikat Tingkat Lanjut untuk mempercepat karier Anda.

Program Unggulan untuk Anda: Program Sertifikasi Pemikiran Desain dari Duke CE