Peran Manajer Produk adalah sebuah kekeliruan
(sollecitom.github.io)- Jika perusahaan produk perangkat lunak salah memahami product-led sebagai “struktur di mana PM membuat semua keputusan”, mereka akan menerapkan model yang hanya cocok untuk pemimpin bertipe pendiri yang luar biasa kepada PM karier yang biasa-biasa saja
- Dalam pendekatan yang memberi kendali produk kepada satu pemimpin, yang terpenting bukan pendekatan itu sendiri, melainkan kepada siapa kendali itu diberikan; model ini mengandaikan sosok langka dengan visi, karisma, kemampuan teknis, dan keyakinan yang kuat
- Jika PM biasa diberi kewenangan berlebihan, data, framework, proses persetujuan, rapat, dan struktur peran bukan lagi alat untuk menilai, melainkan tameng untuk menghindari tanggung jawab dan berpolitik
- Arus seperti ini membuat orang-orang hebat pergi, dan perusahaan terjebak dalam tugas berisiko rendah serta proses internal sehingga kehilangan visi dan talenta
- Alternatifnya bukan struktur yang berpusat pada jabatan PM, melainkan menyatukan orang-orang yang terobsesi pada keterampilan dan kualitas di tiap bidang dalam satu tim agar mereka menangani product discovery, observability, engineering, desain, bisnis, dan pengetahuan domain bersama-sama
Masalah salah memahami product-led sebagai struktur monopoli PM
- Banyak perusahaan produk perangkat lunak didirikan bukan oleh orang yang punya pengalaman kuat membuat produk perangkat lunak, melainkan oleh orang yang pandai dalam penggalangan dana dan memahami industri target
- Pendiri seperti ini memulai perusahaan berdasarkan pengalaman dan relasi di industri, tetapi jika mereka memimpin sendiri semua pengambilan keputusan, keyakinan seorang pakar domain bisa merugikan perusahaan
- Sebagian pendiri mengakui bahwa diri mereka bisa berbahaya dan merekrut orang untuk mengambil alih pengambilan keputusan
- Di titik ini muncul salah kaprah seperti “kita harus menjadi perusahaan produk, bukan organisasi layanan; dan karena perusahaan produk itu product-led, maka PM harus bertanggung jawab”
- Di sini, product-led bukan berarti PM membuat semua keputusan
- Saat ada pendapat yang berlawanan, sering muncul bantahan bahwa perusahaan hebat seperti Amazon, Apple, dan Tesla juga mendelegasikan kendali kepada satu orang
- Banyak perusahaan hebat memang menyerahkan kendali kepada satu orang, tetapi tidak semua perusahaan hebat memakai model yang sama
Prasyarat model pengambil keputusan tunggal
- Model yang memberikan kendali perusahaan kepada satu orang bukanlah pendekatan yang salah; keberhasilannya bergantung pada kepada siapa kendali itu diberikan
- Tokoh seperti Picasso, Jeff Bezos, Mozart, Steve Jobs, Nikola Tesla, Elon Musk, Robert Oppenheimer, Peter Thiel, dan Leonardo dikagumi publik karena visi, karisma, kepercayaan diri, resiliensi, dan keunggulan mereka
- Mereka adalah tipe orang yang membayangkan realitas alternatif, sepenuhnya tenggelam dalam pekerjaannya, dan menciptakan perubahan besar melalui kehendaknya
- Jika sosok seperti ini benar-benar ada, model kendali tunggal bisa bekerja dengan sangat kuat
Sosok luar biasa bukanlah PM biasa
- Tokoh-tokoh besar tersebut bukan manajer produk
- Mereka adalah seniman, matematikawan, penemu, ilmuwan, CEO, dan dalam beberapa kasus memegang banyak peran sekaligus
- Mereka terobsesi pada visi dan keterampilan mereka sendiri, bukan pada OKR, KPI, data, atau pendapat orang lain
- Sosok luar biasa bisa memiliki opini yang kuat, ego besar, cara sendiri, sisi kasar, dan rasa muak terhadap mediokritas
- Karena karakteristik ini, mereka sulit dipekerjakan di perusahaan biasa, dan kemungkinan besar mereka sendiri juga tidak ingin bekerja di sebagian besar perusahaan
- Jika Anda bisa menemukan orang hebat, tidak menghalanginya, dan mampu menahan intensitasnya, Anda bisa mempercayakan kendali produk dan perusahaan kepadanya
- Secara realistis, orang seperti itu sulit ditemukan; mereka mungkin tidak mau bekerja bersama, atau perusahaan mungkin tidak sanggup menahan ego dan intensitas mereka
Saat struktur untuk tokoh besar diterapkan kepada PM biasa
- Kesalahan terbesar adalah mengadopsi model operasi yang membutuhkan sosok luar biasa tanpa adanya sosok luar biasa itu
- Penulis mengkritik bahwa PM karier yang bisa direkrut perusahaan dengan nyaman umumnya bukan orang di level seperti itu
- Mereka digambarkan sebagai pesuruh bisnis, fanatik framework, subject matter expert, mantan builder yang naik tangga korporat, pecandu metrik, lulusan MBA, dan sebagainya
- Jika “product-led” dipahami sebagai PM yang membuat semua keputusan lalu perusahaan merekrut PM karier, dampaknya bisa fatal
- Karena PM seperti ini kekurangan visi, karisma, keahlian, keyakinan kuat, dan kemampuan teknis, mereka bergerak aman dan bertindak politis
- Karena menyadari kekurangannya sendiri, mereka berulang kali berusaha mengambil kredit atas hasil tetapi menghindari tanggung jawab
Bagaimana data dan proses menjadi sarana pertahanan
- Tahap pertama adalah mempersenjatai pengambilan keputusan berbasis data
- Mereka tidak mengakui bahwa data pendukung bisa ditemukan untuk hampir klaim apa pun, lalu membungkus keputusan mereka sendiri sebagai satu-satunya yang rasional berdasarkan data
- Jika sesuatu berjalan salah, mereka menyalahkan pasar, kualitas data, atau nasib buruk perusahaan, dan mengklaim itu bukan tanggung jawab mereka
- Tahap berikutnya adalah memperkenalkan framework dan peran untuk segala hal
- Muncullah framework karier 18 langkah, evaluasi kinerja kuartalan, PI planning, ADR, PRD, RACI, MOSCOW, OKR, KPI, DORA, SAFe, dan lain-lain
- Tidak mengikuti proses, tidak berbasis data, dokumentasi kurang, atau dokumentasi tidak mutakhir menjadi alasan untuk menyalahkan orang
- Organisasi mulai memiliki peran seperti Director of KPIs, Deputy Director of Product Operations, dan Global Head of Digital Whiteboard Solutions
- Segala hal membutuhkan persetujuan, dan tidak ada proses atau area yang benar-benar dikendalikan penuh oleh satu orang
- Dalam komite besar, siapa pun bisa berkata “no”, tetapi tidak ada yang bisa sepenuhnya berkata “yes”
- Rapat juga meledak jumlahnya
- Laporan status, rapat penyelarasan, 1:1, rapat staf, diskusi strategi, penetapan konteks, release go/no-go, laporan proyek, dan lain-lain bertambah
- Tahap terakhir adalah merekrut banyak orang yang buruk
- Perekrutan dilakukan berdasarkan apakah kandidat tidak menjadi ancaman, sementara tanda-tanda keunggulan menjadi alasan penolakan
- Rekrutan ideal menjadi sosok generalis yang cukup mampu mengerjakan apa yang diperintahkan tanpa pendapat berlawanan atau kepedulian terhadap kualitas
- Jumlah PM melonjak, dan di setiap tim serta area muncul lapisan PM yang mengulangi perilaku yang sama
Apa yang hilang dari organisasi
- Begitu arus di mana orang biasa memegang kewenangan dimulai, orang-orang unggul pada akhirnya akan pergi
- Mereka tersingkir oleh diktator medioker, atau pergi sendiri karena sulit bertahan dalam lingkungan tersebut
- Kecepatan kerja berhenti, dan mengeksekusi sesuatu menjadi menyakitkan, berupa komitmen besar sekaligus percobaan yang berisiko
- Visi besar dianggap tidak realistis dan cepat dibuang
- Pekerjaan perusahaan terbatas pada low-hanging fruit dan pilihan aman
- Bahkan orang yang tidak terlalu bersemangat terhadap keterampilannya pun merasakan penderitaan lalu pergi; sementara orang yang cukup tumpul untuk bertahan justru memperburuk masalah
- Perusahaan kehilangan talenta terbaik, melupakan visi, menjadi berorientasi ke dalam, dan kehilangan makna
- Dalam skenario terbaik, perusahaan mati pada suatu titik; dalam skenario terburuk, ia bertahan setengah hidup sebagai sesuatu yang mengubah orang penuh semangat menjadi zombi yang membenci pekerjaannya
Alternatifnya adalah tim berisi orang-orang yang unggul dalam keseharian
- Selain mencari dan merekrut sosok luar biasa, menyerahkan kendali kepadanya, dan menahan intensitasnya, ada cara lain untuk membangun perusahaan produk yang sukses
- Alternatifnya adalah merekrut orang-orang yang unggul dalam keseharian
- Masing-masing harus unggul di suatu bidang
- Mereka harus terobsesi pada keterampilannya sendiri dan digerakkan oleh kualitas
- Tim dibentuk agar area keunggulan mereka saling tumpang tindih seminimal mungkin
- Alih-alih membagi tanggung jawab individu menjadi potongan kecil, biarkan mereka menikmati pekerjaan yang mereka sukai dan menggunakan waktu serta keterampilannya untuk perusahaan
- Orang-orang seperti ini juga bisa menantang, keras kepala, berego kuat, unik, dan berubah-ubah
- Jika diberi masalah yang baik dan kesempatan untuk melakukan pekerjaan hebat, mereka akan sepenuhnya berkomitmen pada keberhasilan perusahaan
Di mana seharusnya posisi pemimpin dan PM
- Tidak perlu sepenuhnya menyingkirkan pemimpin; perusahaan bisa menghapus team lead dan menempatkan area lead sebagai koordinator eksternal-internal
- Jika setiap area memiliki pemimpin yang bertanggung jawab, peran itu harus diisi oleh orang yang mendekati sosok besar
- Yakni orang yang mendekati Jobs, Musk, dan Bezos dalam hal visi, karisma, intensitas, gairah, dan perilaku ekstrem
- Jika orang yang nyaman dalam jangka pendek, patuh pada instruksi, dan menuntut lebih sedikit perhatian ditempatkan sebagai penanggung jawab, ada risiko terjerumus ke situasi yang dijelaskan di atas
- Peran PM dalam arti tradisional dipandang tidak punya tempat di perusahaan yang berjalan baik
- Namun, tetap dibutuhkan orang yang terobsesi pada area yang secara tradisional dipercayakan kepada PM, seperti product discovery dan product observability
- Orang-orang seperti ini mungkin pernah memiliki jabatan PM, dan itu sendiri bukan masalah
- Alasan merekrut mereka adalah obsesi dan kekuatan mereka, bukan jabatan
- Alih-alih menempatkan mereka dalam peran PM terpisah, tempatkan mereka dalam satu tim bersama orang-orang yang terobsesi pada engineering, desain, performa, bisnis, dan pengetahuan domain
Ini bukan hanya masalah PM
- Masalah yang sama muncul ketika orang tanpa visi, karisma, gairah, kemampuan teknis, dan kemauan kuat menjadi penanggung jawab
- Alasan fokus pada PM adalah kecenderungan dalam pengembangan produk perangkat lunak untuk menempatkan orang dengan jabatan product manager sebagai penanggung jawab
- Sebagian PM benar-benar luar biasa dan bisa sangat berhasil dalam kedua model
- Namun, PM seperti itu belum tentu lebih baik daripada orang hebat dengan latar belakang berbeda
- PM seperti itu adalah minoritas yang sangat kecil, dan sebagian besar PM karier dinilai tidak mendekati kemampuan untuk memimpin dengan keunggulan
1 komentar
Komentar Hacker News
Di perusahaan saya saat ini ada banyak orang pintar, tetapi karena berbagai alasan tidak ada manajer produk, dan akibatnya pekerjaan yang seharusnya dilakukan manajer produk jadi tidak dikerjakan sama sekali
Hampir tidak ada engineer yang ingin mengerjakan hal-hal seperti menjaga hubungan dengan pelanggan, wawancara pengguna, menggali fitur potensial, meyakinkan pimpinan, atau politik untuk alokasi sumber daya
Di perusahaan sebelumnya, 2 dari 3 manajer produk tidak kompeten dan dipecat, tetapi 1 orang benar-benar luar biasa, dan hanya dengan sebagian waktunya saja dia berhasil menyelesaikan lebih banyak dalam 1 tahun daripada yang dilakukan perusahaan saya sekarang selama lebih dari 2 tahun
Saya setuju bahwa jumlah manajer produk yang baik tidak cukup. Jumlah orang yang bisa menjadi manajer produk yang baik bertambah secara linear terhadap populasi, tetapi industri software meledak secara eksponensial, jadi menurut saya sekarang dibutuhkan 100 kali lebih banyak peran PM daripada jumlah PM yang benar-benar hebat
Mereka juga tidak cukup teknis sehingga tidak mengelola tiket Jira, dan pengelolaan ke pimpinan umumnya ditangani para manajer
Sepertinya manajer produk itu terutama menghadiri rapat, berbicara dengan pimpinan, berbicara dengan engineer, menulis dokumen, dan memimpin rapat perencanaan sprint yang makin panjang
Menurut saya, manajer produk yang menangani masalah pelanggan, pengguna, dan sumber daya akan jauh lebih bernilai
Saya terus mendengar kalimat, “Kami adalah perusahaan yang mengutamakan engineering”, tetapi kenyataannya itu berarti tim-tim engineering bebas mengejar teknologi terbaru sesuka hati mereka
Produk utama kami ada 3,5, atau sebenarnya 4,5, dan masing-masing dibuat dengan tech stack yang berbeda; selain itu ada sekitar 8 produk lagi yang harus didukung karena kebutuhan legacy. Tidak ada standardisasi atau interoperabilitas antarproduk, dan transfer pengetahuan pun tidak terjadi, jadi biaya pengembangan melonjak gila-gilaan
Tahun ini saja, dua kali saya harus menjelaskan kepada engineer dengan masa kerja 20 tahun mengapa buruk jika satu API hanya memakai TLS 1.3, yang lain 1.x, dan yang lain lagi bahkan tidak mewajibkan TLS sama sekali
Pelanggan membenci kami. Produk saya dibuat dengan cara materi pemasaran ditulis lebih dulu lalu engineer disuruh membangunnya sendiri. Satu tahap untuk memindahkan data Oracle ke parquet dibuat dengan tiga bahasa dan dua DB perantara (MySQL dan PG), dan saya nyaris saja harus menerima Redis juga kalau tidak saya hentikan
Untungnya, dua tahun lalu perusahaan ini diakuisisi oleh private equity dan sekarang kami diberi ultimatum: kalau tidak menghasilkan uang, selesai. Selama 20 tahun perusahaan ini tidak pernah menghasilkan uang dan hanya menjadi cost center, dan bahkan kalau kami gagal mencapai target, rasanya alam semesta akan jadi lebih baik jika bencana desain software yang kami buat ini menghilang
Manajer produk yang bodoh akan menjadi semacam pseudo-project manager yang hanya melacak buku besar pekerjaan lain, sementara orang yang pintar akan memahami bisnis secara mendalam lalu dipromosikan atau pergi
Peran ini juga sulit dikelola. Kadang mengambil kredit besar untuk pekerjaan orang lain, kadang sama sekali tidak diakui sehingga kariernya mandek
Jika peran ini dilemparkan ke engineering, engineering management, atau manajemen umum, kemampuan engineering akan melemah. Jika Anda harus merekrut engineer, Anda seharusnya memilih berdasarkan kemampuan itu dan melindungi mereka dari orang luar; tetapi jika tim juga harus menangani interaksi, Anda akan merekrut orang dengan kemampuan campuran dan pada akhirnya sisi engineering menjadi terdilusi
Sengaja menjaga kapasitas manajer produk tetap sempit bisa menjadi mekanisme paksa agar mereka fokus pada level tinggi dan visi, serta menghindari kecenderungan masuk terlalu dalam lalu membuat proses yang tidak berguna atau mendefinisikan fitur secara berlebihan
Di industri teknologi yang menggelembung lebih dari 10 tahun karena pertumbuhan berbasis suku bunga rendah, banyak orang pada dasarnya bisa sukses hanya dengan datang bekerja
Tulisan yang membingungkan. Sambil mengatakan “peran PM harus dihapus”, di saat yang sama ia juga berkata “orang yang secara khusus menangani pekerjaan yang dulu dilakukan PM tetap dibutuhkan, tetapi jangan sebut itu PM, anggap saja orang hebat yang biasa saja”
Penulis tampaknya punya pengalaman buruk dengan PM, dan dari pembahasan soal MBA jejaknya terlihat, jadi rasanya ia ingin membuang bayinya bersama air mandinya
Ketika skala bisnis membesar, spesialisasi peran muncul dan menjadi perlu. Ada PM yang buruk dan ini memang pekerjaan yang sulit, tetapi jika tim kami kehilangan PM kami, itu akan sangat mengecewakan
Bisa jadi aku hanya pernah punya pengalaman baik dengan PM, tetapi PM di perusahaan kami memahami apa yang diinginkan pelanggan dan apa yang harus disediakan produk, lalu bersama engineering manager menyeimbangkan apa yang secara teknis memungkinkan dan kapasitas implementasi yang tersedia
Jika engineering manager mengatakan, “jadwal ini sama sekali tidak mungkin,” PM akan menemukan rencana alternatif untuk produk tersebut
Tulisan ini tampak seperti melewati tahap tengah itu dan hanya ingin mengganti namanya tanpa alasan yang jelas
Tepatnya siapa yang menurutnya menentukan masalah mana yang harus diprioritaskan tim? Itulah tanggung jawab inti peran PM
Pada akhirnya, tampaknya ia pernah punya pengalaman buruk dengan PM yang gagal membuat keputusan prioritas itu
Hanya saja, karena orang itu aku harus masuk ke rapat paling canggung yang pernah kuhadiri: selama satu jam penuh dari awal sampai akhir, ia memperlihatkan di depan manajer senior bahwa ia sama sekali tidak memahami produknya, sementara manajer senior itu justru memahaminya
PM yang baik sangat membantu karena mereka memahami apa yang diinginkan pelanggan, apa yang bisa kami berikan, jadwal yang realistis, serta cara menangani pemangku kepentingan hukum dan bisnis. Aku membantu mereka ketika perlu memeriksa sisi teknis
Tim jarang kekurangan ide tentang apa yang bisa dibuat atau bagaimana meningkatkan pengalaman produk dan operasional. Product manager adalah orang yang memastikan kita membangun hal yang benar
Aku PM dengan 20 tahun karier di IT, dan sedang mempertimbangkan MBA agar bisa memperoleh pengetahuan dan pemahaman bisnis formal yang membantu pertumbuhan ke depannya
PM seperti aku tidak akan langsung mulai bermain-main dengan omong kosong, meminjam istilah militer, begitu selesai mendapat MBA
Masalahnya adalah orang-orang yang langsung melaju dari SMA, kuliah, MBA, lalu ke jabatan manajerial. Selain magang singkat di tengah program sarjana, sering kali mereka tidak punya pengalaman lapangan satu hari pun
Tulisan yang aneh. Banyak kata dipakai, tetapi pada akhirnya bukankah ini cuma mengatakan “kalau merekrut orang berkinerja rendah, perusahaan akan dirugikan”?
Alternatifnya juga seperti “rekrut orang bagus, tetapi jangan rekrut mereka untuk peran PM”
Ini terbaca seperti tulisan orang yang pernah punya pengalaman buruk dengan PM yang menganggap dirinya Steve Jobs. PM juga cuma orang biasa; aku tidak mengerti kenapa diasumsikan semua orang yang memegang jabatan itu pasti punya rasa berhak istimewa
Sebuah organisasi bisa punya ribuan PM dan masing-masing punya atasan. Pokoknya tulisan yang aneh
Kurang lebih seperti, “jangan rekrut product manager, karena mereka tidak akan menjadi orang hebat. Sebagai gantinya, rekrut orang hebat, dan bukan cuma satu orang, tetapi seluruh tim!”
Setiap hari mereka merekrut orang berkinerja rendah dan aku tidak tahu kenapa. Simpanse tak terlatih yang memegang setumpuk resume rasanya bisa punya tingkat keberhasilan yang lebih baik
PM memenuhi kebutuhan yang sangat spesifik. Kebutuhan itu sulit dikuantifikasi, tetapi bisa dibilang tanpa PM yang bagus semuanya akan runtuh
Biasanya mereka mengumpulkan informasi tentang apa yang bisa dan tidak bisa dilakukan untuk pengguna umum, mendengar dari para eksekutif apa yang diperlukan untuk menjalankan perusahaan, memahami ke mana arah industri dari para pemimpin industri, bekerja dengan desain, lalu memurnikan semua ini menjadi fitur yang benar-benar harus dibangun
Mereka juga bersama engineering menilai apa yang praktis, kira-kira berapa lama waktu yang dibutuhkan, menghapus fitur yang butuh waktu lama tetapi nilainya rendah, serta membantu agar estimasi dan kecepatan tim cukup bisa diprediksi
Itu saja sudah menjelaskan pekerjaan setara 1,5 orang. Jika organisasi produk dihapus, semua pekerjaan ini tersebar ke tim engineering, dan tidak semua anggota tim bisa melakukannya dengan baik
Bahkan jika keseimbangannya tercapai, ketika satu orang pergi akan muncul kekosongan tak terlihat yang bahkan tidak dicari saat perekrutan
Banyak tim tampaknya trauma oleh organisasi produk yang disfungsional. Organisasi seperti itu terlihat terputus dari, atau tidak peduli pada, sisi pelanggan, industri, dan organisasi; sebaliknya mereka malah membakar banyak waktu dalam rapat mengulang-ulang mockup, melakukan micromanagement pada desainer sampai orang bagus pergi, dan menahan engineer dalam rapat produk yang tidak perlu
PM bekerja erat dengan tim untuk mendefinisikan roadmap dan memprioritaskan hal-hal yang memberi dampak terbesar bagi pelanggan dan bisnis
Jika PM menjalankan pekerjaannya dengan baik, engineer akan memahami dengan sangat jelas masalah apa yang harus dipecahkan berikutnya dan mengapa itu harus dipecahkan
Kedua, penting juga apakah mereka punya posisi dalam organisasi yang memungkinkan mereka berkomunikasi dengan manajemen puncak tentang proyek. Jika punya kedua atribut itu, berarti kondisinya bagus
Yang saya pelajari setelah bekerja lebih dari 12 tahun di industri teknologi adalah bahwa peran hanyalah cara mengekspresikan keinginan organisasi.
Jika mereka ingin seseorang berpikir dari sudut pandang produk, mereka membuka posisi PM; jika mereka ingin seorang team lead, mereka membuat posisi engineering manager.
Jabatan adalah elemen fiktif yang memungkinkan kita memainkan RPG bernama pekerjaan dari berbagai sudut. Pada akhirnya, yang dibawa ke tempat kerja adalah kombinasi unik dari bakat dan pengalaman masing-masing.
Sebagian orang kadang melampaui batas-batas peran seperti ini, dan itu tidak masalah. Mereka punya ide dan bahkan bisa menciptakan jabatan mereka sendiri.
Organisasi harus cukup cerdas untuk membiarkan orang-orang seperti itu bertumbuh dan berkembang. Ini bukan berarti Anda tidak bisa sukses sebagai PM atau melakukan pekerjaan hebat, melainkan bahwa organisasi biasanya tidak meluangkan cukup waktu untuk benar-benar mengenali orang yang mereka rekrut, jadi mereka menawarkan peran yang sudah dipaketkan sebelumnya
Engineer juga bisa menjalankan peran PM, tetapi mereka tidak akan memikirkan segala hal dari sudut pandang PM, karena identitas utama mereka bukan PM melainkan engineer.
Dalam konteks melampaui batas peran, hal lain yang saya sadari adalah bahwa sering kali bagian paling berharga dari peran seseorang adalah tanggung jawab yang tidak didefinisikan secara eksplisit.
Sulit dijelaskan, tetapi orang sering memberi nilai dengan cara yang sulit digambarkan atau diukur
Secara keseluruhan ini sudut pandang yang cukup harsh, tetapi jelas ada bagian yang benar. Saat organisasi produk terbentuk di dalam perusahaan, ada kecenderungan untuk mengarah ke komite, OKR, siklus review, perencanaan, dan banyak birokrasi seperti yang digambarkan penulis.
Dulu saya sangat berhasil mendorong produk lewat pengaruh dalam peran sales engineering yang berhadapan langsung dengan pelanggan, lalu dengan naif mengambil pekerjaan product manager karena mengira saya akan mendapat kendali formal.
Setelah duduk di kursinya, ternyata itu pekerjaan kantor yang sangat dibatasi dan sama sekali tidak cocok untuk saya. Sebagian besar isinya adalah mengelola tiket dan backlog, menyelaraskan alih-alih mengambil keputusan, serta menulis laporan PowerPoint tanpa akhir; pekerjaan paling kreatifnya adalah membuat proses agar perusahaan bisa meresmikan product roadmap. Saya kabur setelah 6 bulan.
Fungsi ini cukup berguna untuk memberi visibilitas atas apa yang sedang dibuat dan mengelola prioritas yang saling bertentangan dalam produk yang sedang bertumbuh. Tetapi ini bukan pekerjaan membentuk atau mengendalikan arah evolusi produk.
Ini fungsi penyortiran, pemfilteran, dan kalau beruntung pengumpulan data, sekaligus menciptakan jejak keputusan yang bisa diaudit dan kesan adanya pengambilan keputusan yang matang agar para MBA di atas bisa tidur sedikit lebih nyenyak
Biasanya saya membuat 4 sampai 12 proposal fitur baru (PRD) per bulan, dengan jumlah yang berbeda tergantung ukuran perusahaan dan seberapa banyak proses yang dibutuhkan.
Bentuknya selalu seperti, “pengguna saat ini punya masalah X, dan untuk menyelesaikannya kita harus membuat Y. Y akan terlihat seperti ini…”
Tentu ada kesulitan dalam penyelarasan dan komunikasi, tetapi tujuannya selalu untuk mencari tahu apa yang harus dibuat berikutnya.
Saya paham tidak semua peran PM seperti ini, tetapi saya tidak setuju dengan anggapan bahwa PM tidak bisa menjadi lebih baik daripada sekadar “teater penyelarasan/pemfilteran/kematangan keputusan”.
Jika perannya hanya menyusun urutan backlog yang sudah ada, saya jadi penasaran siapa yang mendefinisikan item-item baru yang masuk ke backlog
Saya setuju bahwa organisasi produk bisa menjadi entitas politik dan birokratis, bukan pihak yang mendukung.
Secara pribadi saya berpikir peran produk seharusnya tertanam di dalam tim engineering dan melapor ke pemimpin yang sama. Soal levelnya bisa diperdebatkan, tetapi dengan begitu PM yang buruk bisa ditangani seperti engineer yang buruk.
Tentu saja, kalau perusahaan bahkan tidak bisa menyingkirkan engineer yang buruk, berarti ada masalah lain
Penulis tidak banyak menawarkan framework untuk hal ini
Solusi dalam tulisan ini berbau teori orang besar.
Bagian penutup yang mengatakan bahwa “orang-orang luar biasa membayangkan realitas alternatif, mendedikasikan diri sepenuhnya pada pekerjaan, dan memindahkan gunung dengan kekuatan kehendak” terasa terlalu reduksionis.
Yang memindahkan gunung bukanlah kekuatan kehendak, melainkan orang-orang di bawah yang benar-benar mewujudkan visi itu. Paling banter, “orang besar” itu hanya menyelaraskan insentif agar para pelaksana dan ahli yang sesungguhnya bergerak
Saya bekerja di perusahaan teknologi besar yang saat ini hampir tidak memiliki peran PM, jadi saya bisa memberi kesan langsung.
Sejauh ini hasilnya campuran. Saya juga pernah bekerja di organisasi yang punya banyak PM dan saya setuju organisasi seperti itu kurang bagus. Tetapi pada akhirnya pekerjaan yang biasa dilakukan PM tetap perlu dikerjakan.
Di organisasi kami, tanggung jawab itu secara resmi jatuh ke software manager dan developer senior ke atas.
Misalnya, jika Anda memimpin sebuah inisiatif tim sebagai engineer senior, Anda harus bertanggung jawab atas semua aktivitas yang biasanya dilakukan PM. Aktivitas lain ditangani manajer atau senior manager.
Dari sudut pandang developer, ini cukup berat. Sebagai individual contributor Anda tetap harus menyelesaikan pekerjaan sendiri, sambil mengoordinasikan orang lain dan memastikan pekerjaan selesai.
Bukan hanya pekerjaan tambahan, tetapi terus terang banyak developer tidak punya keterampilan untuk menjadi PM yang efektif. Kolaborasi lintas tim juga menjadi lebih sulit karena Anda harus mengoordinasikan orang-orang dengan struktur pelaporan yang berbeda.
Pendekatan ini sering berujung pada kurangnya ownership, kurangnya akuntabilitas, upaya yang tumpang tindih, pekerjaan yang lolos di celah, dan kekacauan secara umum.
Namun, ini bekerja dengan baik untuk inisiatif kecil di dalam tim yang hanya melibatkan beberapa orang. Karena ini menghilangkan overhead PM dan memberi kendali kepada orang-orang yang membangun. Tetapi saya tidak yakin ini cocok juga untuk inisiatif yang lebih besar
Memang benar banyak developer tidak punya keterampilan PM yang efektif, tetapi kalau adil, banyak PM juga tidak punya keterampilan PM yang efektif.
Kesulitan mengoordinasikan orang-orang dengan struktur pelaporan berbeda juga sama saja bagi PM.
Perbedaan utamanya tampaknya adalah penilaian apakah “pekerjaan ini layak dipisahkan menjadi peran khusus”. Saya cenderung berpikir bagi engineer hampir selalu tidak layak
Hanya dari judulnya saja, saya sudah siap untuk tidak menyukainya. Saya kira ini akan jadi tulisan tipikal “PM itu bodoh dan perusahaan hanya butuh insinyur cerdas yang menguasai dunia”
Tapi ternyata bukan tulisan seperti itu, dan menurut saya masalahnya sendiri dibedah hampir dengan sempurna
Hanya saja solusinya menguap begitu saja seperti lambaian tangan. Kurang lebih seperti, “rekrut orang-orang biasa yang hebat, masing-masing unggul dalam sesuatu, terobsesi pada keahlian mereka, dan digerakkan oleh kualitas, lalu ikat mereka dalam tim dan biarkan mereka bekerja tanpa tanggung jawab individual”
Kedengarannya bagus, tapi siapa yang bisa menyebut contoh pendekatan seperti ini berhasil di perusahaan dengan lebih dari 100 orang? Saya tidak tahu bagaimana ini bisa bekerja di dunia nyata
Sepertinya Valve menjalankan, atau setidaknya pernah menjalankan, pendekatan yang sangat mirip. Buku panduan karyawan mereka[0] dulu sering muncul di HN, tapi belakangan jarang terlihat. Saya penasaran apakah itu benar-benar bekerja baik untuk mereka
[0] https://steamcdn-a.akamaihd.net/apps/valve/Valve_NewEmployee...
Penulisnya tampaknya benar-benar pernah bekerja dengan manajer produk yang sangat biasa-biasa saja. Saya seorang PM dengan latar belakang engineering otodidak, dan saya sudah melihat banyak orang biasa-biasa saja di berbagai bidang
Saya memandang pekerjaan saya terutama sebagai manajemen risiko. Bahkan tim yang terdiri dari insinyur dan desainer hebat pun menghadapi banyak risiko dalam proses meluncurkan produk yang bagus
Mereka mungkin tidak punya keterampilan untuk menjelaskan visi dan meyakinkan orang lain, atau tim legal bisa saja memberi persyaratan atau batasan pada apa yang boleh dan tidak boleh dilakukan
Pekerjaan saya adalah mengelola hal-hal itu agar keunggulan tim bisa keluar, dan membantu tim tetap fokus pada hal yang benar-benar penting, yaitu membuat dan meluncurkan produk yang bagus
Keberhasilan saya saya nilai dari seberapa tidak perlunya saya lagi. Tujuannya adalah menjadi tidak dibutuhkan, agar tim memiliki konteks, kepercayaan diri, dan dukungan untuk membuat keputusan yang baik tanpa saya
Saya suka bekerja bersama para insinyur agar mereka mengembangkan kemampuan itu, dan bersama partner manajer engineering saya berusaha memahami kekuatan, kelemahan, dan tujuan tiap insinyur untuk menemukan cara agar mereka bisa berkembang
Saya paham argumen bahwa dalam utopia ideal saya mungkin tidak dibutuhkan. Tapi dalam kebanyakan kasus, untuk melakukan pekerjaan yang benar-benar hebat, kita akan menghadapi tantangan dan risiko, dan PM yang baik adalah penambah nilai bersih yang membantu tim melewati semua itu
Artinya memastikan tim punya konteks, persyaratan, wawasan, metrik, tujuan, dan lain-lain yang dibutuhkan untuk melakukan pekerjaan terbaik mereka, serta memahami masalah apa yang harus diselesaikan, untuk siapa, dan mengapa
PM yang baik menciptakan lingkungan yang begitu rapi sampai insinyur bisa berpikir, “PM tidak melakukan apa-apa jadi tidak dibutuhkan.” Penilaian seperti itu picik dan, sejujurnya, menghina