Mungkin Product Manager Memang Ada Buat Ngisi Gap

Gw masuk ke Product Management sebenarnya gak direncanakan dari awal.

Background pendidikan gw Telecommunications Engineering. Fokusnya lebih banyak ke network engineering, dan menjelang akhir kuliah gw lumayan banyak main di IoT.

Karena IoT sendiri berada di persimpangan antara hardware, network, dan software, mau gak mau gw mulai terpapar software development juga.

Ada mata kuliah pemrograman dasar. Pernah ambil mata kuliah pilihan mobile app development. Waktu magang dan ikut research/lab IoT juga lumayan sering kerja bareng software developer.

Circle pertemanan gw juga banyak yang anak Informatika.

Satu-satu mulai punya jalurnya sendiri.

Ada yang jadi frontend developer.

Backend developer.

QA.

UI/UX designer.

Sementara gw masih:

gw sebenarnya mau jadi apa?

Akhirnya FOMO juga.

Gw beli course web development di Udemy. Ikut sertifikasi BPPTIK/BNSP. Ikut bootcamp. Belajar frontend. Nyoba UI/UX. Bahkan sempat beli course digital marketing.

Di sisi network engineering gw juga belajar CCNA dan MikroTik. Sempat kepikiran ambil sertifikasinya, tapi waktu itu biaya ujiannya lumayan besar buat kondisi gw.

Basically gw nyobain banyak hal.

Bukan karena punya grand career plan.

Gw cuma lagi bingung.

Dan waktu itu ada sedikit tambahan pressure.

Gw nikah sebelum lulus kuliah.

Masih magang.

Kenapa?

Ya pengen aja cuy.

Probably bukan career advice yang akan kalian temukan di LinkedIn.

Tapi konsekuensinya cukup nyata. Sekarang gw punya istri yang harus dinafkahi dan gw perlu cari kerja full-time.

Problem-nya, lowongan IoT engineering waktu itu gak sebanyak software engineering. Network engineering ada, tapi jalan menuju beberapa sertifikasi yang lumayan membantu juga membutuhkan modal yang saat itu belum gw punya.

Alhamdulillah akhirnya gw dapat pekerjaan full-time pertama di Gamatechno sebagai IoT System Analyst.

Dan dari situlah semuanya malah makin bercabang.

Gw ternyata suka semuanya sedikit-sedikit

Kerja di IoT bikin gw makin sering berinteraksi dengan berbagai bagian dari software development.

Engineer.

Designer.

Business.

Customer.

Semakin lama gw kerja, semakin gw sadar satu hal yang agak mengganggu.

Gw suka belajar semuanya.

Tapi gw gak yakin mau menjadi spesialis di salah satunya.

Gw bisa tertarik belajar web development beberapa bulan, lalu pindah penasaran ke UX, terus ke networking, terus ke bisnis.

Gw suka ngerti cara sesuatu bekerja.

Tapi kalau harus deep dive bertahun-tahun di satu domain yang sama?

Hmm.

Suatu hari gw nemu sebuah artikel di Medium.

Sayangnya sampai sekarang gw gak ingat judul artikelnya atau siapa penulisnya. Yang gw ingat cuma dia cerita tentang pekerjaannya sebagai Product Manager di Tokopedia.

Gw baca.

Terus rasanya kayak:

lah, ini mah gw banget.

Dia cerita soal role yang harus ngerti banyak hal tanpa harus menjadi orang paling ahli di semuanya.

Jack of all trades, master of none.

Kalimat yang biasanya terdengar seperti kritik malah terasa seperti deskripsi diri gw sendiri.

Gw suka teknologi.

Gw tertarik UX.

Gw penasaran bisnis.

Gw suka ngerti cara banyak hal bekerja.

Gw gampang penasaran.

Dan, admittedly, gw juga gampang bosan.

Ternyata ada pekerjaan yang justru membutuhkan kombinasi aneh itu.

Product Management.

Dari artikel itu gw mulai serius belajar.

