Bahasa Indonesia

PMM sebagai Jembatan: Cara Product Marketing Menghubungkan CS dan Product

PMM sebagai jembatan antara CS dan Product, model terjemahan dua arah

Turn this article into takeaways for your work.

Summarize with ChatGPT Summarize with Claude

Each assistant summarizes the article only for you and suggests best practices for your work.

Penerjemah yang tiba setelah rapat. PMM dipanggil ketika fitur sudah dispesifikasi, peta jalan produk sudah dikunci, dan peluncuran tinggal tiga minggu lagi. Permintaannya: tulis email peluncuran, perbarui situs web, buat ringkasan satu halaman. PMM menjalankan. Konten dikirimkan. CS membaca pesan eksternal pada saat yang sama dengan pelanggan.

Itu bukan jembatan. Itu adalah tim pembersih.

Pola tim pembersih adalah cara kebanyakan perusahaan menengah menggunakan PMM di titik temu CS-Product. Itulah juga mengapa titik temu terus bocor. CS tidak tahu apa yang akan dikirimkan atau bagaimana cara membicarakannya. Product tidak tahu masalah pelanggan mana yang mendesak atau bagaimana membingkainya untuk penentuan prioritas. Dan PMM sibuk menulis email peluncuran untuk fitur yang dirancang tanpa konteks pelanggan yang cukup agar dapat mendarat dengan baik. Ini adalah tanda-tanda peringatan bahwa CS dan product tidak selaras yang sudah familiar.

Artikel ini membahas seperti apa jembatan sesungguhnya, secara struktural daripada relasional. Karena kesalahan yang paling banyak dibuat tim adalah berpikir efektivitas PMM di titik temu adalah fungsi dari seberapa kolaboratif atau komunikatif PMM tersebut. Bukan itu. PMM yang kolaboratif dalam organisasi yang tidak menghubungkannya tidak dapat menjembatani kesenjangan. Jembatan dibangun melalui desain organisasi, deliverable yang ditentukan, dan peran tetap dalam ritual di mana keputusan titik temu dibuat.

Perusahaan di mana PMM disertakan dalam sesi sintesis suara pelanggan (VoC) bersama CS Ops melaporkan adopsi fitur 29% lebih tinggi pada 90 hari pasca-GA, dibandingkan perusahaan di mana PMM hanya aktif saat peluncuran, per riset penyelarasan ProductBoard 2024.

Waktu rata-rata antara draf spesifikasi fitur pertama PM dan keterlibatan pertama PMM adalah 18 hari di perusahaan tanpa protokol penghubungan PMM terstruktur. Pada titik itu, sebagian besar keputusan UX dan lingkup sudah dikunci dan PMM menerjemahkan sesuatu yang tidak mereka bantu bentuk, per studi yang sama.

Model Terjemahan PMM 2 Arah: Seperti Apa Jembatan Sesungguhnya Secara Struktural

Jembatan memiliki dua fungsi penopang. Ia membawa lalu lintas di kedua arah, dan ia menahan beban. Model Terjemahan PMM 2 Arah menamai kedua fungsi ini secara eksplisit karena sebagian besar perusahaan menghubungkan PMM hanya dalam satu arah (hilir, dari Product ke CS) dan bertanya-tanya mengapa sinyal CS tidak pernah mencapai Product dalam bentuk yang berguna.

PMM yang bertindak sebagai jembatan antara CS dan Product harus membawa sinyal pelanggan dari CS ke Product dan membawa keputusan produk dari Product ke CS. Dan harus menahan beban, artinya harus dihubungkan ke dalam desain organisasi, bukan hanya bagan organisasi. Riset strategi product marketing Gartner menggambarkan pemasar produk sebagai orkestrator yang harus menyatukan produk, penjualan, dan customer success di balik tujuan go-to-market bersama: persis fungsi titik temu yang dijelaskan di sini.

Versi struktural ini terlihat seperti dua fungsi terjemahan yang beroperasi secara bersamaan.

