Sehari dalam Kehidupan Seorang Manajer Produk (B2B SaaS, Edisi Jujur)

Deskripsi pekerjaan bilang Anda akan "memiliki strategi produk, mendorong hasil, dan bermitra dengan engineering pada roadmap yang terpadu." Sekarang pukul 08.47 hari Selasa dan realitas Anda adalah tiga thread Slack yang bertumpuk satu sama lain: Sales ingin tahu apakah Anda bisa "tinggal menambahkan" SSO untuk deal yang akan ditutup hari Jumat, seorang engineer senior bertanya apakah penghapusan harus cascade atau soft-delete pada audit log baru, dan CEO menjatuhkan voice note "pemikiran cepat dari semalam" tentang dashboard. Seorang designer juga menunggu salinan teks untuk sebuah empty state. Anda belum membuka dokumen roadmap Anda dan kemungkinan tidak akan membukanya selama sembilan puluh menit ke depan.

Ini bukan mode kegagalan. Inilah peran pada tahap ini. Seorang PM B2B SaaS di antara Series A dan akhir Series B tidak menjalankan organisasi produk yang Anda baca di buku dari perusahaan yang lima putaran pendanaan di depan Anda. Anda melakukan pekerjaan PM, sebagian pekerjaan PMM, sebagian pengalihan rapat support, dan cukup banyak peran "pemilik hal yang tidak dimiliki siapa pun". Jika Anda sudah enam bulan di kursi ini dan merasa tertinggal pada "pekerjaan sebenarnya" setiap hari, masalahnya bukan Anda. Bentuk pekerjaannya memang seperti itu.

Yang dilakukan panduan ini: menelusuri hari Selasa nyata di perusahaan ber-ARR $5J-$100J, menamai pola-polanya, dan memberi Anda struktur mingguan yang bisa dipertahankan di atas kekacauan itu.

Mengapa hari Anda terlihat seperti ini

Matematika headcount tidak kenal ampun. Pada Series A Anda sering kali satu-satunya PM untuk 8-15 engineer yang tersebar di dua squad, ditambah tim GTM beranggota 4 orang yang semuanya ingin memberi masukan roadmap. Pada Series B Anda mungkin punya PM kedua, tapi luas permukaannya sudah berlipat tiga. Sekarang Anda juga memiliki tool internal, alur self-serve, dan apa pun yang dirilis founder sebelum Anda bergabung yang tidak disentuh siapa pun selama setahun.

Anda belum punya Product Marketing Manager, jadi salinan peluncuran jatuh ke tangan Anda. Anda belum punya orang Product Ops, jadi kerangka prioritisasi, templat catatan rilis, dan dewan pelanggan semuanya ada di Notion Anda. Tim CS mengeskalasi apa pun yang tidak bisa mereka jawab dalam dua balasan, dan itu banyak. CEO menggunakan Anda sebagai tempat bertukar pikiran karena Anda satu-satunya orang di gedung dengan konteks cukup di seluruh produk, pelanggan, dan engineering untuk memberi jawaban berguna dalam waktu kurang dari lima menit.

Setengah-PM, setengah-PMM, setengah-pengalih-rapat berjumlah lebih dari 100% dengan sengaja. Itulah matematikanya. Keterampilannya bukan menjejalkannya ke dalam 40 jam; melainkan memutuskan apa yang mendapat perhatian nyata Anda dan apa yang cukup mendapat penanganan "cukup baik".

08.00: Tinjauan panggilan pelanggan (20 menit, tak bisa ditawar)

Sebelum standup, sebelum Slack, Anda membuka Gong atau Chorus dan memilih satu panggilan dari kemarin. Biasanya discovery call atau exit dari pelanggan yang churn. Anda memindai bagian-bagian di mana pelanggan berbicara lebih dari 30 detik berturut-turut. Di situlah sinyal sesungguhnya berada. Rangkuman dari Sales rep hampir selalu terlalu murah hati ("mereka suka demonya!") atau tersaring melalui keberatan apa pun yang paling dikhawatirkan rep itu pada kuartal tersebut.

Saya pernah melihat seorang PM menyadari bahwa yang digambarkan Sales sebagai "mereka ingin pelaporan yang lebih baik" sebenarnya adalah calon pelanggan yang berkata "Saya tidak bisa menunjukkan kepada CFO saya mengapa kami harus membeli ini dibandingkan tetap memakai spreadsheet." Masalah berbeda. Fitur berbeda. Fitur itu akan dirilis dengan salah.