Ikut bootcamp Product Management di Apiary Academy dan Binar Academy. Baca buku mulai dari The Lean Startup, Inspired, Cracking the PM Interview, dan segala macam materi PM yang waktu itu bisa gw temukan.

Lumayan banyak uang yang gw keluarkan untuk belajar.

Tapi kali ini beda dengan fase gw beli course random sebelumnya.

Untuk pertama kalinya gw cukup yakin:

kayaknya ini memang kerjaan yang cocok buat gw.

Alhamdulillah, di Gamatechno kemudian gw juga dipercaya menjadi semacam Product Owner untuk salah satu produk IoT mereka.

Dari sana gw akhirnya bisa pindah full ke Product Management.

GoKampus.

Kemudian Moladin.

Dan sekarang Erajaya.

Title-nya kurang lebih sama.

Tapi ternyata kerjaannya gak pernah benar-benar sama.

Dan justru dari situ pemahaman gw tentang Product Management mulai berubah.

Bootcamp bilang PM ada di tengah Business, Tech, dan UX

Kalau pernah belajar Product Management dari bootcamp, buku, atau artikel internet, kemungkinan besar kalian pernah lihat diagram yang sama.

Tiga lingkaran.

Business.

Technology.

User Experience.

Di tengah-tengahnya:

Product Manager.

Kadang ada juga versi yang lebih dramatis:

“The CEO of the Product.”

Dulu gw lumayan percaya dengan gambaran itu.

And to be fair, menurut gw itu gak sepenuhnya salah.

Diagram tersebut cukup berguna untuk menjelaskan bahwa PM harus memahami beberapa domain sekaligus dan membantu mereka bergerak menuju tujuan yang sama.

Problem-nya baru muncul ketika kita mulai menganggap diagram itu sebagai job description universal.

Karena setelah kerja di beberapa jenis organisasi, gw menemukan sesuatu yang agak berbeda.

Gw pernah berada di software house di mana sebagai product gw literally ikut bikin UX design di Figma.

Bukan sekadar wireframe atau mockup kasar buat diskusi.

High-fidelity design yang kemudian benar-benar dikonsumsi frontend developer untuk dibangun.

Pernah juga di startup kecil dengan jumlah orang yang gak banyak, di mana product bisa ikut nyemplung ke marketing, partnership, atau hal lain yang technically bukan “kerjaan product”.

Pernah di startup Series B dengan ratusan orang di product dan engineering, role yang lebih specialized, analyst sendiri, designer sendiri, engineering structure yang proper, dan product development cycle yang jauh lebih mendekati apa yang biasanya diajarkan di buku.

Lalu gw juga pernah berada di korporasi besar.

Organisasinya besar.

Stakeholder banyak.

Politics lebih terasa.

Pergerakannya lebih lambat.

Dan ketika ada gap di technical leadership atau koordinasi antar-system, product akhirnya gak bisa cuma datang bawa problem statement lalu bilang:

“How-nya urusan engineering.”

Ya good luck with that.

Kadang gw harus ikut cari API.

Baca documentation.

Ngerti system mana ngomong ke system mana.

Ngerti request dan response.

Ngerti payload.

Ngerti kenapa data di system A gak sampai ke system B.

Bahkan kadang expected API request dan response perlu cukup jelas di requirement supaya beberapa team berbeda gak pulang meeting dengan interpretasi yang berbeda-beda.

Apakah itu textbook Product Management?

Probably not.

Apakah pekerjaannya tetap harus selesai?

Unfortunately, yes.

Dan dari berbagai environment itu akhirnya gw sampai pada definisi Product Management yang sekarang lebih masuk akal buat gw.

Product Manager fills the gap

Menurut gw salah satu fungsi paling fundamental dari Product Manager adalah:

fill the gap.

Mengisi celah yang saat itu membuat product atau organisasi gak bisa bergerak dengan baik.

Gap-nya bisa berbeda-beda.

Di organisasi yang engineering-nya kuat tapi business context-nya lemah, PM mungkin harus jauh lebih business-heavy.

Di perusahaan yang sangat sales-driven tapi technical understanding-nya kurang, PM mungkin perlu menjadi orang yang cukup teknis untuk menerjemahkan kebutuhan bisnis ke system.