Fakta Utama: Kesenjangan Jembatan PMM

  • Hanya 34% PMM di perusahaan SaaS menengah yang memiliki tempat duduk tetap dalam tinjauan peta jalan produk sebelum keputusan dikunci, per laporan State of Product Marketing 2024 Product Marketing Alliance.
  • 61% tim CS melaporkan bahwa sumber informasi utama mereka tentang fitur baru adalah changelog publik, bukan briefing internal pra-GA dari Product atau PMM, per tolok ukur tahunan ChurnZero 2024.
  • CSM di perusahaan dengan proses pre-brief PMM terstruktur menghabiskan 2,3 jam lebih sedikit per siklus rilis untuk mengimprovisasi penjelasan kepada pelanggan, per tolok ukur efisiensi CS Totango 2024.

Arah 1: CS ke Product. PMM mengambil sinyal kualitatif mentah dari CSM (verbatim, pola eskalasi, tema QBR) dan menerjemahkannya ke dalam format yang dapat digunakan PM dalam penentuan prioritas. Terstruktur, berbobot, dikategorikan, berlabel ARR. Bukan "pelanggan frustrasi dengan pelaporan" tetapi "sembilan akun yang mewakili $2,1 juta ARR telah menggunakan solusi alternatif Excel untuk ekspor rentang tanggal kustom selama dua kuartal terakhir." Ini adalah pipeline VoC dengan PMM sebagai lapisan sintesis.

Arah 2: Product ke CS. PMM mengambil spesifikasi fitur bahasa rekayasa dan catatan rilis lalu menerjemahkannya menjadi tiga output siap pelanggan: pre-brief CS, pesan dalam aplikasi, dan catatan rilis eksternal. Bukan "peningkatan mesin kueri lanjutan" tetapi "pelanggan Anda sekarang dapat memfilter ekspor berdasarkan rentang tanggal kustom. Ini yang harus dikatakan ketika mereka bertanya tentang itu, dan ini adalah tiga pertanyaan yang akan Anda dapatkan."

Kedua arah memerlukan keterampilan dasar yang sama: memahami kosakata kedua sisi dengan cukup baik untuk menerjemahkan tanpa kehilangan makna. Namun tidak ada satu pun arah yang berhasil secara struktural tanpa PMM dihubungkan ke ritual di mana materi sumber berasal. Ritual-ritual itu adalah tempat Arah 1 dan Arah 2 terjadi atau tidak.

Arah 1: Sinyal CS ke Input Product

CSM mengumpulkan verbatim kualitatif. PM membutuhkan input terstruktur, berbobot, dan dikategorikan. Kesenjangan antara kedua format itu adalah tempat sebagian besar pipeline VoC rusak. CSM yang berkata "pelanggan frustrasi dengan modul pelaporan" tidak memberi PM cukup untuk ditindaklanjuti. PMM yang mensintesis sinyal itu menjadi "tujuh akun yang mewakili $1,4 juta ARR menggunakan solusi alternatif Excel karena fungsi ekspor tidak mendukung rentang tanggal kustom, dikonfirmasi di tiga siklus QBR" memberi PM sesuatu yang dapat mereka masukkan dalam sesi penentuan prioritas.

Peran PMM dalam Arah 1 memiliki tiga fungsi konkret.

Mempertahankan taksonomi umpan balik. Baik CS maupun Product perlu menandai sinyal pelanggan menggunakan kategori yang sama: area produk, tingkat keparahan, status solusi alternatif, dampak ARR. Ketika CSM menandai umpan balik secara tidak konsisten, PM tidak dapat mengagregasinya secara bermakna. PMM memiliki taksonomi, melatih tim CS cara menggunakannya, dan mengaudit kepatuhan setiap kuartal. Ini adalah infrastruktur operasional, bukan pekerjaan kreatif. Panduan menangkap umpan balik secara sistematis mencakup mekanika sisi CSM dari proses ini.

Menjalankan sintesis VoC kuartalan. Sekali per kuartal, PMM mengagregrasi umpan balik yang diajukan CS selama 90 hari terakhir (tiket VoC, verbatim NPS, catatan QBR, tema eskalasi) dan menimbangnya berdasarkan dampak ARR. Outputnya adalah dokumen sintesis singkat: lima tema teratas berdasarkan bobot ARR, verbatim kunci yang mendukung setiap tema, dan urutan prioritas yang direkomendasikan untuk dipertimbangkan PM. PMM mempresentasikan ini bersama CS Ops dalam tinjauan CS-Product kuartalan.

