Beberapa Hal yang Menurut Gw Bikin Seorang PM itu Bagus

Gw agak ragu sebenarnya nulis artikel dengan tema how to be a good Product Manager.

Masalahnya sederhana:

emang gw udah jadi good PM?

Kayaknya terlalu pede kalau gw sendiri yang jawab iya.

Jadi tulisan ini bukan tutorial tentang bagaimana menjadi Product Manager yang bagus. Anggap aja ini hasil pengamatan gw setelah beberapa tahun kerja sebagai PM dan ketemu banyak orang dengan title yang sama.

Ada atasan.

Peers.

Junior.

Ada juga PM dari company lain yang gw kenal, tulisannya pernah gw baca, atau pernah gw dengar ngomong di webinar.

Tapi gw pribadi lumayan skeptis menilai kemampuan orang cuma dari tulisan atau apa yang mereka sampaikan di depan publik.

Orang bisa terdengar sangat pintar ketika ngomong soal Product Management.

Apakah sehari-harinya dia benar-benar kerja seperti itu?

I have no idea.

Jadi tulisan ini mungkin lebih banyak dipengaruhi orang-orang yang pernah benar-benar kerja bareng gw. Orang yang pernah satu company, satu project, satu meeting, atau minimal pernah sama-sama pusing menghadapi problem yang sama.

Dari situ ada beberapa kali gw melihat seseorang bekerja dan mikir:

wah, orang ini keren nih jadi PM.

Dan pelan-pelan gw mulai memperhatikan apa yang sebenarnya bikin gw punya kesan seperti itu.

Tulisan ini juga sekaligus jadi catatan buat diri gw sendiri.

PM seperti apa yang sebenarnya pengen gw jadi?

Karena beberapa hal di bawah sudah lumayan bisa gw lakukan.

Beberapa masih belajar.

Dan ada satu yang sampai sekarang masih jadi PR besar.

Dua yang sudah pernah gw bahas: adapt dan belajar cepat

Di tulisan sebelumnya, Mungkin Product Manager Memang Ada Buat Ngisi Gap, gw sempat nulis bahwa kerjaan PM menurut gw sangat bergantung pada kondisi organisasi.

PM di satu company bisa sangat business-heavy.

Di tempat lain technical-heavy.

Di tempat lain lagi mungkin harus masuk cukup jauh ke UX, analytics, operations, atau apapun gap yang sedang ada.

Makanya dua hal pertama yang menurut gw penting adalah:

adaptability dan kemampuan belajar cepat.

PM yang terlalu rigid dengan:

“harusnya kerjaan PM tuh begini”

bakal sering kecewa ketika ketemu dunia nyata.

Tapi adapt aja gak cukup.

Lo juga harus bisa belajar cukup cepat supaya bisa useful ketika masuk ke domain yang belum lo ngerti.

Company bukan universitas.

Lo gak punya satu semester buat belajar struktur API sebelum ikut technical discussion.

Lo gak punya mata kuliah dua SKS sebelum boleh ngomong soal UX mental model.

Kadang hari ini lo gak ngerti.

Besok ada meeting.

Minggu ini harus bikin keputusan.

Bukan berarti harus jadi expert dalam semalam.

Tapi harus bisa belajar cukup cepat dan cukup tepat untuk problem yang sedang dihadapi.

Dua hal itu sudah gw bahas lebih panjang di artikel sebelumnya.

Tapi setelah gw pikir-pikir lagi, ada beberapa hal lain yang menurut gw sama pentingnya.

Dan salah satunya gw pelajari cukup keras dari mantan lead gw sendiri.

Jangan iya-iya mulu

Waktu di Moladin, gw pernah punya lead bernama Jonathan.

Di salah satu sesi 1-on-1 waktu gw masih probation, dia kasih feedback yang sampai sekarang masih nempel di kepala gw.

Kurang lebih dia bilang:

