Bahasa Indonesia

30/60/90 Hari Pertama Anda sebagai Manajer Produk Baru

Anda akan menerima pesannya di minggu ke-2. Kadang hari ke-4. Ia mendarat di Slack dari seseorang yang senior, biasanya sales lead atau CEO, dan bunyinya kira-kira: "hai, bisakah kamu scope ini untuk sprint berikutnya? Pelanggan besar sedang meminta."

Mengatakan ya terasa seperti pekerjaannya. Itu jebakannya.

PM yang merilis di minggu ke-2 adalah PM yang dilepas di bulan ke-6. Bukan karena mereka merilis hal yang salah (meskipun biasanya memang begitu), melainkan karena mereka menghabiskan kredibilitas mereka pada fitur pertama yang diminta siapa pun, alih-alih membelinya kembali melalui discovery. Pada saat mereka memahami masalah sesungguhnya, mereka sudah membakar satu setengah sprint niat baik engineering pada fitur yang hanya akan disentuh 11% pelanggan.

Inilah playbook untuk jalur yang lain. Inilah cara saya akan menjalankan 90 hari pertama saya jika saya mulai hari Senin.

Mengapa 30/60/90 lebih penting bagi PM dibanding peran lain mana pun

Seorang engineer baru merilis PR di minggu ke-1 dan tim berterima kasih kepadanya. Seorang designer baru mendorong file Figma di minggu ke-2 dan tim memuji karyanya. Seorang PM baru merilis fitur di minggu ke-2 dan tim... menunggu untuk melihat apakah ia berhasil, lalu diam-diam menurunkan skor kepercayaan mereka ketika ternyata tidak.

PM tidak punya otoritas langsung. Kita tidak menulis kode, kita tidak menggambar layar, dan kita tidak menandatangani kontrak. Satu-satunya mata uang yang kita miliki adalah kepercayaan + bukti. Jendela 90 hari adalah jendela di mana eng lead Anda, designer Anda, manajer Anda, dan 2 pemangku kepentingan teratas Anda diam-diam memutuskan apakah Anda seorang ahli strategi yang kebetulan memakai Jira, atau penggerak Jira yang kebetulan menyebut diri ahli strategi.

30 hari pertama adalah saat Anda membeli kredibilitas itu. 30 hari berikutnya adalah saat Anda mulai membelanjakannya dengan hati-hati. 30 hari terakhir adalah saat Anda mulai menggandakannya.

Lewati fase satu dan sisanya runtuh.

Hari 1-30: Mendengar, jangan merilis

Bulan pertama punya satu tugas: membangun teori pribadi tentang produk, pelanggan, dan tim yang lebih baik daripada yang dimiliki manajer Anda. Anda tidak bisa melakukan itu dari meja Anda.

Pesan 10 wawancara pelanggan dalam 21 hari pertama

Lima power user. Tiga pelanggan yang churn. Dua calon pelanggan yang tidak jadi membeli. Itu komposisinya.

Minta tim CSM Anda untuk power user, yang memperbarui langganan tanpa negosiasi dan membalas Slack dalam 10 menit. Minta siapa pun yang memiliki retensi untuk daftar churn, lalu secara spesifik minta yang pergi dalam 90 hari terakhir, bukan tahun lalu. Minta sales untuk calon pelanggan yang sampai ke demo lalu menghilang.

Tujuan panggilan ini bukan untuk memvalidasi solusi. Melainkan untuk menemukan bahasa yang dipakai pelanggan Anda ketika tidak ada yang mendengarkan. Power user akan memberi tahu Anda alur kerja yang mereka tambal-sulam. Pengguna yang churn akan memberi tahu Anda apa yang akhirnya mematahkan mereka. Calon pelanggan akan memberi tahu Anda apa yang hilang dalam demo yang tidak disadari siapa pun di tim deal.