Menerjemahkan bahasa pelanggan menjadi masalah produk. Ini adalah fungsi leverage tertinggi dalam Arah 1. Pelanggan berkata "saya benci pelaporan." CSM menulis "pelanggan frustrasi dengan modul pelaporan." PMM menerjemahkan: "pelanggan tidak dapat melihat data lintas modul dalam satu tampilan, jadi mereka mengekspor ke spreadsheet dan membangun ulang laporan secara manual, yang membutuhkan 2-3 jam per minggu per pengguna." Terjemahan mempertahankan konteks pelanggan dan memberi PM definisi masalah yang dapat mereka buat spesifikasinya.

Arah 2: Keputusan Product ke Komunikasi CS

PM menulis spesifikasi dan catatan rilis dalam bahasa rekayasa. CSM berkomunikasi dalam outcome pelanggan. PMM menerjemahkan, dan terjemahan harus terjadi sebelum GA, bukan setelahnya.

Kegagalan standar: PM menulis changelog teknis. CSM membacanya tetapi tidak tahu apa yang harus dikatakan kepada pelanggan. Pelanggan mengetahui dari catatan rilis publik atau dari produk itu sendiri. CSM mendapat email dari pelanggan yang menanyakan apa yang berubah sebelum CSM memiliki jawaban yang berguna.

Peran PMM dalam Arah 2 memiliki tiga output konkret per rilis.

Pre-brief CS. Dokumen singkat, satu halaman dengan lima bagian, yang dikirimkan ke tim CS lima hari kerja sebelum GA. Bagian-bagian: apa yang dikirimkan (dalam bahasa sederhana), apa yang akan diperhatikan pelanggan (secara khusus apa yang berubah dalam alur kerja mereka), tiga pertanyaan yang akan diajukan pelanggan dan cara menjawabnya, segmen pelanggan mana yang paling terpengaruh, dan akun mana yang harus menerima penjangkauan proaktif dari CSM mereka sebelum atau pada hari GA.

Pesan dalam aplikasi. Ditulis dalam bahasa outcome pelanggan, bukan bahasa deskripsi fitur. "Anda sekarang dapat membuat laporan rentang tanggal kustom tanpa mengekspor ke Excel" daripada "Mesin kueri pelaporan lanjutan kini tersedia." PMM memiliki template dan salinannya; Product meninjau untuk akurasi; CS meninjau untuk nada.

Catatan rilis. Catatan eksternal resmi tentang apa yang dikirimkan. Lebih teknis dari pesan dalam aplikasi; lebih mudah dibaca pelanggan dari spesifikasi internal. PMM menulis; PM meninjau; PMM menerbitkan. Arsip dimiliki oleh PMM.

Ketiga output perlu ada sebelum GA. Bukan pada hari GA. Sebelumnya. Ini mengharuskan PMM menerima ringkasan fitur dari PM setidaknya sepuluh hari sebelum GA, dan jadwal itu harus menjadi ekspektasi yang ditentukan, bukan permintaan.

Apa yang Dibawa PMM yang Tidak Dapat Dilakukan CS maupun Product Sendiri

Peran jembatan berhasil karena PMM secara unik membawa tiga jenis konteks yang tidak dapat dengan mudah diakses oleh CS maupun Product sendiri.

Konteks positioning. PMM tahu bagaimana produk diposisikan di pasar: klaim apa yang dibuat, pembeda apa yang ditekankan, produk dijual sebagai apa. Ketika sebuah fitur dikirimkan yang bertentangan dengan positioning saat ini (atau yang harus mengubahnya), PMM adalah orang yang menangkapnya sebelum CS dan Sales mulai menyampaikan pesan yang salah. CS tidak memiliki visibilitas pasar. Product tidak memiliki visibilitas pesan. PMM berada di persimpangan.

