Product Owner vs Product Manager: Perbedaan Utama

Product Owner adalah akuntabilitas yang didefinisikan Scrum Guide; product manager adalah jabatan tanpa standar pemilik, sehingga artinya berbeda di hampir setiap perusahaan yang memakainya. Asimetri itu, bukan sekadar daftar siapa mengerjakan apa, adalah alasan sebenarnya mengapa "product owner vs product manager" terus membingungkan orang-orang cerdas.

Kebanyakan artikel tentang topik ini membuat tabel perbandingan simetris, seolah kedua peran berada pada posisi setara dan hanya membagi pekerjaan secara berbeda. Kenyataannya tidak. Yang satu berasal dari dokumen framework singkat yang konten intinya tidak berubah sejak 2020. Yang lain berasal dari apa pun yang ditulis seorang VP of Product dalam lowongan kerja kuartal lalu. Begitu Anda memisahkan kedua fakta itu, sisa kebingungan (siapa memiliki roadmap, siapa berbicara dengan pelanggan, siapa melapor ke mana, apakah Anda butuh satu peran atau keduanya) jauh lebih mudah dipilah.

Fakta Utama

• Scrum Guide 2020 menyatakan Product Owner "bertanggung jawab memaksimalkan nilai produk yang dihasilkan dari pekerjaan Scrum Team," dan menambahkan bahwa Scrum Team "biasanya 10 orang atau kurang."
• "Product Owner" berasal dari satu dokumen, yaitu Scrum Guide. "Product Manager" tidak berasal dari badan standar mana pun; setiap pemberi kerja mendefinisikannya sendiri.
• Pada skala enterprise, Scaled Agile Framework memisahkan keduanya dengan sengaja: Product Management memiliki backlog dan strategi level program, dan Product Owner memiliki backlog satu tim di bawahnya.
• Event PI Planning SAFe, di mana Product Management dan Product Owner harus selaras secara langsung, berlangsung setiap 8 hingga 12 minggu sebagai event dua hari untuk seluruh Agile Release Train.

Apa yang sebenarnya didefinisikan Scrum Guide sebagai Product Owner

Mulai dari sini, karena inilah satu-satunya bagian perbandingan ini yang tidak bisa diperdebatkan. Scrum Guide, yang terakhir direvisi pada November 2020, sengaja dibuat singkat dan menyatakan dengan jelas: "Product Owner bertanggung jawab memaksimalkan nilai produk yang dihasilkan dari pekerjaan Scrum Team." Itulah seluruh pekerjaannya dalam satu kalimat. Semua hal lain yang dikatakan Guide tentang peran ini menjelaskan bagaimana akuntabilitas itu berjalan sehari-hari.

Guide menegaskan bahwa Product Owner adalah satu orang, bukan kelompok: "Product Owner adalah satu orang, bukan komite." Guide melanjutkan: "Product Owner dapat mewakili kebutuhan banyak pemangku kepentingan dalam Product Backlog. Mereka yang ingin mengubah Product Backlog dapat melakukannya dengan mencoba meyakinkan Product Owner." Kalimat itu lebih penting daripada kelihatannya. Artinya Product Owner bukan saluran pass-through bagi siapa pun yang paling lantang berargumen dalam rapat. Pemangku kepentingan tidak bisa mengedit product backlog secara langsung. Mereka mengajukan argumen kepada satu orang yang akuntabel, dan orang itulah yang memutuskan.

Tugas spesifik Product Owner, menurut Guide, mencakup mengembangkan dan mengomunikasikan Product Goal, membuat dan mengomunikasikan item backlog, mengurutkan backlog, dan menjaga backlog tetap transparan dan dipahami semua orang di tim. Perhatikan apa yang tidak ada dalam daftar itu: perekrutan, kepemilikan anggaran, strategi pasar, penetapan harga, atau perencanaan go-to-market. Scrum Guide adalah framework tentang bagaimana tim pengembangan mengorganisasi pekerjaannya. Ia nyaris tidak berbicara tentang sisi bisnis dalam menjalankan produk, karena itu memang bukan tugasnya.