Beberapa aturan yang saya pelajari dengan susah payah:

  • Maksimal 30 menit. Anda tidak menjalankan proyek riset enterprise. Disiplin kalender mengalahkan kedalaman di bulan pertama.
  • Rekam dengan persetujuan, transkripsikan dengan Otter atau Granola. Mendengarkan ulang pada kecepatan 1,5x adalah tempat pola-pola muncul.
  • Tanyakan "apa yang Anda coba sebelum ini?" dengan lima cara berbeda. Di situlah pemicu pembelian dan solusi sementara berada.
  • Jangan mempromosikan apa pun. Bahkan tidak secara halus. Tugas Anda adalah mendengar, bukan menguji ide yang belum Anda miliki.

Pada wawancara ke-7 Anda akan mulai mendengar keluhan yang sama diungkapkan dengan tiga cara berbeda. Itu sinyal. Tuliskan secara harfiah. Salin kata-kata pelanggan, bukan terjemahan Anda atasnya. PM kehilangan 60% makna asli pada saat mereka memparafrasekan.

Audit 3 metrik tempat produk Anda diukur, dan temukan satu yang tidak Anda percayai

Setiap produk punya 3 angka yang menjadi dasar penilaiannya. Aktivasi. Retensi. ARR. Atau suatu varian. Temukan mereka. Lalu temukan kueri SQL, dashboard, dan orang yang memilikinya.

Anda mencari satu hal spesifik: metrik yang tidak bisa dijelaskan sepenuhnya oleh siapa pun. Mungkin itu "pengguna aktif mingguan" tetapi definisinya terakhir diperbarui 14 bulan lalu dan mengecualikan segmen pelanggan yang kini 30% dari basis. Mungkin itu tingkat aktivasi yang menghitung akun demo. Mungkin tidak ada yang bisa memberi tahu Anda apa arti "engaged".

Temukan metrik itu. Jangan perbaiki dulu. Cukup tuliskan pertanyaannya dan bawa ke check-in manajer hari ke-30 Anda. Ketika saya bergabung dengan perusahaan terakhir saya, metrik yang tidak bisa saya percayai ternyata adalah north star tempat seluruh roadmap bertumpu. Memunculkan satu pertanyaan itu membeli saya tiga bulan kredibilitas sebelum saya merilis apa pun.

Duduk bersama eng selama satu sprint, design untuk satu critique, support untuk satu hari

Undangan kalender, bukan DM Slack. Secara spesifik:

  • Engineering: minta untuk menghadiri sprint penuh mereka (planning, daily stand-up, retro). Jangan bicara kecuali diminta. Anda mempelajari arsitektur, dendam soal utang teknis, dan tiket mana yang membuat tim mengeluh.
  • Design: ikuti satu design critique, atau dua. Anda mempelajari kosakata design tim, seperti apa yang baik itu, dan bagian mana dari produk yang diam-diam memalukan bagi para designer.
  • Support: bayangi seorang agen support selama satu hari penuh, idealnya hari Rabu (volume tiket puncak di B2B SaaS). Anda akan melihat 4 masalah yang sama muncul 30 kali. Masalah-masalah itu adalah roadmap tersembunyi Anda.

Ini adalah pengintaian termurah yang akan pernah Anda jalankan. Sebagian besar PM melewatinya karena ia tidak menghasilkan artefak. Itulah intinya.

Pelajari domain codebase, bukan kodenya

Anda tidak perlu menulis PR. Anda perlu mampu membaca satu PR tanpa panik.

Dapatkan akses repo pada hari ke-3. Minta eng lead Anda memandu Anda melalui arsitektur tingkat-atas dalam 30 menit. Baca 10 PR terakhir yang di-merge. Tandai model datanya. Ketahui nama tiga layanan inti dan kira-kira apa yang mereka lakukan.

Standarnya adalah: ketika seorang engineer berkata "kita harus menyentuh billing service untuk melakukan ini," Anda tahu apakah itu berarti satu hari Selasa atau satu kuartal.

Satu aturan keras: jangan mengusulkan apa pun di all-hands pertama Anda