Kecerdasan kompetitif. PMM melacak apa yang dikirimkan pesaing. CS mendengar ketika pelanggan mengajukan perbandingan kompetitif. Forrester mencatat bahwa kolaborasi awal dan terstruktur tentang kecerdasan kompetitif adalah praktik yang menentukan dari tim product marketing yang berkinerja tinggi. PMM mensintesis kedua aliran menjadi input yang berguna untuk Product: bukan "pelanggan sering menyebutkan Pesaing X" tetapi "Pesaing X mengirimkan fitur di Q3 yang mengatasi kesenjangan pelaporan yang sama yang ditandai pelanggan kami. Ini yang mereka lakukan dan artinya bagi peta jalan produk kami." Sinyal CS yang memunculkan perbandingan kompetitif harus mengalir melalui model penentuan prioritas umpan balik berbobot ARR sebelum mencapai PM.

Pengujian pesan. PMM dapat menguji A/B bagaimana pelanggan merespons berbagai framing dari fitur yang sama sebelum CS harus mengomunikasikannya dalam skala besar. Dua deskripsi berbeda dari perubahan alur kerja yang sama dapat menghasilkan reaksi pelanggan yang sangat berbeda. Mengujinya dengan sampel kecil sebelum rilis penuh mencegah komunikasi yang membuat fitur yang baik mendarat dengan buruk.

Kondisi Struktural yang Membuat PMM Menjadi Jembatan Nyata

Efektivitas PMM di titik temu ditentukan oleh desain organisasi, bukan kepribadian. Riset Forrester tentang penyelarasan product marketing dan manajemen menemukan bahwa ketika peran-peran ini memiliki tanggung jawab yang jelas dan metrik bersama, organisasi melihat efisiensi eksekusi yang lebih tinggi dan lebih sedikit gangguan komunikasi saat peluncuran. Empat kondisi ini adalah perbedaan antara PMM sebagai jembatan dan PMM sebagai tim pembersih.

PMM disertakan dalam tinjauan peta jalan produk sebelum keputusan dikunci. Bukan dalam tinjauan retrospektif. Bukan dalam sesi "kami ingin memberi tahu Anda sebelum dikirimkan." PMM perlu berada di ruangan ketika prioritas peta jalan produk ditetapkan, sebelum spesifikasi ditulis, sehingga konteks pasar dan bahasa pelanggan dapat membentuk fitur sebelum dibangun. Jika keterlibatan pertama PMM adalah setelah spesifikasi, jembatan bersifat satu arah dan terlambat.

PMM memiliki tempat duduk tetap dalam tinjauan VoC kuartalan. Tinjauan umpan balik pelanggan kuartalan adalah tempat umpan balik pelanggan kuartal sebelumnya menjadi input peta jalan produk kuartal berikutnya. Jika PMM tidak ada di meja itu bersama CS Ops dan PM, fungsi terjemahan rusak: sinyal CS pergi ke PM secara langsung dan kehilangan lapisan sintesis; atau PMM mengetahui apa yang diprioritaskan setelah fakta dan menulis untuk brief yang tidak mereka bantu bentuk.

Deliverable PMM ke CS sesuai jadwal yang ditentukan. Pre-brief tiba lima hari kerja sebelum GA. Sintesis VoC diterbitkan pada tanggal sepuluh setiap bulan. Kalender rilis diperbarui pada Senin pertama setiap bulan. Ketika deliverable PMM ke CS terjadwal, CS dapat merencanakan di sekelilingnya. Ketika bersifat ad-hoc, CS kembali ke improvisasi.

PMM memiliki wewenang untuk menolak peluncuran jika komunikasi belum siap. Ini adalah kondisi yang paling banyak dilewatkan perusahaan. Kesiapan peluncuran mencakup persetujuan PMM. Jika pre-brief tidak lengkap, jika pesan dalam aplikasi belum ditinjau, jika tim CS belum menerima pre-brief mereka, PMM harus memiliki posisi untuk menandai itu dan menunda tanggal GA. Ini terdengar radikal. Namun itu lebih tidak radikal daripada CSM yang mengimprovisasi penjelasan kepada pelanggan sehari setelah perubahan yang membingungkan dikirimkan.