Itu juga sebabnya Product Owner berada di dalam Scrum Team yang sengaja dijaga kecil, "biasanya 10 orang atau kurang," menurut Guide, dan bekerja dalam sprint dengan durasi tetap. Peran ini hanya ada dalam konteks struktur itu. Singkirkan Scrum, dan "Product Owner" berhenti menjadi sesuatu yang terdefinisi. Ia menjadi jabatan yang dipinjam dari Scrum dan ditempelkan pada cara kerja lain, yang persis terjadi di banyak perusahaan.

Apa yang sebenarnya dilakukan product manager

Inilah bagian yang menjebak orang: tidak ada dokumen setara untuk "Product Manager." Tidak ada badan standar yang memiliki jabatan ini seperti Scrum Guide memiliki "Product Owner." Pekerjaan sebenarnya seorang product manager bergantung sepenuhnya pada perusahaan, industri, kematangan produk, dan kepada siapa orang itu melapor.

Meski begitu, beberapa tanggung jawab muncul di hampir setiap deskripsi pekerjaan product manager, apa pun perusahaannya: memahami pasar dan pelanggan, menetapkan strategi produk dan roadmap, memprioritaskan apa yang dibangun terhadap kapasitas engineering yang terbatas, dan bertanggung jawab atas apakah produk sukses secara komersial, bukan hanya apakah fitur dirilis sesuai jadwal. Marty Cagan dari Silicon Valley Product Group, salah satu suara yang paling banyak dibaca tentang perbedaan persis ini, berargumen bahwa pekerjaan produk yang kuat membutuhkan "pemahaman mendalam tentang pelanggan" dipadukan dengan "kemampuan menerapkan teknologi untuk memecahkan masalah pelanggan," dan bahwa memisahkan kedua rangkaian keterampilan itu ke orang berbeda biasanya melemahkan kedua belahnya.

Dalam praktik, hari seorang product manager lebih mirip rotasi antara panggilan pelanggan, riset kompetitif, percakapan penetapan harga, tinjauan roadmap bersama eksekutif, dan negosiasi ruang lingkup dengan lead engineering, ketimbang backlog grooming. Sementara Product Owner, menurut Scrum Guide, akuntabel atas backlog satu tim, product manager biasanya akuntabel atas hasil sebuah lini produk: adopsi, pendapatan, retensi, atau metrik apa pun yang diperhatikan bisnis. Matriks analisis pemangku kepentingan yang dibangun product manager cenderung menjangkau jauh di luar tim delivery, mencakup sales, legal, keuangan, dan eksekutif yang mendanai roadmap.

Karena tidak ada standar pemilik, deskripsi pekerjaan product manager sangat bervariasi cakupannya. Di startup lima orang, "product manager" bisa berarti melakukan riset pasar, menulis spesifikasi, menjalankan sprint planning, dan menjawab tiket dukungan, semuanya sekaligus. Di enterprise 2.000 orang, product manager mungkin memiliki satu area fitur, tidak pernah menyentuh backlog secara langsung, dan menghabiskan sebagian besar minggu dalam rapat penyelarasan pemangku kepentingan. Keduanya memakai jabatan yang sama. Pekerjaan mereka nyaris tidak beririsan.

Product owner vs product manager: berdampingan

Baca peran-peran ini melalui akuntabilitas, konteks kerja, dan otoritasnya sebelum membandingkan jabatannya.

Siapa memiliki artefak yang mana

Cara berguna untuk menembus kebingungan adalah berhenti membandingkan jabatan dan mulai membandingkan siapa yang sebenarnya memegang setiap artefak.