Anda mencatat insight di Productboard atau Aha, biasanya sebagai catatan satu baris yang ditandai ke inisiatif yang tepat, dengan stempel waktu panggilan tertaut. Dua puluh menit, setiap hari kerja, tanpa pengecualian. Ini adalah satu kebiasaan paling berdaya ungkit dalam peran ini dan ini adalah hal pertama yang ditinggalkan saat minggu menjadi riuh. Jangan tinggalkan.

Tengah pagi: async dengan engineering soal pertanyaan spec

Standup pukul 10. Anda menghabiskan dua puluh menit setelahnya menjawab komentar Linear atau Jira. Separuhnya bersih: "ya, perlakukan kasus itu sebagai no-op." Separuh lainnya adalah pajak ambiguitas spec: pertanyaan yang tampak seperti klarifikasi tetapi sebenarnya merupakan perubahan ruang lingkup yang berkedok klarifikasi.

Contoh nyata dari minggu lalu: "Hanya mengklarifikasi, ketika seorang pengguna dihapus dari workspace, apakah kita juga mencabut API token mereka?" Itu bukan klarifikasi. Spec-nya tidak mencakupnya karena tidak ada yang memikirkannya. Jawaban "ya, cabut" adalah dua belas jam kerja, satu tinjauan keamanan, dan catatan komunikasi yang menghadap pelanggan. Jawaban "tidak, biarkan saja" adalah tiga baris kode dan satu tiket support di masa depan. Keduanya bisa dipertahankan. Tidak ada yang sesuai dengan apa yang dikatakan spec.

Pekerjaan PM di sini adalah mengenali bahwa pertanyaan itu adalah persimpangan jalan, bukan rambu petunjuk, dan entah memutuskan dengan cepat atau mengeskalasi ke panggilan keputusan 15 menit bersama lead engineer dan orang keamanan. Yang membunuh tim adalah PM yang berkata "ya, lakukan mana saja yang lebih mudah" karena ia tertinggal di Slack, lalu mengetahui dua sprint kemudian bahwa jalur yang "lebih mudah" menciptakan celah kepatuhan.

Balasan Loom adalah tool yang bagus di sini. Loom 90 detik yang menjawab "ini yang saya pikirkan, ini trade-off-nya, bantah saya jika saya salah" memberi Anda jawaban yang lebih kaya dibanding mengetiknya, dan engineer bisa menontonnya ulang.

Tengah hari: discovery call yang bukan voting fitur

Anda memblokir 12.00 hingga 12.45 untuk panggilan pelanggan atau calon pelanggan. Bukan panggilan yang dipimpin Sales di mana Anda penutupnya; melainkan percakapan discovery yang nyata. Dokumen Notion terbuka, dua pertanyaan yang sudah ditulis sebelumnya, dan kesediaan untuk mengikuti alurnya.

Sebagian besar discovery call buruk karena merupakan voting fitur yang menyamar. Anda bertanya "apakah Anda akan memakai integrasi Salesforce?" dan mereka bilang "ya, tentu," karena mengatakan ya tidak merugikan mereka dan mereka ingin membantu. Itu bukan data. Pertanyaan discovery yang baik berada di hulu fitur: "Ceritakan kepada saya terakhir kali Anda mencoba melakukan X. Apa yang sebenarnya Anda lakukan? Apa yang rusak? Apa yang Anda lakukan sebagai gantinya?" Anda menginginkan kisah spesifik yang baru terjadi, bukan preferensi abstrak.

Jebakannya adalah memperlakukan panggilan itu sebagai sesi feedback. Bukan. Itu sesi riset, dan riset memiliki pertanyaan yang Anda bawa masuk untuk dijawab. Tulis pertanyaan itu di bagian atas dokumen Notion sebelum panggilan dimulai. Setelah panggilan, tulis tiga hal: apa yang Anda dengar, apa yang mengejutkan Anda, apa yang berubah pada hal berikutnya yang akan Anda bangun. Jika tidak ada yang berubah, panggilan itu tidak berguna, yang justru berguna, karena artinya Anda sudah berada di titik di mana Anda harus memvalidasi dengan prototipe, bukan wawancara.

Untuk versi yang lebih mendalam dengan skrip, lihat Menjalankan Discovery Call yang Bukan Voting Fitur.

Sore: sync mingguan dengan pemangku kepentingan