Jangan membagikan visi. Jangan mempromosikan roadmap. Jangan menjatuhkan "pendapat panas" di Slack perkenalan Anda. Setiap kata yang Anda ucapkan dalam 30 hari pertama dikalibrasi terhadap nol bukti, dan begitu Anda menaruh sebuah posisi di atas meja, Anda akan menghabiskan 60 hari berikutnya membelanya alih-alih menyempurnakannya.

Perkenalkan diri Anda. Katakan apa yang sedang Anda cari dengar. Janjikan satu pendapat pada hari ke-60. Lalu pergi mendengar.

Hari 31-60: Mendapatkan sinyal

Pada hari ke-31 Anda punya teori pribadi tentang produk. 30 hari berikutnya adalah tentang menguji teori itu di bawah tekanan tanpa mempertaruhkan kredibilitas penuh Anda padanya.

Rilis satu taruhan kecil yang tidak Anda usulkan

Inilah triknya: warisi sesuatu yang sudah di-scope. Fitur yang di-spec pendahulu Anda. Proyek bug-bash yang sudah lama mengendap di backlog. Migrasi kecil yang disepakati tim sebagai kebutuhan tetapi tidak dimiliki siapa pun.

Pilih sesuatu dengan definisi selesai yang jelas, rilis dalam tiga minggu, dan gunakan proyek itu sebagai gerakan kredibilitas cepat Anda. Anda tidak mempertaruhkan penilaian Anda padanya (Anda tidak memilihnya), tetapi Anda menunjukkan bahwa Anda bisa menjalankan satu sprint tanpa menjatuhkan tongkat estafet. Eng lead memperhatikan ini. Mereka lebih memperhatikan ini daripada pekerjaan discovery Anda, karena ini nyata.

Jika Anda di level senior atau staff, proyek warisan bisa berupa migrasi kecil atau penghentian fitur yang sudah usang. Bentuknya tidak sepenting jadwalnya. Tiga minggu. Selesai. Terlihat.

Jalankan satu sprint discovery pada masalah yang Anda temukan dalam wawancara

Sekarang Anda membelanjakan sepotong kredibilitas, dengan sengaja. Pilih sinyal terkuat dari wawancara pelanggan Anda (yang Anda dengar dari setidaknya 6 dari 10) dan jalankan sprint discovery terstruktur padanya.

Dua minggu. Satu PM (Anda), satu designer, satu engineer selama satu jam sehari. Keluaran: pernyataan masalah, tiga sketsa solusi, dan keputusan apakah akan menginvestasikan satu sprint penuh pada salah satunya.

Intinya bukan untuk merilis. Intinya adalah membuat discovery terbaca oleh tim Anda. Mereka belum pernah melihat Anda menjalankannya. Tunjukkan kepada mereka seperti apa yang baik itu. (Kami punya playbook sprint discovery yang menelusuri strukturnya jika Anda ingin templat.)

Usulkan v1 dari opportunity solution tree Anda, kepada manajer Anda saja

Pada hari ke-50 Anda sudah mendengar dari 10 pelanggan, mengaudit 3 metrik, duduk bersama eng, dan menjalankan satu sprint discovery. Itu cukup material untuk membangun opportunity solution tree v1: hasil yang diinginkan di puncak, peluang (masalah) yang sudah Anda validasi di bawahnya, dan beberapa solusi kandidat di dasarnya.

Tunjukkan kepada manajer Anda terlebih dahulu. Bukan tim. Bukan pemangku kepentingan. Manajer Anda, dalam 1:1, dengan permintaan eksplisit: "beri tahu saya di mana ini salah sebelum saya menyosialisasikannya."

Dua alasan. Satu: tree yang dibangun dalam ruang hampa akan dihancurkan di depan umum. Dua: manajer Anda tahu peta politik yang tidak Anda ketahui. Mereka akan memberi tahu Anda peluang mana yang dimiliki tim lain, mana yang menjadi dendam pribadi CEO, dan mana yang akan dimatikan oleh penataan ulang dewan.

Sempurnakan tree-nya, lalu rencanakan walkthrough yang lebih luas untuk hari ke-75. (Jika Anda ingin primer strukturalnya, opportunity solution tree dijelaskan untuk PM B2B membahasnya.)