Kalau gak ada analyst, product mungkin harus jadi analyst.

Kalau UX maturity-nya rendah, product mungkin harus lebih banyak masuk ke UX.

Kalau company masih kecil dan gak punya partnership team yang cukup, product bisa aja ikut bantu partnership.

Kalau semuanya sudah mature?

Great.

Baru mungkin pekerjaan PM benar-benar terlihat seperti diagram tiga lingkaran yang cantik tadi.

Discovery.

Prioritization.

Strategy.

Roadmap.

Stakeholder alignment.

Outcome.

Semua orang punya scope yang jelas.

Sounds nice.

Tapi kita hidup di dunia nyata.

Dan organisasi di dunia nyata hampir selalu punya gap.

Ada fungsi yang belum mature.

Ada ownership yang gak jelas.

Ada team yang kekurangan capability tertentu.

Ada proses yang theoretically harusnya jalan, tapi kenyataannya belum jalan.

Dan kadang Product Manager memang jadi orang yang paling dekat dengan problem tersebut, jadi ya dia yang akhirnya perlu bantu nutup gap-nya.

Gw sudah berhenti terlalu sering bilang “harusnya PM gak begini”

Dulu gw juga pernah ada di fase:

“Harusnya product gak sampai bahas teknis sedetail ini.”

“Harusnya engineer yang menentukan implementation.”

“Harusnya product fokus ke problem.”

“Harusnya ada analyst yang kerjain ini.”

“Harusnya business yang handle itu.”

Dan mungkin secara organizational design, benar.

Memang harusnya begitu.

Tapi setelah beberapa kali pindah environment, gw mulai merasa pertanyaan yang lebih useful bukan:

“Harusnya siapa yang mengerjakan ini?”

Tapi:

“Sekarang ada gap apa yang bikin product ini gak bergerak?”

Kalau jawabannya technical clarity dan gak ada orang lain yang mengisinya, ya mungkin product perlu masuk.

Bukan berarti selamanya.

Bukan berarti organisasi gak perlu memperbaiki structure.

Dan bukan berarti PM harus menjadi dumping ground semua pekerjaan yang gak punya owner.

Itu distinction yang penting.

Fill the gap bukan berarti do everything.

Kalau setiap masalah dilempar ke PM karena “PM kan harus adaptif”, itu bukan Product Management.

Itu organizational dysfunction yang kebetulan dibebankan ke Product Manager.

Tapi selama gap tersebut genuinely menghambat product dan kita punya kemampuan untuk membantu menutupnya, gw sudah gak terlalu tertarik debat apakah pekerjaan itu secara textbook masuk job description PM atau enggak.

Selesaikan dulu problem-nya.

Setelah itu kalau gap yang sama terus muncul, baru tanya:

Kenapa gap ini ada?

Perlu hire orang?

Perlu ubah process?

Perlu ownership yang lebih jelas?

Karena PM yang terus-menerus mengisi gap yang sama juga bukan tanda bahwa dia hebat.

Bisa jadi tanda bahwa organisasinya gak pernah benar-benar memperbaiki problem tersebut.

Makanya menurut gw gak ada satu template “PM yang bagus”

Ini juga mengubah cara gw melihat hiring Product Manager.

Kadang kita terlalu sibuk mencari kandidat yang kelihatan seperti “PM ideal”.

Jago discovery.

Data-driven.

Strategic thinker.

Great communicator.

Technical enough.

Business savvy.

User obsessed.

Leadership.

Stakeholder management.

Daftarnya bisa panjang banget sampai akhirnya kita sebenarnya sedang mencari orang yang bagus di hampir semua hal.

Masalahnya, PM gak bekerja di vacuum.

Seseorang bisa jadi PM yang sangat bagus di satu organisasi dan biasa aja di organisasi lain.

PM yang tumbuh di company tech-heavy mungkin sangat nyaman kerja dengan engineering team yang mature dan bisa fokus ke discovery, strategy, dan business problem.