Pukul 14.00. Sales lead, CS lead, Marketing lead, dan Anda, dalam ruang 45 menit. Ini adalah rapat di mana permintaan "bisakah kita tinggal menambahkan" diarsipkan, diprioritaskan, atau dimatikan. Jika Anda tidak punya rapat ini pada hari tetap, Anda menjalaninya dalam serpihan-serpihan sepanjang minggu di Slack dan kehilangan tiga jam untuknya alih-alih empat puluh lima menit.

Anda menampilkan roadmap di Productboard atau Aha, bukan slide. Slide menyiratkan finalitas; roadmap langsung menyiratkan "ini keadaan saat ini, bisa berubah, ini trade-off-nya." Anda menelusuri apa yang sedang berjalan, apa yang berikutnya, dan item mana yang bergeser minggu ini dan alasannya. Lalu Anda mengambil tiga hingga lima permintaan baru, mengajukan pertanyaan yang menentukan ("berapa jumlah pelanggan dan bobot ARR di balik ini?"), dan entah berkomitmen untuk mengevaluasi, menolak dengan alasan, atau memarkirnya.

Mengatakan tidak tanpa menjadi PM-yang-selalu-bilang-tidak sebagian besar soal memberi penolakan itu bentuk yang jelas. "Kita tidak akan melakukan ini di Q3 karena kita berkomitmen pada kecepatan onboarding dan ini akan menundanya tiga minggu; mari tinjau ulang pada perencanaan kuartal berikutnya" adalah penolakan yang bisa dijual Sales lead Anda secara internal. "Kita tidak bisa melakukan itu sekarang" adalah penolakan yang kembali sebagai DM Slack besok.

Kerangka yang terus saya datangi: setiap ya juga merupakan tidak terhadap hal lain. Buat hal-lain itu terlihat. Tunjukkan trade-off-nya. Trade-off itulah percakapannya.

Akhir hari: penataan backlog

Pukul 16.30. Empat puluh lima menit di Linear atau Jira menutup tiket basi, menarik kandidat sprint berikutnya, dan meninjau rilis kemarin di Amplitude atau Mixpanel. Figma terbuka di tab sebelah untuk komentar design pada hal yang masuk ke sprint setelah ini.

Kebersihan backlog tidak glamor dan itulah pembeda antara tim engineering yang memercayai prioritisasi Anda dan yang tidak. Jika sebuah tiket sudah terbuka selama enam minggu tanpa pergerakan, tutup dengan komentar yang menjelaskan alasannya. Tiket basi dalam backlog adalah kebisingan yang menenggelamkan sinyal tentang apa yang sebenarnya berikutnya. Engineer berhenti membaca backlog ketika backlog berhenti bisa dipercaya, dan begitu itu terjadi Anda kembali menggerakkan segalanya melalui Slack.

Pemeriksaan Amplitude singkat: apakah fitur yang Anda rilis minggu lalu menggerakkan metrik yang Anda katakan akan ia gerakkan? Jika ya, tulis catatan satu baris di tiket peluncuran dan lanjutkan. Jika tidak, tanyakan mengapa sebelum Anda merilis hal berikutnya di atasnya. Sebagian besar PM merilis hal berikutnya tanpa memeriksa hal terakhir, dan begitulah pabrik fitur terjadi.

Dua jebakan

Pabrik fitur. Velocity tinggi. Tim merilis. Standup terasa produktif. Tapi ketika Anda memeriksa metrik hasil (aktivasi, retensi, ekspansi, yang dijanjikan roadmap untuk digerakkan) semuanya datar atau menuju arah yang salah, dan tidak ada seorang pun di tim yang punya satu jam tenang untuk memikirkan mengapa selama tiga bulan. Uji baunya: jika Anda bertanya kepada engineer senior Anda "masalah apa yang kita selesaikan sprint ini dan bagaimana kita tahu kita sudah menyelesaikannya," apakah mereka punya jawaban yang jelas? Jika jawabannya "kita merilis spec," Anda berada dalam pabrik fitur.

Solusinya bukan memperlambat. Solusinya adalah menaruh metrik hasil di samping setiap inisiatif pada roadmap dan menolak memulai yang berikutnya sampai Anda memeriksa apakah yang terakhir berhasil. Sepuluh menit "apakah ia menggerakkan angkanya" sebelum setiap kickoff. Murah untuk dilakukan. Nyaris tak ada yang melakukannya. Lihat Keluar dari Pabrik Fitur untuk versi yang lebih panjang.