Jika organisasi Anda tidak bisa menjawab "siapa memiliki roadmap" dan "siapa memiliki sprint backlog" dengan dua nama berbeda, kemungkinan besar satu orang mengerjakan kedua pekerjaan itu dengan satu jabatan. Itu umum, dan tidak otomatis menjadi masalah. Ia menjadi masalah ketika tak ada yang menyadari hal itu sedang terjadi.

Empat pola organisasi yang akan benar-benar Anda temui

Perusahaan tidak mengimplementasikan "Product Owner" dan "Product Manager" sebagai peran buku teks yang bersih. Dalam praktik, Anda akan melihat salah satu dari empat pola, dan masing-masing punya mode kegagalan yang dapat diprediksi.

Pola 1: Satu orang memakai kedua topi

Setup paling umum di startup dan tim produk kecil: satu orang memegang jabatan "Product Manager" tetapi juga mengerjakan semua yang diberikan Scrum Guide kepada Product Owner, termasuk merapikan backlog, menghadiri sprint planning, dan ikut setiap sprint review.

Ini berjalan baik sampai titik tertentu: biasanya satu produk, satu atau dua Scrum Team, dan pasar yang tidak berubah cukup cepat untuk menuntut perhatian strategis penuh waktu. Ia runtuh ketika sisi strategis pekerjaan (riset pelanggan, roadmap, penetapan harga) dan sisi taktis (backlog refinement, menulis story, tradeoff level sprint) mulai bersaing memperebutkan jam yang sama di minggu yang sama. Orang itu entah mengabaikan tim, sehingga backlog menjadi basi dan sesi backlog refinement terlewat, atau mengabaikan pasar, sehingga roadmap menjadi basi sementara pesaing bergerak dan masukan pelanggan menumpuk tak terbaca.

Pola 2: Product Owner melapor ke Product Manager

Umum di perusahaan menengah yang menjalankan beberapa Scrum Team di bawah satu lini produk. Product Manager menetapkan strategi dan memiliki roadmap; satu atau lebih Product Owner masing-masing menjalankan backlog untuk tim tertentu, menerjemahkan roadmap menjadi pekerjaan seukuran sprint.

Ini pada dasarnya versi informal dari apa yang diformalkan SAFe pada skala besar, dibahas di bawah. Ia berjalan ketika serah terima antara strategi dan eksekusi benar-benar dua arah: Product Owner menyampaikan apa yang mereka pelajari dari eksekusi sprint kembali ke Product Manager, dan Product Manager tidak sekadar melempar roadmap melewati pagar. Ia runtuh ketika loop umpan balik itu hanya berjalan satu arah, dan Product Owner menjadi sekadar penerima perintah.

Pola 3: Product Owner adalah proxy berorientasi delivery tanpa mandat pasar

Inilah pola yang menjadi sasaran langsung kritik Cagan. Satu orang, sering memegang jabatan "Product Manager," memiliki semua kontak pelanggan dan pasar. Orang lain, "Product Owner," mengelola backlog dan berbicara dengan tim pengembangan, tetapi tidak pernah berbicara dengan pelanggan dan tidak punya suara dalam strategi. Product Owner itu ada untuk menjaga tim tetap terisi item backlog yang tersusun baik, titik.

Mode kegagalannya spesifik: orang yang membuat keputusan prioritisasi dari saat ke saat, yang benar-benar membentuk produk, tidak memiliki konteks pelanggan untuk membuatnya dengan baik. Cagan berargumen pemisahan semacam ini membagi pekerjaan yang harus tetap terintegrasi, karena keputusan backlog yang baik bergantung pada pemahaman pelanggan yang sama dengan yang dibutuhkan keputusan strategi yang baik. Tim yang menjalankan pola ini sering menyadari backlog secara teknis tetap sehat sementara produknya sendiri menjauh dari apa yang sebenarnya dibutuhkan pelanggan.

Pola 4: Ada Product Manager tanpa Product Owner sama sekali