Pindahkan dia ke organisasi yang technical structure-nya berantakan dan membutuhkan PM yang mau bongkar API integration sampai level payload, belum tentu dia enjoy atau bahkan efektif.

Sebaliknya, PM yang sangat technical dan kuat mengurai system complexity belum tentu menjadi kandidat terbaik untuk role yang sebenarnya membutuhkan market development, commercial thinking, dan partnership jauh lebih banyak.

Bukan berarti salah satu lebih bagus.

Gap yang perlu mereka isi berbeda.

Makanya kalau gw berada di posisi hiring PM, pertanyaan pertama yang menurut gw harus dijawab bahkan sebelum interview kandidat adalah:

“Apa yang kurang dari organisasi kita sekarang?”

Bukan:

“Seperti apa Product Manager yang bagus?”

Apa problem terbesar team saat ini?

Kurang business understanding?

Kurang technical translation?

Discovery lemah?

Execution berantakan?

Stakeholder alignment?

Analytics?

UX?

Strategy?

Domain knowledge?

Baru cari orang yang shape-nya bisa mengisi gap tersebut.

Hiring PM tanpa ngerti kondisi organisasi itu kayak nyari dokter dengan pertanyaan:

“Dokter terbaik itu yang kayak gimana?”

Ya tergantung sakitnya apa.

Lo gak butuh dokter jantung kalau problem-nya tulang.

Sama kayak PM.

Kandidat yang bagus bukan yang paling banyak centang checklist-nya.

Kandidat yang bagus adalah yang paling cocok dengan problem organisasi yang memang perlu diberesin sekarang.

Terus kalau kita yang jadi PM, harus bagaimana?

Ini bagian yang mungkin agak gak enak.

Karena organisasi gak akan selalu menyesuaikan dirinya dengan job description ideal yang kita pelajari.

Jadi pilihannya kurang lebih dua:

tetap idealis dan terus kesal karena dunia gak bekerja seperti framework,

atau adapt.

Gw lebih memilih yang kedua.

The company doesn’t care about our ego.

Kalau environment berubah, kita juga harus punya kemampuan untuk berubah.

Dan menurut gw ada dua modal yang paling penting buat PM:

curiosity dan kemampuan belajar cepat.

Curiosity bikin kita mau masuk ke hal yang belum kita ngerti.

Tapi curiosity doang gak cukup kalau setiap kali ketemu domain baru kita butuh waktu berbulan-bulan buat ngerti basic-nya.

Company bukan universitas.

Lo gak punya satu semester buat belajar struktur API.

Gak ada mata kuliah dua SKS buat ngerti UX mental model.

Gak ada dosen yang kasih silabus dari basic sampai advanced sebelum lo diminta ikut diskusi.

Problem-nya sudah ada sekarang.

Meeting-nya besok.

Decision-nya mungkin harus keluar minggu ini.

Jadi yang dibutuhkan bukan selalu deep expertise.

Yang dibutuhkan adalah belajar secukupnya, secepatnya, untuk bisa ikut solve problem dengan benar.

Kalau ada issue API, lo gak harus berubah jadi backend engineer.

Tapi lo harus bisa ngerti cukup tentang endpoint, payload, response, dependency, dan data flow supaya gak cuma duduk diam waktu technical discussion.

Kalau ada issue UX, lo gak perlu tiba-tiba jadi product designer.

Tapi lo harus ngerti cukup tentang user behavior, hierarchy, affordance, mental model, atau interaction pattern supaya bisa diskusi dengan designer tanpa cuma bilang:

“menurut gw lebih bagus yang ini.”

Kalau ada issue bisnis, lo gak harus jadi finance atau commercial lead.

Tapi lo harus ngerti cukup tentang margin, conversion, revenue, inventory, atau unit economics supaya keputusan product-nya gak hidup di vacuum.

Belajar cepat bukan berarti asal ngerti permukaan.

Lebih ke tahu:

apa yang perlu dipahami,

mana yang relevan buat problem sekarang,

siapa yang perlu ditanya,

dan kapan pengetahuan lo sudah cukup untuk ikut bikin keputusan yang proper.

