Produk Bertambah, Product Manager Justru Cenderung Berkurang
(kitemaker.co)- Perdebatan tentang berapa banyak PM yang perlu ada di tim produk makin besar setelah restrukturisasi organisasi manajemen produk Airbnb dan contoh startup yang tumbuh tanpa PM
- Semakin banyak PM, semakin mungkin muncul struktur kerja yang menghabiskan waktu untuk manajemen proyek dan pembaruan roadmap alih-alih hasil bisnis produk
- Pada tim dengan desainer dan engineer berpengalaman, pekerjaan PM tidak selalu harus menjadi peran penuh waktu, dan model satu PM per tim juga perlu ditinjau ulang sesuai situasi
- Perekrutan PM pertama biasanya dipertimbangkan saat pendiri mulai sulit terlibat dalam semua keputusan produk utama, umumnya di skala 50–100 orang dan 3–5 tim produk
- Menambah jumlah PM saja tidak otomatis membuat organisasi menjadi lebih berpusat pada produk, dan justru bisa melemahkan rasa tanggung jawab terhadap produk yang seharusnya dimiliki desainer dan engineer
Struktur yang Mengurangi PM dan Memperluas Tanggung Jawab Produk
- Diskusi tentang kebutuhan jumlah PM menjadi lebih aktif setelah tulisan-tulisan yang membahas restrukturisasi organisasi manajemen produk Airbnb dan contoh startup yang bertumbuh bahkan tanpa PM
- Di banyak perusahaan, PM sering menghabiskan hari mereka untuk tugas seperti manajemen proyek dan pembaruan roadmap alih-alih mengoptimalkan produk agar selaras dengan bisnis
- Secara umum, jumlah PM seharusnya lebih sedikit daripada jumlah tim produk, dan struktur yang menempatkan satu PM di setiap tim perlu ditinjau kembali berdasarkan kondisi produk dan tim
- Jika pekerjaan produk sangat banyak dan tim masih junior, satu tim mungkin memang membutuhkan PM khusus
- Pada tim dengan engineer dan desainer berpengalaman, peran PM mungkin tidak perlu penuh waktu, atau bahkan sebaiknya tidak demikian
- Waktu yang tepat bagi startup untuk merekrut PM pertama adalah ketika pendiri mulai kesulitan terlibat dalam semua keputusan produk yang penting
- Biasanya patokannya adalah saat organisasi berukuran 50–100 orang dan memiliki 3–5 tim produk
- Strategi produk secara keseluruhan harus sudah jelas, dan PM perlu berpartisipasi dalam arahan serta pengambilan keputusan di tingkat yang lebih rendah berdasarkan strategi tersebut
- Untuk PM pertama, PM senior lebih tepat dibanding PM junior atau CPO
- Kandidat tersebut mungkin bisa mengambil peran CPO seiring pertumbuhan organisasi, tetapi pada praktiknya pendiri tetap perlu menjalankan peran sebagai penanggung jawab produk
Cara Praktis Membangun Tim yang Berpusat pada Produk
- Tanggung jawab produk tidak boleh terpusat pada satu PM saja; desain dan engineering juga harus memahami pengguna dan konteks produk secara langsung
- Desainer dan engineer harus aktif berpartisipasi dalam membentuk produk dan memimpin diskusi produk yang detail
- PM tidak seharusnya menjadi satu-satunya penulis UX, wireframe, pelacakan progres, pengelolaan standup, atau PRD/spesifikasi
- Fokus PM adalah mengekspresikan visi produk, memilih masalah yang tepat, menjaga arah produk, dan menyelaraskannya dengan kebutuhan bisnis
- Panduan Michael Seibel untuk product development terhubung dengan contoh penerapan pendekatan ini di Social Cam
- Tim harus aktif berbagi konteks dan dasar pertimbangan
- Desain dan engineering juga harus bisa mengakses umpan balik pengguna
- Pemecahan masalah seharusnya bukan berpusat pada PM, melainkan kolaborasi antara produk, desain, dan engineering
- Praktik untuk membangun tim yang berorientasi produk bisa diringkas menjadi empat hal
- Memulai bersama: sebelum menulis tiket atau spesifikasi, sebelum menentukan solusi, desain·engineering·produk/pendiri berdiskusi bersama untuk menyelaraskan cara kerja dan rencana
- Mengekspos semua orang ke pengguna: ikut langsung dalam riset pengguna dan uji kegunaan, atau melihat pengguna memakai produk lewat streaming video dan alat seperti Lookback
- Berhati-hati dalam cara mengelola tim: jika kinerja diukur dengan jumlah tiket yang ditutup atau story point, tim akan bergerak untuk menyelesaikan tiket, bukan membangun produk yang baik
- Tidak memakai alat PM: jika umpan balik pengguna, insight, data, spesifikasi, dan roadmap terkunci di alat PM yang terpisah, seluruh tim akan sulit mengakses konteks produk
- Pengembangan produk pada dasarnya sulit diprediksi, dan yang lebih penting daripada sekadar merilis sesuatu adalah merilis hal yang tepat yang benar-benar berdampak pada bisnis
- Di perusahaan besar yang sangat berpusat pada produk, PM memang sangat penting, tetapi jumlah PM yang dibutuhkan mudah dibesar-besarkan, dan bertambahnya PM tidak otomatis meningkatkan fokus pada produk
1 komentar
Komentar Hacker News
Sebagai engineering manager atau kepala organisasi fungsi, saya sudah cukup lama bekerja dengan product manager, dan di perusahaan teknologi menengah saya juga pernah menjalankan peran PM sementara untuk produk internal
Menurut saya, manajemen produk termasuk salah satu area paling penting dari apa yang dilakukan perusahaan. Namun pekerjaannya memang sangat sulit, dan semakin kurang kompeten seorang PM, semakin mudah ia menjauh dari inti pekerjaan itu lalu mengalir ke micromanagement atas nama “memimpin” tim engineering atau politik internal
Di organisasi yang memisahkan organisasi engineering dan produk ke dalam rantai komando yang berbeda, masalah ini sulit ditangani, dan bahkan jika masalahnya dieskalasikan ke atas, bandwidth di sana secara alami sangat terbatas. Dari sudut pandang EM, PM seperti ini sering membuat engineer terbaik tersiksa, dan pada akhirnya mereka pergi
Saat ini saya melihat cara terbaik adalah menempatkan PM bergaya mini-CEO di tiap tim, dan jika kemampuan teknisnya tidak cukup, memasangkannya dengan mini-CTO. Ruang bagi politik menjadi jauh lebih kecil dan ruang untuk kerja tim jauh lebih besar
Tim-tim paling sukses yang pernah saya ikuti tidak memiliki peran produk khusus, dan semua keputusan dibuat oleh developer
Sekarang saya pikir yang terbaik adalah menyingkirkan orang non-teknis, bahkan orang yang setengah-setengah teknis, dari jalan developer agar developer bisa membangun dengan tenang
Yang saya lihat adalah orang-orang mengajukan pilihan mereka dan berusaha mendapatkan dukungan. Saya belum pernah melihat politik yang dikeluhkan orang-orang itu. Mungkin saya hanya beruntung
Apakah politik berarti orang yang secara teknis salah tetapi mengemukakan argumen dengan lebih meyakinkan? Apa itu “politik”? Atau apakah jabatan saya belum cukup tinggi, meski sudah senior principal
Tulisan ini dan banyak orang yang mencoba menganalisis topik ini melewatkan satu faktor kunci: insentif
Banyak developer lebih bersemangat pada teknologi itu sendiri, yaitu coding, memecahkan masalah teknis yang kompleks, dan membuat solusi yang efisien. Imbalan formal seperti promosi, bonus, dan pengakuan juga sering dikaitkan dengan pencapaian teknis
Jika seorang developer menghabiskan 40 jam untuk riset pelanggan, ia mungkin tidak mendapat pengakuan atau imbalan resmi sebesar pencapaian teknis seperti mengembangkan solusi autentikasi baru yang membantu seluruh tim
Mengubah dinamika ini tidak cukup hanya dengan menganjurkan developer agar meluangkan lebih banyak waktu untuk manajemen produk. Diperlukan perubahan sistemik pada apa yang dihargai organisasi dan bagaimana hal itu diberi imbalan
Mengubah struktur insentif dari berpusat pada teknologi menjadi berpusat pada pengguna akan berdampak besar pada peran manajer tingkat menengah dan atas. Perubahan seperti itu mengguncang dasar peran dan tanggung jawab mereka, dan bisa berujung pada hilangnya kontrol dan pengaruh
Karena itu, perubahan semacam ini kemungkinan akan menghadapi resistensi yang halus tetapi kuat dari manajer tingkat menengah dan atas. Mereka sering memiliki kekuatan politik yang cukup besar dan kepentingan yang sudah mapan di dalam organisasi
Semua pekerjaan perajin dipelajari saat bersentuhan langsung dengan kenyataan. Seorang sutradara film bisa menonton filmnya seribu kali di ruang editing, tetapi satu kali menontonnya bersama penonton sungguhan untuk pertama kalinya mengajarkan lebih banyak daripada seribu jam itu
Seorang tukang kayu bisa puas membuat furnitur sepanjang minggu, tetapi momen sebenarnya datang ketika furnitur itu ditempatkan di kamar pelanggan. Software juga sama
Agar software engineer peduli pada pengguna, mereka harus menerima feedback langsung tentang apa yang berjalan baik dan apa yang buruk, dan kalau bisa melihatnya dengan mata sendiri
Software engineer yang layak punya tingkat kebanggaan tertentu dalam melakukan pekerjaan dengan baik. Jika kebanggaan itu hanya terhubung dengan kode, riwayat commit, dan konsep abstrak lain, tanpa pernah bersentuhan dengan seberapa baik hasilnya dipakai untuk pengguna nyata, bagaimana mereka bisa mulai peduli sejak awal
Hampir tidak ada hubungannya dengan tulisan ini, tetapi tren sekarang memakai gambar AI sebagai gambar utama posting blog benar-benar membuat saya kesal
Jika saat menulis tidak terbayang gambar utama yang jelas, saya berharap jangan membuang bandwidth saya untuk mengunduh mimpi kosong komputer
Saya cenderung mendukung gambar AI karena itu alat yang sangat bernilai. Namun jika gambar AI digunakan sebagai satu-satunya gambar di halaman, harus ada alasan yang benar-benar layak untuk itu, bukan sekadar pengisi ruang
Apalagi jika bahkan jumlah jari setiap orang dalam gambar yang dihasilkan tidak dikurasi dengan benar
Tujuan gambar adalah menyampaikan sebuah rasa. Membuat konsep abstrak dalam tulisan menjadi sesuatu yang sedikit lebih bisa disentuh
Dulu saya mencari gambar di internet yang sesuai dengan tujuan itu. Sekarang saya bisa membuatnya sendiri dengan DALL-E, dan biasanya jauh lebih baik
Gambar ini harus melengkapi tulisan. Sama seperti teks dalam tulisan berusaha menyampaikan informasi, rasa, dan konsep, gambar juga harus melakukan sebagian dari itu
Tidak ada yang ingin melihat gambar bergaya uncanny valley tentang orang-orang yang memasukkan semua kelompok ras utama, berdiri melingkar dan saling tersenyum aneh
Tren gambar korporat yang ganjil dan tanpa jiwa seperti ini sudah dimulai bahkan sebelum generasi AI meledak popularitasnya
Mungkin karena semacam kepercayaan terkait optimasi mesin pencari
Pada saat yang sama mereka hanya harus terlihat menarik
Tapi ada sisi yang agak lucu di sini. Template blog meminta area gambar, jadi orang tanpa berpikir mengisinya dengan sesuatu. Jika itu terlalu sulit, mereka mencari foto stok yang hambar, dan jika itu pun sulit, mereka sengaja membuat foto stok hambar
Sampah AI yang tanpa inspirasi dan tanpa selera sepertinya akan segera menutupi semuanya
Sebagian besar masalah PM terletak pada tidak mau turun langsung ke lapangan. PM yang baik harus terus menjembatani kesenjangan antara engineering dan pengguna
Feedback loop ini harus diulang
Namun kebanyakan orang merasa mereka bisa bekerja hanya di dunia dokumen, memproduksi dokumen roadmap, lalu berusaha menjaga alignment stakeholder dengan check-in dan omelan tanpa akhir. Pada akhirnya, yang mereka lakukan sebenarnya adalah pekerjaan “project manager”
Pengumpulan requirement, menangani pengguna yang marah karena bug, rapat status mingguan, sampai menyampaikan kabar buruk terkait prioritas—semuanya dikirim ke senior developer atau tech lead. Ia juga melewatkan sebagian besar ritual Agile dengan alasan orang-orang sibuk. Ia tidak pernah menulis atau memperbaiki tiket JIRA, dan mengatakan itu urusan organisasi teknis untuk mengelolanya. Dua tim teknis lain juga diperlakukan sama oleh PM itu
Para tech lead dan senior developer sudah tahu sejak minggu pertama bahwa PM itu buruk, tetapi ia bertahan lebih lama daripada kami semua dan baru keluar 4 tahun kemudian karena pengurangan tenaga kerja
Manajemen yang terjebak dalam pemujaan Agile mudah terpikat oleh orang-orang seperti ini, dan bisa membuat organisasi melenceng selama bertahun-tahun. Secara teori, stakeholder PM adalah pengguna, tetapi dalam praktiknya pekerjaan itu menjadi mengelus ego para eksekutif senior yang mempekerjakannya
Bisa terbentuk closed loop yang memperkuat diri sendiri antara eksekutif senior, konsultan Agile, dan PM
Dalam kedua kasus itu, produknya tidak kompetitif, dan biasanya kemungkinan besar akan tetap ada sampai akhirnya dihentikan. Meski begitu, perusahaan tetap menempatkan PM dan PO, membentuk sesuatu yang mirip SCRUM, dan bertindak seolah-olah sedang membuat produk revolusioner. Termasuk pekerjaan mendesak dan tekanan hasil
Di lingkungan seperti ini, PM dan PO sering kali tidak terlalu peduli pada produk yang baik atau berguna, dan lebih sibuk berpolitik untuk menaiki tangga promosi internal
Mereka mengarahkan proyek ke arah yang membuat diri mereka terlihat baik di mata manajemen atau pelanggan, meski hasilnya adalah produk terfragmentasi yang dari sisi fitur dan perbaikan tampak seperti random walk
Aku tidak cukup tua untuk tahu bagaimana orang membuat produk pada era 60-an, 70-an, dan 80-an, tetapi sepertinya saat itu tidak ada SCRUM/PM/PO. Narasi pesimistis bahwa produktivitas sangat melambat dibandingkan dekade-dekade lalu dan bahwa hari ini kita umumnya bergantung pada hal-hal yang dibuat di masa lalu cukup sesuai dengan persepsiku
Belakangan ini aku juga membimbing PM lain. Ada roadmap yang dibagikan luas, tetapi sangat banyak dokumen dan spreadsheet yang dibuat lalu tidak pernah dilihat lagi oleh siapa pun selain aku. Rasanya dibuat hanya untuk menunjukkan bahwa ada pekerjaan yang sedang dilakukan, dan aku berusaha mematahkan kebiasaan itu
Alasanku sangat mendukung technical product management adalah karena jika masalahnya disederhanakan, menurutku sebagian PM terjebak di tingkat abstraksi yang terlalu tinggi. Karena tidak bisa membicarakan detail teknis dengan tim setiap hari, mereka akhirnya berada di area abu-abu yang aneh antara project management dan product management
Itu sendiri tidak masalah, tetapi jika ada sindrom HIPPO yang ingin mengambil keputusan produk, sebagian besar waktu akan habis untuk melindungi diri dari belakang dan mengelola atasan
PM sering dihajar, kadang memang pantas, tetapi pada akhirnya mereka sering harus berpolitik di internal perusahaan supaya pekerjaan bisa berjalan
PM yang hebat tidak hanya membuat visi atau rencana, tetapi juga memimpin eksekusi dan iterasi. Rencana hanyalah 20% dari keseluruhan
Product manager terbaik yang pernah bekerja denganku adalah orang yang memang sangat hebat; ia memahami kompleksitas implementasi, bahkan mungkin bisa melakukannya sendiri jika perlu, sekaligus memahami kebutuhan bisnis
Ia bukan engineering manager, tetapi tetap menambah nilai bagi perusahaan
Sayangnya, sebagian besar product manager hanyalah orang yang duduk di posisi itu. Mereka adalah gatekeeper yang mengambil kredit ataupun tanggung jawab, dan sering kali hampir tidak punya kepentingan pribadi yang dipertaruhkan
Secara umum, menurutku jika ada organisasi product management tersendiri, berarti kalian melakukannya dengan keliru
Produk terbaik dan paling sukses yang pernah kuikuti semuanya dimiliki secara produk oleh para implementor nyata. Orang-orang seperti engineer, designer, dan tim customer success
Sebagai engineer, aku suka masuk giliran support, karena itu menutup kesenjangan abstraksi antara pekerjaanku dan orang-orang nyata yang menggunakannya setiap detik
Pernah juga, sangat jarang, aku bekerja dengan PM yang benar-benar menambah nilai bersih; dalam semua kasus itu, mereka adalah orang-orang yang juga bisa saja menjadi engineer yang layak
Alasan utamanya adalah jika PM, atau orang dalam tim yang memegang peran itu, melapor ke struktur manajemen engineering yang sama, semua hal pada akhirnya condong ke kebutuhan engineering
Pekerjaan fitur yang benar-benar penting dan kemungkinan besar akan mendorong bisnis maju pun akhirnya tersingkir dari prioritas karena technical debt atau pekerjaan infrastruktur selalu, dengan satu atau lain cara, dianggap menghambat orang. Kadang itu memang bisa menjadi pilihan yang benar, tetapi untuk mengambil keputusan seperti itu dibutuhkan ketegangan antara dua organisasi yang punya posisi setara. Jika menjadi bagian dari engineering, hal itu sulit terjadi
Tentu saja, kenyataan menyedihkan di industri kita adalah organisasi PM terpisah sering mendapat kewenangan lebih besar daripada organisasi engineering karena dianggap memiliki “apa yang baik untuk bisnis”. Jika ditambah PM yang tahu cara mengikuti proses atau framework tetapi tidak benar-benar memahami produk atau penggunanya sendiri, itu berubah menjadi mimpi buruk
Saya memikirkannya sebagai rasio
Berapa rasio antara engineer frontend dan engineer backend? Rasio antara engineering manager dan kontributor individu? Rasio antara penulis dokumentasi teknis dan total engineer? Rasio antara product manager dan total engineer?
Lalu rasio ini disetel secara cermat agar dampaknya maksimal, sementara intervensi dan micromanagement diminimalkan
Angka riil rasio ini tentu berbeda di tiap organisasi, tetapi kalau mulai terasa ada intervensi, atau “bagaimana” tidak cukup muncul dari para engineer sendiri, rasionya harus diubah
Jumlah engineer per people manager atau product manager perlu ditambah agar mereka tidak bisa ikut campur seperti ini, dipaksa memprioritaskan hal-hal yang perlu mereka tangani, mundur dari ranah mikro, dan mengembalikan otonomi soal cara kepada engineer
Hal yang sama juga berlaku untuk QA, engineer junior, engineer senior, arsitek, staf HR, wakil presiden, dan tenaga sales
Saya sudah lebih dari 20 tahun berkecimpung di product management, dan setuju dengan sebagian besar hal yang dikatakan di sini. Rasio itu penting
CPO mudah membangun kerajaan dengan pasukan PM di bawahnya. Organisasi menjadi tempat para PM memiliki potongan-potongan kecil dari pengalaman pelanggan, seperti satu halaman, lalu mengoptimalkan click-through rate tombol, tetapi tidak berkontribusi secara bermakna pada strategi atau visi produk
Sulit menjadi product manager kalau tidak memiliki produk
PM harus jauh lebih fokus pada tujuan bisnis dibanding kebanyakan PM saat ini. Menyelesaikan masalah pengguna itu perlu, tetapi tidak cukup. Penyelesaian masalah itu juga harus berujung pada nilai bagi perusahaan
Agar ini memungkinkan, partner engineering dan UX yang memiliki product sense kuat adalah keharusan
Lebih buruk lagi, developer yang “mudah diganti” berasal dari perusahaan outsourcing. Sekarang development harus diisolasi dari pelanggan dengan lebih banyak lapisan manajemen
Cara yang bagus untuk menaikkan GDP
Misalnya jika yang ditangani adalah ERP, Oracle Fusion Apps, WorkDay, atau SAP, satu PM tidak mungkin memiliki seluruh produk. Sebagai gantinya, ia memegang beberapa fitur, dan tiap fitur itu sendiri kompleks; karena sifat ERP, biasanya juga mencakup integrasi dengan berbagai produk lain
Meski begitu, saya setuju dengan arah besarnya bahwa PM harus memiliki sesuatu yang bermakna
Sebagai developer sekaligus development manager, product manager terbaik yang pernah bekerja dengan saya hampir tidak ikut campur soal “bagaimana”
Tentu mereka bisa membuat tiket level epic di backlog, tetapi di tingkat di bawah itu mereka percaya bahwa Anda dan para penanggung jawab proyek bisa menyelesaikan pekerjaan
Masalahnya, organisasi harus mendukung hal itu. Di kebanyakan perusahaan, pekerjaan yang paling banyak mendapat perhatian bukanlah yang berorientasi visi atau pertumbuhan, melainkan yang paling berisik
Dan pekerjaan seperti itu sering kali bertabrakan langsung dengan arah yang diinginkan product owner atau manager
PM yang tidak memahami “bagaimana”, yaitu PM yang tidak tahu bagaimana produknya bekerja, adalah yang terburuk
PM terbaik yang pernah bekerja dengan saya punya latar belakang teknis
Ketika orang mulai menginjak wilayah orang lain, hasilnya selalu bencana. Berlaku dua arah. Engineer terlalu banyak berpikir dari sudut “bagaimana?”, sehingga lemah dalam “mengapa?” dan “apa?”, dan product manager juga harus mundur dari “bagaimana?” kecuali jika itu untuk memperjelas “apa?” atau “mengapa?”
Harus ada keseimbangan. PM/PO juga perlu punya pemahaman dasar. Jangan sampai orang yang bahkan nyaris tidak bisa memakai komputer
PM yang baik pun bisa cukup terikat kalau di sekelilingnya ada terlalu banyak PM biasa-biasa saja
Setelah bekerja dengan beberapa perusahaan Fortune 500, saya melihat banyak budaya yang rusak
Di tempat seperti itu, PM menyelesaikan sebagian besar masalah dengan satu-satunya alat yang mereka punya: rapat. Insentif promosi dibuat sedemikian rupa sehingga semakin besar rapatnya, semakin penting orang itu terlihat
Saya pernah mengikuti ratusan jam rapat tim lintas fungsi; yang benar-benar bekerja hanya 1–2 orang, biasanya PM berbicara sepanjang waktu, sementara 10–20 orang dalam kondisi mute lalu di akhir hanya memberi persetujuan seolah membuktikan bahwa mereka ada
Akibatnya, tim engineer kehilangan motivasi dan tidak punya waktu untuk pekerjaan teknis yang sebenarnya, sementara di tempat itu juga mereka diminta memberikan estimasi atau komitmen tanpa sempat menyelidiki atau memahami kode
Saya juga pernah melihat PM menolak desain teknis karena tidak suka angka atau “point”-nya, lalu para engineer harus memformat ulang ide yang sama menjadi “ticket” lain demi memuaskan estetika PM yang tidak jelas
Seluruh proyek tertunda dan melenceng karena kurangnya pemahaman serta ritual pamer status yang tidak bermakna
Sebaliknya, saya juga pernah bekerja dengan PM yang luar biasa; orang-orang seperti itu melindungi tim dari omong kosong semacam ini dan membuat mereka fokus pada tujuan yang benar. Orang seperti itu sangat berharga, sementara yang sebelumnya sama merusaknya
Terlepas dari jumlah PM, ini adalah cerita tentang tipe PM yang ingin saya ajak bekerja
Saya pernah bekerja di empat perusahaan di industri ini, dengan pengalaman mulai dari startup berisi kurang dari 40 orang hingga JP Morgan Chase
Saya menolak anggapan bahwa orang “teknis” lebih pintar daripada orang “nonteknis”. Faktanya, sebagai engineer, saya sering terlalu tenggelam dalam detail hingga melewatkan gambaran besar, dan sering kali saya membutuhkan PM untuk menarik saya keluar dari sana
Namun, berdasarkan pengalaman saya, sebagai engineer, PM yang paling mudah diajak bekerja sama adalah orang yang pernah punya sedikit saja paparan nyata terhadap kode
Tidak perlu hebat. Cukup pernah membuat situs web dengan HTML dan CSS dulu, pernah menulis kueri SQL ad hoc, atau mengikuti kelas Python saat program magister
Yang penting ada sesuatu yang membuat PM memahami bahwa menulis kode bukanlah ilmu pasti, tetapi juga bukan sihir sepenuhnya
PM seperti ini akan membela para engineer yang bekerja bersama mereka, atau setidaknya berusaha menyeimbangkan kebutuhan bisnis dengan realitas engineering
Orang yang menjadi PM tanpa paparan teknis sama sekali cenderung lebih “berorientasi bisnis”, dan pada titik tertentu bisnis mungkin memang membutuhkan hal itu, tetapi tidak selalu demikian. Sebagai engineer, saya ingin bekerja dengan orang yang juga lebih memahami sudut pandang saya
Sama sekali tidak tersinggung kok :p