Umum di perusahaan yang tidak menjalankan Scrum, entah memakai Kanban, model alur berkelanjutan, atau sesuatu yang ad hoc. Ada Product Manager. Tidak ada "Product Owner" karena tidak ada Scrum Team untuk menempelkan akuntabilitas itu.

Ini bukan celah yang perlu diperbaiki. Ini pembacaan yang benar atas Scrum Guide: peran Product Owner hanya ada di dalam Scrum. Jika tim Anda tidak menjalankan Scrum, Anda tidak perlu menciptakan Product Owner. Anda perlu siapa pun yang memprioritaskan pekerjaan, sering Product Manager langsung, kadang delivery lead, untuk jelas soal otoritasnya, apa pun sebutannya.

Bagaimana SAFe memisahkan Product Management dari Product Owner

Begitu organisasi tumbuh melampaui segelintir Scrum Team, pola informal di atas cenderung berhenti berfungsi. Di sinilah Scaled Agile Framework menjadi relevan, karena ia salah satu dari sedikit framework yang menamai kedua peran secara eksplisit dan menarik garis tegas di antaranya.

SAFe mendefinisikan Product Owner-nya sebagai "anggota tim Agile yang terutama bertanggung jawab memaksimalkan nilai yang dihasilkan tim dengan memastikan backlog tim selaras dengan kebutuhan pelanggan dan pemangku kepentingan." Peran itu berada di level tim, satu per Agile Team, mengerjakan pekerjaan yang sangat mirip dengan deskripsi Scrum Guide.

Product Management dalam SAFe adalah fungsi terpisah di level program: "fungsi yang bertanggung jawab mendefinisikan solusi yang diinginkan, layak secara bisnis, layak secara teknis, dan berkelanjutan yang memenuhi kebutuhan pelanggan." Product Management memiliki program backlog (fitur, bukan story level tim), menetapkan prioritas di seluruh Agile Release Train, dan bekerja langsung dengan Business Owner dan System Architect. Dokumentasi SAFe sendiri eksplisit bahwa Product Owner berfungsi "sebagai bagian dari fungsi Product Management yang lebih besar," cara formal untuk mengatakan apa yang dilakukan Pola 2 di atas secara informal: strategi berada di atas eksekusi, dan keduanya membutuhkan koneksi terdefinisi, bukan sekadar kedekatan.

Koneksi itu paling terlihat di PI Planning, event di mana setiap tim dalam sebuah Agile Release Train, bersama Product Management, menghabiskan dua hari menyelaraskan 8 hingga 12 minggu pekerjaan berikutnya. Itu satu-satunya momen berulang di mana strategi level program yang dimiliki Product Management dan backlog level tim yang dikelola Product Owner harus direkonsiliasi dalam satu ruangan. Product Management juga biasanya memiliki pemisahan yang dijelaskan dalam epic vs feature vs story: epic dan feature berada di level program, dan story, unit yang dikelola Product Owner dalam sprint, berada di level tim.

Pelajaran praktisnya: pada skala besar, "product owner vs product manager" berhenti menjadi perdebatan tentang jabatan mana yang lebih senior dan menjadi pertanyaan tentang level hierarki backlog mana yang menjadi tanggung jawab seseorang. SAFe tidak menyelesaikan ambiguitas di tempat lain dalam artikel ini. Ia menyelesaikannya khusus untuk organisasi yang menjalankan beberapa Scrum Team di bawah satu train yang terkoordinasi, yaitu situasi di mana Pola 1 (satu orang, kedua topi) tidak lagi berkelanjutan.

Keterampilan dan jalur karier

Kedua peran menghargai kekuatan yang berbeda, bahkan ketika orang yang sama akhirnya mengerjakan kedua pekerjaan di awal kariernya.