“Lo jangan iya-iya mulu. Ke UI/UX iya, ke Ops iya, ke Dev iya. Kalau semuanya lo iya-in, nanti lo sendiri bingung mana yang harus dibangun duluan.”

Jujur, setelah itu gw belum pernah lagi punya atasan yang cara kasih feedback-nya se-direct dia.

But damn, it was useful.

Untungnya gw bukan tipe yang gampang baper kalau dikasih feedback seperti itu.

Dan makin lama gw kerja, makin gw ngerti kenapa dia ngomong begitu.

PM gak bisa jadi Yes Man.

Karena request gak akan pernah berhenti.

Business mau A.

Operations mau B.

Marketing mau C.

Engineer mungkin punya technical improvement D.

Designer punya concern E.

Terus semuanya bilang:

urgent.

Kalau semuanya lo terima, semuanya lo akomodasi, dan semuanya masuk backlog dengan status “penting”…

ya sebenarnya gak ada yang penting.

Gw juga pernah melihat PM yang memang gak enakan.

Setiap request masuk diiyakan.

Semua mau diakomodasi.

Hasilnya bukan stakeholder jadi bahagia dan delivery makin cepat.

Justru PM-nya sendiri akhirnya kesulitan menentukan apa yang harus dibangun duluan, scope makin besar, dan delivery jadi lama.

Ini bukan berarti PM harus defensif terhadap setiap request.

Bukan juga berarti stakeholder selalu salah.

Tugas kita justru memahami:

mana yang benar-benar problem,

mana yang priority,

mana yang bisa nanti,

dan mana yang sebenarnya cuma nice to have.

Karena gw juga sudah beberapa kali melihat stakeholder sangat yakin minta fitur tertentu.

Dibikin.

Selesai.

Terus…

kagak dipakai.

Request yang datang belum tentu problem yang harus diselesaikan

Menurut gw kemampuan bilang “enggak” ini nyambung juga dengan salah satu hal yang gw pelajari dari The Lean Startup.

Kalau kita masih belum tahu sebuah ide bakal works atau enggak, ngapain langsung keluarin effort besar buat bikin semuanya lengkap?

Salah satu hal yang gw suka dari The Lean Startup adalah ide bahwa kalau kita masih menguji hipotesis, kita seharusnya mencari cara termurah dan tercepat untuk belajar apakah hipotesis tersebut benar.

Tapi realitanya, request sering datang dalam bentuk yang sudah sangat lengkap.

“Kita butuh fitur A.”

Harus ada ini.

Harus ada itu.

Flow-nya begini.

Ada dashboard.

Ada notification.

Ada automation.

Sekalian bikin configurable.

Padahal kita bahkan belum tahu apakah orang akan menggunakan basic functionality-nya.

Kalau PM gak nyaman challenge request, gampang banget akhirnya kita build sesuatu yang langsung perfect, lengkap, dan over-engineered untuk problem yang belum tentu terbukti ada.

Makanya menurut gw kemampuan untuk gak menjadi Yes Man bukan cuma soal berani nolak stakeholder.

Ini juga soal menjaga product supaya gak menghabiskan effort untuk sesuatu hanya karena orang yang request terdengar yakin.

Kadang jawaban yang benar memang:

yes.

Kadang:

not now.

Kadang:

kita coba versi kecilnya dulu.

Dan kadang:

kenapa kita butuh ini?

Nah, pertanyaan terakhir itu membawa gw ke hal berikutnya.

Jangan terlalu cepat merasa sudah tahu jawabannya

Ini juga salah satu pelajaran yang gw dapat dari Jonathan.

Bahkan sebelum gw resmi masuk Moladin.

Waktu interview, dia pernah kasih feedback bahwa gw masih terlalu cepat jump into conclusion.

Dan menurut gw dia benar.

Waktu itu gw masih cukup newbie di Product Management.

Kesalahan klasiknya adalah merasa bahwa tugas PM adalah memberikan solusi.