Apa yang Tidak Boleh Dimiliki PMM di Titik Temu

Peran jembatan memiliki lingkup yang ditentukan. Ketika PMM berkembang melampaui itu, peran berhenti bekerja.

PMM tidak boleh memiliki keputusan hubungan spesifik-pelanggan. Akun mana yang harus dihubungi, CSM mana yang harus dilibatkan, cara menangani pelanggan yang sudah kesal tentang suatu perubahan: itu tetap ada pada CS. PMM menetapkan pesan; CS menetapkan penjangkauan.

PMM tidak boleh memiliki keputusan penentuan prioritas produk. PMM menginformasikan dengan konteks pasar dan sinyal pelanggan yang disintesis, tetapi tidak memiliki backlog atau peta jalan produk. Ketika PMM mulai membuat argumen penentuan prioritas daripada memberikan input penentuan prioritas, itu menciptakan konflik dengan PM yang merusak kepercayaan yang diperlukan peran jembatan.

PMM tidak boleh memiliki penilaian kesehatan atau penilaian risiko akun. Itu adalah fungsi CS Ops. PMM tahu akun mana yang ada di tingkat komunikasi mana; CS tahu akun mana yang berisiko. Itu adalah dataset yang berbeda.

Ketika Perusahaan Belum Memiliki PMM

Ini umum di perusahaan menengah pra-Seri B. Fungsi terjemahan jatuh pada siapa pun yang mau, biasanya Head of Product atau VP CS, dan itu bekerja dengan buruk karena tidak keduanya memiliki waktu atau konteks tim ganda untuk melakukannya dengan baik.

Pola tim pembersih adalah hasil alami ketika tidak ada PMM: Product mengirimkan, CS bergegas, dan Head of Product menulis deskripsi fitur dalam pesan Slack ke channel CS karena tidak ada orang lain yang melakukannya. Kerangka kerja RACI siapa yang memiliki perubahan yang menghadapi pelanggan menunjukkan cara mendistribusikan pekerjaan ini secara eksplisit tanpa headcount PMM penuh.

Model sementara yang bekerja lebih baik dari tim pembersih: tetapkan satu orang CS Ops dan satu PM untuk memiliki fungsi terjemahan bersama, dengan protokol serah terima yang jelas. CS Ops menulis pre-brief CS dari ringkasan fitur PM. PM meninjaunya. Protokol didokumentasikan dan diulang per rilis. Ini lebih lambat dari PMM yang berdedikasi dan menghasilkan output berkualitas lebih rendah, tetapi secara struktural baik dan berkembang hingga PMM dipekerjakan.

Satu catatan penting tentang sementara pra-PMM: jangan mempekerjakan PMM dan segera menempatkan mereka dalam pola tim pembersih. Kegagalan paling umum ketika perusahaan mempekerjakan PMM pertama mereka adalah PMM masuk ke dalam organisasi yang memperlakukan mereka sebagai penulis email peluncuran. Bangun desain organisasi jembatan sebelum PMM mulai, sehingga perannya memiliki dukungan struktural dari hari pertama.

Model Operasi PMM-di-Titik-Temu yang Konkret

Desain organisasi abstrak mudah disetujui dan sulit diimplementasikan. Ini adalah ritme spesifiknya.

Bulanan (berkelanjutan): PMM menerbitkan sintesis VoC dari data CS bulan sebelumnya pada tanggal sepuluh bulan tersebut. Sintesis mencakup lima tema umpan balik teratas, berbobot ARR, dengan verbatim representatif. PM meninjau pada tanggal lima belas. Sesi input backlog diadakan sebelum akhir bulan, dengan PMM dan CS Ops hadir.

Per rilis: PMM menerima ringkasan fitur dari PM sepuluh hari sebelum GA. PMM menyampaikan pre-brief CS kepada pimpinan CS lima hari sebelum GA. Pimpinan CS mendistribusikan ke tim akun pada hari yang sama. Pada hari GA, PMM menerbitkan pesan dalam aplikasi dan catatan rilis. PMM mengarsipkan semua aset rilis.