Mulai menulis catatan produk mingguan: temuan discovery, bukan update status

Setiap Jumat, kirim dokumen singkat ke manajer Anda dan eng lead Anda. Bukan update status hasil ekstraksi Jira. Sebuah catatan discovery. Apa yang Anda dengar dari pelanggan minggu ini. Metrik apa yang Anda selidiki. Apa yang membuat Anda berubah pikiran.

300-500 kata. Tanpa daftar proyek. Tanpa burndown sprint. Catatan ini memposisikan Anda sebagai seseorang dengan sudut pandang, bukan seseorang dengan backlog.

Kebiasaan ini menggandakan diri. Pada bulan ke-6, eng lead Anda akan membaca catatan Anda sebelum standup. Pada bulan ke-12, CEO Anda akan meneruskannya kepada kandidat sebagai artefak rekrutmen.

Hari 61-90: Mengambil kepemilikan

Kepemilikan dalam PM berarti tiga hal: metrik yang menjadi tanggung jawab Anda secara publik, roadmap dengan daftar "tidak" yang eksplisit, dan kesediaan untuk mematikan hal-hal yang tidak layak.

Miliki satu metrik secara publik, dan pilih input, bukan output

Pada hari ke-65, posting di channel Slack tim Anda: "Saya mengambil tingkat aktivasi mingguan untuk pendaftaran self-serve baru. Target: tingkatkan dari 22% ke 30% pada akhir Q3. Saya akan posting tiap minggu."

Dua catatan soal pemilihan metrik:

  1. Pilih input, bukan output. Tingkat aktivasi adalah input bagi retensi. Retensi adalah output. Input adalah hal yang bisa Anda gerakkan langsung dengan perubahan produk. Output adalah hal yang akan Anda salahkan ketika sales punya kuartal yang buruk. Miliki input. (Kami menggali ini di metrik PM: hasil versus keluaran.)
  2. Pilih sesuatu yang tidak akan bergerak karena kampanye marketing. Jika metrik Anda bisa didongkrak oleh blast email, Anda tidak memilikinya. Marketing yang memilikinya.

Memiliki metrik secara publik adalah satu gerakan paling berdaya ungkit dari 90 hari pertama. Ia mengubah cara Anda dilihat oleh tim eng, rekan-rekan Anda, dan manajer Anda. Mulai hari ke-66 dan seterusnya, Anda bukan "PM baru." Anda adalah "PM yang memiliki aktivasi."

Presentasikan roadmap 6 bulan Anda dengan 3 taruhan dan 3 penolakan eksplisit

Hari ke-75-80. Anda masuk ke tim Anda dan mempresentasikan roadmap.

Bukan 12 fitur. Tiga taruhan. Setiap taruhan terikat pada satu peluang dari tree. Setiap taruhan dengan hipotesis, target pergerakan metrik, dan kriteria pembunuhan.

Lalu (dan inilah bagian yang dilewati sebagian besar PM baru) Anda mendaftar tiga hal yang secara eksplisit TIDAK Anda lakukan. Bukan "kita akan sampai ke sana nanti." Bukan "ada di backlog." Sebuah "tidak" yang nyata dengan alasan yang nyata. "Kita tidak membangun pelaporan lanjutan pada paruh ini. Data memberi tahu kita power user menginginkannya tapi power user tidak churn. Kita fokus pada aktivasi."

Daftar "tidak" itulah yang memberi Anda hak untuk mengatakan tidak di lain waktu ketika sales bertanya. Tanpanya, setiap permintaan adalah wilayah baru dan Anda harus mengulang perdebatan prioritas setiap minggu.

Jalankan upacara pembunuhan untuk 3 fitur zombie

Fitur zombie adalah sesuatu yang dirilis, tidak terpakai, dan tidak ada yang berani menghentikannya. Setiap produk B2B SaaS punya mereka. Produk Anda punya lebih banyak dari yang Anda kira.