Ada orang datang membawa masalah.

Otak langsung:

“Oh, berarti bikin fitur ini.”

Ada request.

Langsung mikir flow.

Ada metric turun.

Langsung punya teori.

Kelihatannya productive.

Padahal bisa jadi kita cuma cepat salah.

Semakin lama gw kerja, semakin gw merasa salah satu kemampuan yang penting justru menahan diri untuk gak langsung punya jawaban.

Ada stakeholder minta fitur A?

Kenapa?

Problem apa yang sebenarnya terjadi?

Seberapa sering?

Siapa yang mengalami?

Sekarang mereka solve problem itu bagaimana?

Kenapa cara sekarang gak cukup?

Apa yang terjadi kalau kita gak build apapun?

Kadang setelah beberapa pertanyaan, request yang tadinya terdengar sangat jelas mulai berubah bentuk.

Dan kadang kita akhirnya sadar:

oh, ternyata problem-nya bukan itu.

Ini juga mungkin menjelaskan kenapa ada fitur yang sangat diminta sebelum dibangun tapi akhirnya hampir gak pernah dipakai setelah release.

Kita terlalu cepat menerima solution yang dibawa stakeholder tanpa cukup memahami problem di belakangnya.

Dan menurut gw PM gak harus menjadi orang yang selalu punya jawaban.

Malah kadang PM yang bagus adalah orang yang nyaman bilang:

“Gw belum tahu. Coba kita cari tahu dulu.”

Asking better questions is probably more useful than having faster answers.

Problem besar biasanya cuma problem kecil yang belum dipisah-pisah

Hal berikutnya adalah kemampuan breaking problems into smaller pieces.

Pertama kali gw cukup sadar dengan konsep ini justru dari buku Cracking the PM Interview, terutama dari latihan-latihan guesstimate.

Dulu mungkin kelihatannya seperti interview exercise aja.

“Seberapa banyak bola golf yang muat di dalam mobil Innova?”

“Seberapa banyak bangku bioskop yang ada di Provinsi Jakarta?”

Dan segala pertanyaan aneh lainnya.

Pertanyaan kayak gini mungkin sekilas terdengar gak jelas.

Toh kapan juga sebagai PM tiba-tiba CEO nanya berapa bola golf yang muat di Innova.

Tapi setelah kerja, gw makin ngerti kenapa cara berpikir seperti itu sering dites ketika interview PM, terutama untuk junior sampai mid-level.

Yang sebenarnya diuji bukan apakah tebakan angka akhirnya benar.

Yang menarik adalah:

ketika dikasih problem besar dan ambiguous, otak lo ngapain?

Apakah lo langsung asal sebut angka?

Apakah lo panik karena gak punya datanya?

Atau lo mulai memecah problem-nya?

Ukuran Innova kira-kira berapa?

Berapa space yang benar-benar bisa dipakai?

Ukuran satu bola golf berapa?

Ada kursi dan interior yang makan tempat berapa banyak?

Dari situ baru bikin asumsi dan estimasi.

Angka akhirnya bisa salah.

Tapi proses berpikirnya kelihatan.

Dan ternyata cara berpikir yang sama kepakai banget ketika kerja.

Karena problem di kerjaan jarang datang dalam bentuk:

Problem A disebabkan oleh variable X di step ketiga.

Enak banget kalau begitu.

Biasanya datangnya:

“Kenapa conversion kita turun ya?”

atau:

“Gimana caranya supaya lebih banyak user click button ini?”

atau:

“Order kita banyak yang gagal.”

That’s it.

Sekarang silakan pusing.

Yang menurut gw membedakan adalah apakah kita langsung overwhelmed oleh ukuran problem-nya, atau bisa mulai memecahnya.

Conversion turun.

Okay.

Semua traffic atau channel tertentu?

New user atau returning?

Mobile atau desktop?