Jalur karier di antara keduanya tidak selinear yang disarankan papan lowongan. Banyak orang berpindah dari Product Owner ke Product Manager setelah membangun cukup pengetahuan domain dan pelanggan untuk memiliki strategi, progresi alami yang tersirat dalam struktur SAFe. Sama banyaknya yang berpindah ke arah sebaliknya dengan sengaja: product manager berpengalaman yang ingin lebih dekat dengan tim dan menjauh dari manajemen pemangku kepentingan kadang mengambil peran Product Owner secara sengaja, terutama di perusahaan di mana "Product Manager" telah bergeser ke koordinasi proyek alih-alih strategi produk.

Data kompensasi untuk kedua jabatan ini sungguh tidak dapat diandalkan untuk dikutip. Agregator gaji publik saling berbeda puluhan ribu dolar untuk jabatan yang sama di pasar yang sama, hasil yang dapat diprediksi dari sampel yang dilaporkan sendiri dan tidak terkendali, bukan sinyal nyata. Perlakukan angka tunggal mana pun yang Anda lihat dikutip di internet dengan skeptisisme sungguhan, dan lihat leveling internal perusahaan Anda sendiri.

Cara memutuskan peran mana yang sebenarnya dibutuhkan tim Anda

Jawab pertanyaan-pertanyaan ini secara berurutan.

Kesalahan umum

Merekrut "Product Owner" padahal deskripsi pekerjaannya sebenarnya pekerjaan Product Manager. Ini terjadi terus-menerus. Perusahaan memasang lowongan "Product Owner," tetapi tanggung jawab sebenarnya mencakup riset pasar, masukan penetapan harga, dan kepemilikan roadmap, yang semuanya tidak diberikan Scrum Guide kepada peran tersebut. Kandidat datang mengharapkan pekerjaan berfokus backlog dan akhirnya mengerjakan pekerjaan strategis yang tidak mereka direkrut atau level-kan untuk itu.

Mengasumsikan jabatan dapat dipertukarkan antar perusahaan. Product Owner di satu perusahaan mungkin punya otoritas roadmap penuh. Product Manager di perusahaan lain mungkin tidak punya sama sekali, dan menghabiskan hari menulis tiket. Jangan mengira Anda tahu cakupan kerja sebenarnya seseorang dari kartu namanya. Tanyakan apa yang mereka miliki.

Membiarkan Product Owner menjadi sekadar penerima perintah. Scrum Guide eksplisit bahwa Product Owner itu akuntabel, bukan administratif. Jika pekerjaan Product Owner direduksi menjadi meneruskan keputusan Product Manager menjadi item backlog yang tersusun baik tanpa masukan atas apa keputusan itu seharusnya, itulah mode kegagalan Pola 3 yang dibangun sengaja ke dalam bagan organisasi.

Terlambat memisahkan peran. Tim sering menunggu sampai orang yang mengerjakan kedua pekerjaan tampak jelas kelelahan sebelum memisahkan strategi dari eksekusi. Sinyal yang lebih baik adalah kapasitas, bukan burnout: jika backlog refinement dan perencanaan roadmap sama-sama terburu-buru, itulah saatnya memisahkan pekerjaan, bukan enam bulan setelah moral sudah anjlok.

Menyalin struktur SAFe tanpa mekanisme koordinasi SAFe. Beberapa organisasi mengadopsi pemisahan "Product Management di atas, Product Owner di bawah" tanpa mengadopsi sesuatu seperti PI Planning untuk menjaga kedua level tetap berbicara. Struktur saja tidak menciptakan keselarasan. Mekanisme pemaksalah yang melakukannya.

Jika Anda mengambil satu hal dari perbandingan ini, jadikan asimetri itu sendiri. Jangan mencari pemetaan baris demi baris yang bersih antara "Product Owner" dan "Product Manager," karena satu sisi pemetaan itu berlabuh pada dokumen dan sisi lainnya tidak. Tentukan akuntabilitas apa yang sebenarnya perlu dicakup tim Anda, entah kesehatan backlog level sprint, strategi level produk, atau keduanya, lalu putuskan apakah satu orang bisa jujur memegang sebanyak itu, atau sudah waktunya memisahkannya.