Sales membajak roadmap. Setiap deal menjadi komitmen kustom. Produk terpecah karena pelanggan A mendapat alur kerja yang tidak dimiliki pelanggan B, dan sekarang Anda merilis logika kondisional di delapan tempat berbeda. Enam bulan kemudian Anda punya utang teknis yang tidak bisa Anda lunasi karena setiap potongannya melekat pada nama seorang pelanggan.

Sinyal awal: jika tiga pergeseran roadmap terakhir Anda masing-masing berasal dari satu deal, Anda sedang dibajak. Solusinya adalah aturan yang jelas yang diketahui seluruh perusahaan. Aturan saya adalah "kita hanya akan mempertimbangkan komitmen kustom jika deal-nya lebih dari 5x ACP saat ini dan permintaan yang sama datang dari tiga pelanggan terpisah." Sesuaikan angkanya dengan tahap Anda. Intinya adalah memiliki aturan, tertulis, yang bisa Sales kutipkan kembali ke calon pelanggan tanpa mengeskalasi ke Anda. Lihat Mengatakan Tidak kepada Sales Tanpa Menjadi PM-yang-Selalu-Bilang-Tidak.

Stack yang Anda sentuh setiap hari

Anda tidak butuh setiap tool. Anda butuh satu di tiap kategori, dan Anda butuh data mengalir di antara mereka.

Untuk perbandingan yang lebih panjang dan apa yang harus dipilih di tiap tahap, lihat Tool dan Tech Stack Manajer Produk.

Bentuk mingguan yang bisa dipertahankan

Anda tidak bisa mengendalikan setiap ping Slack. Anda bisa memutuskan blok mana yang Anda pertahankan dan mana yang Anda biarkan dimakan kekacauan.

Inilah bentuk mingguan yang bertahan saat berbenturan dengan realitas di sebagian besar perusahaan B2B SaaS:

Dilindungi berarti ia masuk kalender sebelum hal lain dan Anda mempertahankannya seperti rapat dengan pelanggan. Blok waktu-berpikir adalah yang paling sering dilewati PM, dan itu juga yang menentukan apakah Anda beroperasi satu kuartal di depan atau selalu satu minggu di belakang. Dua jam, tanpa Slack, satu pertanyaan untuk dipikirkan, satu dokumen untuk ditulis di akhir. Lindungi itu.

Dipadatkan berarti Anda menerimanya tapi menerimanya dengan cepat. Rapat status pindah ke async. Permintaan "ada waktu sebentar" mendapat "kirim saya Loom atau dokumen dan saya akan merespons sebelum akhir hari." Intinya bukan menjadi tidak tersedia; melainkan membuat biaya menarik Anda ke dalam sesuatu sama dengan biaya menarik orang lain.

Penutup

Pekerjaan ini berbentuk seperti ini karena perusahaannya berbentuk seperti ini. PM di perusahaan beranggota 12 orang dengan empat pelanggan punya hari yang berbeda dari PM di perusahaan beranggota 200 orang dengan empat ratus pelanggan, dan berpura-pura sebaliknya adalah cara Anda berakhir mencoba menyalin proses dari deck yang tidak berlaku untuk tahap Anda.

Yang bertahan lintas tahap: lindungi ritual panggilan pelanggan, namai pajak ambiguitas spec saat Anda melihatnya, jalankan discovery call dengan pertanyaan bukan daftar fitur, tampilkan roadmap Anda sebagai trade-off langsung dan bukan slide, dan periksa apakah hal terakhir berhasil sebelum Anda merilis hal berikutnya.

Satu kalimat untuk ditempel ke tinjauan kalender Anda besok pagi: apa yang mendapat perhatian nyata minggu ini, apa yang mendapat penanganan "cukup baik", dan apakah itu yang akan saya pilih jika saya memulai minggu ini dari awal?

Jika jawabannya tidak selama dua minggu berturut-turut, bentuknya perlu diubah.

Pelajari Lebih Lanjut

• Templat Deskripsi Pekerjaan Manajer Produk
• PM vs Product Marketing Manager: Di Mana Sebenarnya Garis Pemisahnya
• Menjalankan Discovery Call yang Bukan Voting Fitur
• Mengatakan Tidak kepada Sales Tanpa Menjadi PM-yang-Selalu-Bilang-Tidak
• Keluar dari Pabrik Fitur