Kuartalan: PMM co-mempresentasikan sintesis VoC dalam tinjauan kuartalan CS-Product bersama bersama CS Ops. PM mempresentasikan respons peta jalan produk: apa yang diprioritaskan berdasarkan input VoC, apa yang tidak, dan mengapa. PMM menjalankan sesi penyelarasan pesan untuk rilis yang direncanakan kuartal berikutnya.

Sinyal bahwa PMM Tidak Berfungsi sebagai Jembatan

Gunakan ini sebagai diagnostik, bukan sebagai tuduhan.

CS mengetahui perubahan fitur bersamaan dengan pelanggan. Ini adalah sinyal paling tidak ambigu bahwa PMM tidak ada dalam lingkaran Arah 2 atau tidak menyampaikan pre-brief cukup awal.

PM mempresentasikan kutipan pelanggan dalam rapat penentuan prioritas yang tidak pernah didengar tim CS. Ini berarti sinyal CS mencapai Product melalui saluran yang melewati PMM, sehingga fungsi sintesis, pembobotan, dan terjemahan tidak terjadi.

Output PMM adalah email peluncuran, bukan pre-brief. Email peluncuran melayani funnel akuisisi. Pre-brief melayani retensi. Ketika output PMM seluruhnya berorientasi akuisisi, fungsi jembatan telah runtuh menjadi tim pembersih.

Sintesis VoC kuartalan tidak ada. Ini berarti PMM tidak ada dalam Arah 1 sama sekali. Product menerima sinyal CS mentah atau tidak ada sinyal CS, dan PMM menunggu untuk menulis tentang apa pun yang dikirimkan.

Sinyal-sinyal ini adalah masalah struktural, bukan kegagalan individual. Ketika muncul, solusinya adalah mengaudit empat kondisi struktural (penyertaan tinjauan peta jalan produk, tempat duduk tetap tinjauan VoC, jadwal deliverable yang ditentukan, dan wewenang kesiapan peluncuran), bukan berbicara dengan PMM tentang menjadi lebih proaktif. Model operasi di bagian berikutnya menempatkan keempat kondisi pada jadwal konkret.

Analisis Rework: Kapan Menghubungkan PMM vs Kapan Menggunakan Sementara

Berdasarkan tolok ukur SaaS menengah, fungsi jembatan PMM memberikan imbal hasil tertinggi pada dua momen spesifik: sebelum peta jalan produk dikunci (Arah 1, sintesis sinyal CS) dan lima hari sebelum GA (Arah 2, pengiriman pre-brief). Perusahaan yang hanya dapat mendanai satu momen harus memprioritaskan jendela pre-brief. Pre-brief CS terstruktur yang dikirimkan lima hari sebelum GA secara konsisten mengurangi waktu improvisasi pasca-pengiriman sebesar 2+ jam per CSM per rilis dan secara terukur meningkatkan adopsi minggu pertama. Fungsi sintesis VoC (Arah 1) memiliki nilai strategis lebih tinggi selama beberapa kuartal tetapi dampak langsung lebih rendah per rilis. Untuk perusahaan tanpa PMM yang berdedikasi, model sementara (CS Ops menulis pre-brief dari ringkasan PM, PM meninjau) menangkap sekitar 70% nilai Arah 2 dengan headcount yang ada, per estimasi operasional dari perusahaan yang telah menjalankan model ini sebelum mempekerjakan PMM pertama mereka.

Pertanyaan yang Sering Diajukan

Apa itu Model Terjemahan PMM 2 Arah?

Model Terjemahan PMM 2 Arah menggambarkan peran struktural PMM di titik temu CS-Product sebagai dua fungsi terjemahan simultan: Arah 1 (CS ke Product) mengubah sinyal pelanggan mentah dari CSM menjadi input berbobot berlabel ARR yang dapat digunakan PM dalam penentuan prioritas; Arah 2 (Product ke CS) mengubah spesifikasi fitur rekayasa menjadi tiga output siap pelanggan: pre-brief CS, pesan dalam aplikasi, dan catatan rilis eksternal. Sebagian besar perusahaan menghubungkan PMM hanya ke Arah 2 dan bertanya-tanya mengapa sinyal CS tidak pernah mencapai Product dalam bentuk yang berguna.