Semua category atau cuma beberapa?

Drop-nya mulai dari PLP?

PDP?

Add to cart?

Checkout?

Payment?

Kapan mulai berubah?

Ada release?

Campaign?

Inventory issue?

Payment issue?

Satu problem besar tadi pelan-pelan berubah jadi beberapa problem kecil yang bisa dicek satu per satu.

Dan begitu problem bisa dipecah, kita bisa mulai isolate.

Begitu bisa isolate, kita bisa mulai bergerak.

Terdengar basic.

Tapi makin lama gw kerja, makin gw sadar kemampuan ini gak otomatis dimiliki semua orang.

Ada orang yang ketika dapat problem besar langsung stress duluan.

Panik.

Lompat ke solusi.

Atau malah mencoba menyelesaikan semuanya sekaligus.

Padahal kadang yang dibutuhkan cuma berhenti sebentar dan mulai motong problem-nya.

Buat yang tertarik belajar cara berpikir seperti ini, gw selalu suka merekomendasikan Problem Solving 101 dari Ken Watanabe.

Lucunya buku itu sebenarnya ditulis supaya problem solving bisa dipahami anak-anak.

Tapi surprisingly…

kayaknya lumayan banyak orang dewasa yang masih butuh baca juga.

Especially if you work in Product.

Lalu ada stakeholder management. Sayangnya.

Nah.

Ini bagian yang paling gw gak suka.

Dan mungkin justru salah satu yang paling penting.

Stakeholder management.

Sampai hari ini gw sendiri masih figuring this out.

Gw bukan orang yang terlalu bagus menyembunyikan rasa kesel.

Kalau gw gak suka sesuatu, muka gw bisa berubah.

Tone suara juga bisa berubah.

Gw cukup direct.

Dan sebagai orang yang kadang road rage juga, emotional regulation mungkin memang bukan achievement utama gw.

Jadi ya…

mungkin gw sendiri pernah jadi salah satu PM yang dibenci stakeholder.

Gw cukup nyaman bilang enggak ke request yang menurut gw gak masuk akal.

Problem-nya adalah:

bisa bilang enggak dan bisa menyampaikan enggak dengan baik ternyata dua skill yang berbeda.

Yang pertama menurut gw sudah lumayan.

Yang kedua?

Masih banyak PR.

Dan semakin lama gw kerja, semakin gw merasa kalau lo sudah bisa gak jadi Yes Man dan bisa maintain relationship dengan stakeholder setelah bilang enggak…

wah, tamat sih.

Lulus.

Karena sebagian besar hari PM memang dihabiskan berinteraksi dengan orang.

Meeting.

Diskusi.

Negotiation.

Alignment.

Follow-up.

Conflict.

Dan sayangnya orang-orang tersebut bukan API.

Mereka manusia.

Punya ego.

Mood.

Emosi.

Background.

Target.

Pressure dari atasannya.

Cara komunikasi.

Personal interest.

Kadang punya informasi yang kita gak punya.

Kadang juga…

ya memang ngeselin aja.

Ada banyak framework untuk stakeholder management.

Salah satu yang menurut gw cukup fun adalah Productboard yang pernah menggambarkan berbagai stakeholder sebagai Dangerous Animals of Product Management.

Ada berbagai tipe dan cara menghadapinya.

Useful sebagai mental model.

Tapi masalahnya tetap sama.

Manusia jauh lebih kompleks dari empat kotak matrix atau beberapa jenis hewan.

Mencoba bikin framework yang bisa memetakan semua stakeholder menurut gw kayak bikin API yang jumlah parameter-nya gak pernah selesai.

Jabatan.

Personality.

Domain knowledge.

Ego.

Mood hari itu.

Political power.

Personal target.

Hubungan dengan atasan.

Hubungan dengan kita.

Seberapa ngerti dia tentang product.

Seberapa peduli dia terhadap data.

Seberapa keras kepala.