Pada hari ke-85, identifikasi tiga. Kriteria: adopsi kurang dari 5%, tidak ada pengembangan aktif dalam 9 bulan terakhir, tidak ada pelanggan enterprise yang memilikinya dalam kontrak mereka.

Lalu jalankan penghentian. Umumkan. Email beberapa pelanggan yang memakainya (jumlahnya akan lebih sedikit dari yang Anda takutkan). Dokumentasikan mengapa Anda mematikannya dalam dokumen publik. Rayakan di standup.

Upacara pembunuhan melakukan tiga hal. Ia menandakan bahwa Anda akan menukar ruang lingkup demi fokus. Ia membersihkan beban mental engineering (zombie lebih mahal dalam pemeliharaan daripada yang diakui siapa pun). Dan ia menetapkan preseden bahwa tidak ada yang sakral dalam produk.

Bangun log keputusan Anda

Pada hari ke-90 Anda punya satu dokumen (Notion, Linear, di mana pun) yang mencatat setiap keputusan produk yang berarti: pertanyaannya, opsi yang dipertimbangkan, pilihannya, tanggalnya, alasannya.

Anda di masa depan akan berterima kasih kepada Anda di masa kini. Lain kali sales masuk dengan permintaan mengejutkan yang sesuai dengan sesuatu yang Anda tolak di bulan ke-2, Anda akan punya jejak dokumennya. "Kita membuat keputusan ini pada 14 Mei. Inilah yang kita ketahui, inilah yang perlu kita pelajari agar saya meninjaunya ulang. Apa yang berubah?"

Dua jebakan yang akan memakan 90 hari Anda jika Anda membiarkannya

Dua pola akan diam-diam menyerap waktu yang Anda butuhkan untuk segala hal di atas. Namai mereka sekarang.

Jebakan 1: Permintaan sales yang mengejutkan

Slack tiba. "Hai, saya sedang dalam tinjauan deal dengan $80K ARR dipertaruhkan. Mereka butuh [fitur]. Bisakah kita memasukkannya di sprint berikutnya?"

Jangan bilang ya. Jangan bilang tidak. Katakan ini:

"Ini persis jenis permintaan yang ingin saya tangani dengan hebat. Kirim saya one-pager deal-nya dan dua pain point terbesar calon pelanggan. Saya akan punya rekomendasi dalam 48 jam, bukan sprint berikutnya, tapi rekomendasi yang nyata. Jika kita bilang ya, saya ingin memastikan kita menyelesaikan untuk mereka, bukan hanya untuk satu deal ini. Jika kita bilang tidak, saya ingin Anda punya pembingkaian yang tepat untuk pelanggan."

Tiga hal yang dilakukan skrip ini:

  1. Membeli Anda 48 jam, yang merupakan pembeda antara strategi dan stenografi.
  2. Memaksa AE untuk mengartikulasikan masalah secara tertulis, yang langsung mematikan 30% permintaan (ternyata calon pelanggan baik-baik saja).
  3. Membingkai ulang Anda dari "PM yang membuka blokir deal" menjadi "PM yang meningkatkan cara kita menangani deal."

Anda akan membutuhkan skrip ini tiga hingga lima kali dalam 90 hari pertama Anda. Simpan dalam sebuah snippet. (Jika Anda ingin versi lebih mendalam dari percakapan ini, mengatakan tidak kepada sales tanpa merusak hubungan menelusuri playbook lengkapnya.)

Jebakan 2: PM-sebagai-project-manager

Anda akan tahu ini sedang terjadi ketika kalender Anda 70% berisi standup, retro, sprint planning, dan "biar saya sync dengan kamu sebentar." Jumlah tiket Jira Anda naik. Jumlah wawancara pelanggan Anda datar.

Ini adalah versi perlahan dari kegagalan peran. Tidak ada yang menyuruh Anda menjadi project manager tim. Anda terbawa ke sana karena tim punya kekosongan dan Anda mengisinya.