Apa yang dimiliki PMM di titik temu CS-Product dibandingkan apa yang dimiliki CS dan PM?

PMM memiliki lapisan terjemahan: template pesan, sintesis VoC, pre-brief, kalender komunikasi rilis, dan salinan pesan dalam aplikasi. PMM tidak memiliki keputusan penjangkauan spesifik-pelanggan (akun mana yang harus dihubungi, CSM mana yang harus dilibatkan). Itu tetap ada pada CS. PMM tidak memiliki penentuan prioritas backlog. Itu tetap ada pada PM. Peran jembatan memiliki lingkup yang ditentukan, dan ketika PMM berkembang melampaui itu ke dalam keputusan hubungan pelanggan atau argumen prioritas produk, peran berhenti bekerja.

Mengapa hanya 34% PMM yang memiliki tempat duduk tetap dalam tinjauan peta jalan produk sebelum keputusan dikunci?

Alasan paling umum adalah waktu dan inersia: tinjauan peta jalan produk diperlakukan sebagai rapat internal produk, dan PMM hanya dibawa setelah keputusan dibuat untuk menulis narasi peluncuran. Namun pada saat spesifikasi difinalisasi, sebagian besar keputusan UX dan lingkup sudah dikunci. PMM yang dihubungkan setelah spesifikasi adalah tim pembersih, bukan jembatan. Solusinya adalah protokol formal, bukan permintaan budaya, yang menjadikan kehadiran PMM dalam tinjauan peta jalan produk sebagai ekspektasi tetap sebelum siklus berikutnya dimulai.

Apa yang harus dimuat dalam pre-brief CS?

Pre-brief CS harus mencakup lima elemen: apa yang dikirimkan dalam bahasa sederhana, apa yang secara khusus akan diperhatikan atau dialami pelanggan secara berbeda, tiga pertanyaan paling umum yang akan diajukan pelanggan dan cara CSM harus menjawabnya, segmen pelanggan mana yang paling terpengaruh, dan akun mana yang harus dihubungi CSM secara proaktif sebelum atau pada hari GA. Harus satu halaman dan disampaikan lima hari kerja sebelum GA. Ini bukan dokumen yang sama dengan catatan rilis publik.

Apa yang terjadi ketika perusahaan belum memiliki PMM?

Tanpa PMM, fungsi terjemahan jatuh pada siapa pun yang mau, biasanya Head of Product atau VP CS, dan itu bekerja dengan buruk karena tidak keduanya memiliki waktu atau konteks tim ganda untuk mempertahankannya. Model sementara yang berhasil: tetapkan satu orang CS Ops dan satu PM untuk memiliki pre-brief bersama per rilis. CS Ops menulis brief yang menghadapi CS dari ringkasan fitur PM; PM meninjau untuk akurasi. Itu lebih lambat dari PMM yang berdedikasi tetapi secara struktural baik. Kesalahan utama yang harus dihindari: mempekerjakan PMM pertama dan segera menempatkan mereka dalam pola tim pembersih. Bangun desain organisasi jembatan sebelum PMM mulai, bukan setelahnya.

Bagaimana peran kecerdasan kompetitif PMM terhubung ke CS?

PMM melacak apa yang dikirimkan pesaing. CS mendengar ketika pelanggan mengajukan perbandingan kompetitif dalam panggilan. Tanpa fungsi sintesis PMM, kedua aliran ini tidak pernah menyatu: CS meneruskan eskalasi ke atas, Product melihat perbandingan kompetitif dalam data menang/kalah, dan tidak ada tim yang memiliki gambaran lengkap. PMM mensintesis keduanya: bukan "pelanggan sering menyebutkan Pesaing X" tetapi "Pesaing X mengirimkan fitur di Q3 yang mengatasi kesenjangan pelaporan yang sama yang ditandai pelanggan kami. Ini yang mereka lakukan dan artinya bagi penentuan prioritas." Sinyal CS yang memunculkan perbandingan kompetitif harus ditandai ke PMM sebelum masuk ke pipeline VoC.

Pelajari Lebih Lanjut