Karena kalau setiap kali masuk domain baru response kita cuma:

“wah gw gak ngerti nih,”

dan berhenti di situ,

ya wassalam.

Role ini memang bukan dibuat untuk orang yang nyaman cuma hidup di satu kotak.

“Gw gak technical” bukan personality trait

Salah satu hal yang agak mengganggu gw adalah ketika kekurangan pengetahuan dijadikan identitas permanen.

“Gw kan PM non-technical.”

“Gw gak ngerti UX.”

“Gw orangnya gak terlalu data.”

“Gw gak ngerti business.”

Okay.

Sekarang belum ngerti.

Terus?

Kalau pekerjaan lo terus bersinggungan dengan system dan lo sudah tiga tahun memilih untuk tetap gak ngerti cara system tersebut bekerja, menurut gw problem-nya bukan background pendidikan lagi.

Sama seperti gw yang background-nya engineering.

Itu gak otomatis bikin gw ngerti business.

Gw harus belajar.

Gw harus ngerti conversion.

Margin.

Revenue.

Inventory.

Marketing.

Customer behavior.

Dan segala hal yang sebelumnya gak pernah diajarin di Telecommunications Engineering.

Background menentukan starting point.

Menurut gw dia gak seharusnya menentukan boundary.

PM gak perlu menjadi orang paling technical di ruangan.

Gak perlu menjadi designer terbaik.

Gak perlu menjadi orang finance.

Tapi mengatakan “itu bukan area gw” setiap kali ketemu sesuatu yang unfamiliar rasanya bertentangan dengan nature pekerjaan ini sendiri.

Karena kalau definisi kerja kita adalah mengisi gap, kita gak bisa terlalu pilih-pilih gap berdasarkan hal yang sudah nyaman kita kerjakan.

Mungkin “jack of all trades” memang bukan insult

Dulu gw menemukan Product Management karena membaca seseorang menggambarkan dirinya kurang lebih sebagai jack of all trades, master of none.

Bertahun-tahun kemudian, gw malah semakin merasa itu cukup akurat.

Bukan karena PM harus tahu semuanya.

Impossible.

Tapi karena pekerjaan ini memberi reward ke orang yang genuinely penasaran terhadap banyak hal dan cukup cepat belajar ketika problem-nya pindah domain.

Hari ini gw bisa bahas payload API apa yang perlu dipassing waktu user add to cart.

Besok gw bisa mikirin kenapa conversion sepatu brand tertentu tiba-tiba turun dalam satu bulan terakhir.

Lusa gw bisa debat soal UX mental model dan kenapa sebuah button mungkin lebih masuk akal warna merah daripada hijau.

Minggu depannya bisa pindah lagi ke inventory, loyalty, payment, search ranking, warehouse operation, atau stakeholder issue yang sebelumnya bahkan gak ada di radar.

Buat sebagian orang mungkin exhausting.

Buat gw justru itu bagian yang fascinating.

Gw gak pernah benar-benar tahu problem seperti apa yang akan muncul berikutnya.

Dan setelah sekian tahun, gw semakin gak peduli apakah problem itu textbook-nya “kerjaan PM” atau bukan.

Pertanyaan gw sekarang lebih sederhana:

Ada gap apa di sini?

Apakah gap itu menghambat product?

Dan apakah gw bisa membantu menutupnya?

Kalau iya, ya masuk.

Pelajari yang belum ngerti.

Tanya orang yang lebih tahu.

Kerjain yang memang perlu dikerjakan.

Dan kalau ternyata gap yang sama terus kita isi berulang kali, jangan merasa heroik juga.

Maybe it’s time to fix the organization instead.

Menurut gw Product Management memang hidup di antara ketidaksempurnaan seperti itu.

Bukan CEO of the Product.

Bukan sekadar titik tengah Business, Technology, dan UX.

Mungkin kita cuma orang yang cukup curious untuk melihat ada sesuatu yang belum nyambung di antara semuanya, lalu bilang:

“Okay. Yang ini belum ada yang pegang. Gimana kalau kita beresin?”