Tambah terus.

Gak akan selesai.

Dan dari pengalaman gw, kombinasi manusianya juga macam-macam.

Ada yang keras kepala dan sebenarnya memang pintar.

Sulit, tapi kadang setelah dipahami argumennya memang ada isinya.

Ada yang gak terlalu ngerti domain-nya tapi cukup terbuka kalau diajak diskusi.

Masih enak.

Ada yang pintar dan gak keras kepala.

Nah ini jackpot.

Ada juga yang…

sudahlah.

Punya jabatan tinggi pula.

Good luck.

Point-nya, menurut gw gak akan ada satu framework stakeholder management yang works for everyone.

Treatment-nya memang harus berbeda.

Dan ironically, kemampuan membaca manusia seperti ini mungkin jauh lebih sulit dipelajari dibanding bikin PRD.

Gw sendiri masih belum punya jawaban bagus tentang bagaimana caranya jadi jauh lebih baik di bagian ini.

Tapi gw cukup yakin:

ini salah satu skill paling penting yang harus gw improve kalau gw mau jadi PM yang lebih bagus.

Jadi PM bagus menurut gw kayak gimana?

Kalau gw recap dari apa yang gw lihat selama beberapa tahun ini, list gw sebenarnya cukup pendek.

Adapt.

Karena bentuk pekerjaan PM berubah tergantung organisasi dan problem yang sedang dihadapi.

Learn fast.

Bukan belajar semuanya sampai expert. Belajar hal yang tepat, cukup dalam, dan cukup cepat supaya bisa useful.

Don’t be a Yes Man.

Request bukan command. Challenge, filter, prioritize, dan berani bilang enggak ketika memang perlu.

Don’t jump to conclusions too fast.

Problem datang dulu. Solution belakangan. Tanya lebih banyak sebelum merasa sudah tahu jawabannya.

Break problems into smaller pieces.

Ambiguity akan selalu ada. Kemampuan memecah sesuatu yang besar menjadi bagian yang bisa dianalisis dan dikerjakan membuat problem jauh lebih manageable.

Learn to manage stakeholders.

Yang terakhir ini gw sendiri masih belajar.

Probably akan terus belajar juga.

Terus mungkin ada yang nanya:

Kok gak ada bikin PRD?

Bikin mockup?

SQL?

Analytics?

Prioritization framework?

Roadmap?

Menurut gw itu semua tetap useful.

Tapi sebagian besar adalah hal teknis yang bisa dipelajari relatif cepat dan kebutuhannya juga sangat tergantung organisasi.

Ada company yang PM-nya gak pernah bikin mockup.

Ada yang sampai bikin high-fidelity Figma.

Ada yang punya analyst lengkap.

Ada yang PM-nya sendiri harus bongkar data.

Ada yang PRD-nya belasan halaman.

Ada yang cukup beberapa paragraf dan ngobrol langsung sama engineer.

Makanya gw lebih tertarik dengan hal-hal yang tetap kepakai ketika environment-nya berubah.

Cara menghadapi sesuatu yang belum lo ngerti.

Cara belajar.

Cara bilang enggak.

Cara bertanya.

Cara membongkar problem.

Dan cara bekerja dengan manusia.

Apakah enam hal tadi otomatis bikin seseorang jadi good Product Manager?

I don’t know.

Gw sendiri juga belum merasa menguasai semuanya.

Tapi dari orang-orang yang pernah benar-benar gw lihat bekerja dan bikin gw berpikir:

“wah, orang ini keren nih jadi PM,”

hampir selalu ada beberapa dari sifat tadi.

Jadi mungkin tulisan ini bukan checklist tentang bagaimana menjadi PM yang bagus.

Lebih tepatnya ini checklist tentang PM seperti apa yang suatu hari pengen gw jadi.

Masih ada yang sudah lumayan.

Ada yang masih jauh.

At least sekarang gw tahu PR-nya apa.