Atur ulang sebelum melekat. Tiga gerakan:

  • Tolak dua rapat berulang minggu ini. Pilih dua yang paling rendah daya ungkitnya dan cukup katakan "saya rasa saya tidak perlu hadir di sini." Dunia tidak akan berakhir.
  • Serahkan administrasi sprint ke tech lead atau scrum master Anda. Jika Anda tidak punya, minta. PM bukanlah pemilik Jira.
  • Blokir 2 jam setiap pagi untuk discovery. Panggilan pelanggan, transkrip, pekerjaan opportunity tree. Tak bisa ditawar. Jika Anda tidak punya 2 jam discovery dalam hari Anda, Anda tidak punya pekerjaan PM. Anda punya pekerjaan koordinasi dengan jabatan PM.

Jebakan ini nyaman. Koordinasi terlihat. Discovery tak terlihat sampai bulan ke-4 ketika ia menjadi terlihat. Pilih pekerjaan yang tak terlihat lebih awal daripada yang terasa aman.

Templat: check-in manajer hari ke-30

Ketika Anda masuk ke 1:1 hari ke-30 Anda, bawa one-pager ini. Ia menambatkan percakapan menjauh dari "bagaimana Anda beradaptasi" dan menuju apakah Anda membangun teori pribadi yang tepat.

CHECK-IN HARI KE-30: [Nama Anda]

YANG SUDAH SAYA PELAJARI
- 3 pola pelanggan yang saya dengar berulang kali:
  1. [verbatim]
  2. [verbatim]
  3. [verbatim]
- 1 metrik yang tidak saya percayai: [metrik] ([alasannya])
- 1 hal yang sedang diselesaikan tim yang akan saya bingkai ulang: [observasi]

YANG SAYA USULKAN (BELUM ADA)
- Hari 60: opportunity tree v1 untuk Anda
- Hari 75: usulan roadmap untuk tim
- Hari 90: memiliki satu metrik secara publik

YANG SAYA BUTUHKAN DARI ANDA
- [permintaan spesifik 1 (biasanya perkenalan pelanggan)]
- [permintaan spesifik 2 (biasanya peringatan pemangku kepentingan)]
- [permintaan spesifik 3 (biasanya ruang lingkup otoritas atas suatu keputusan)]

Kirim 24 jam sebelum rapat. Manajer Anda akan membacanya dua kali.

Seperti apa yang baik itu pada hari ke-90

Inilah kalibrasinya. Pada akhir hari ke-90, tiga hal seharusnya benar.

Satu: Anda bisa menyebut 3 masalah teratas yang benar-benar dimiliki pelanggan Anda. Bukan yang ada di roadmap. Yang nyata, dalam bahasa pelanggan. Anda bisa memberi peringkat berdasarkan frekuensi dan tingkat keparahan, dan Anda bisa menunjuk wawancara yang memvalidasi masing-masing.

Dua: eng lead Anda memercayai prioritisasi Anda. Anda akan tahu karena mereka berhenti bertanya "apakah kamu yakin kita mengerjakan hal yang benar?" dan mulai bertanya "apa berikutnya setelah ini?" Pergeseran itu adalah segalanya.

Tiga: manajer Anda tidak perlu bertanya apa yang sedang Anda kerjakan. Anda mengirim catatan discovery hari Jumat. Anda memiliki metrik publik. Roadmap Anda punya daftar "tidak." Log keputusan Anda diperbarui mingguan. Tarikan berhenti dibutuhkan karena dorongannya andal.

Jika ketiganya benar pada hari ke-90, Anda sudah mendapatkan hak untuk mengambil ayunan yang lebih besar di bulan ke-4. Jika tidak satu pun benar, Anda tidak gagal, tetapi Anda membeli pekerjaan project-manager, bukan pekerjaan PM, dan Anda punya satu kuartal lagi untuk mengatur ulang.

Kepercayaan menggandakan diri. Keluaran meluruh. Belanjakan 90 hari pertama untuk membeli kepercayaan yang membiarkan Anda melakukan pekerjaan sesungguhnya selama 900 hari berikutnya.

Pelajari Lebih Lanjut