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

Hari ke-4. PM Anda menjatuhkan file Figma di DM dengan "bisakah kamu poles ini untuk Jumat?" Anda memoles. Rasanya baik, Anda merilis sesuatu di hari keempat, PM berterima kasih di standup, EM memberi emoji jempol. Selamat datang.

Anda juga baru saja kehilangan satu-satunya jendela yang Anda miliki untuk mempertanyakan masalah yang mendasarinya. Pada saat Anda tiga bulan masuk, Anda sudah memoles enam belas spesifikasi, tidak bisa menyebutkan satu pelanggan pun yang pernah Anda ajak bicara, dan manajer Anda bertanya apa yang sebenarnya sudah Anda rilis yang benar-benar milik Anda. Jawaban jujurnya adalah: tidak ada. Anda sudah menjadi operator Figma dengan gelar Senior.

Inilah lintasan default. Pola PM-sebagai-pelempar-spesifikasi adalah gravitasi organisasi, dan Anda tidak keluar dari itu secara kebetulan. Anda keluar darinya dengan masuk membawa rencana 90 hari, menjalankannya dengan sengaja, dan memiliki kemenangan awal kecil yang membelikan Anda kredibilitas untuk terus berkata tidak.

Mengapa 90 Hari Pertama Tidak Bisa Dinegosiasikan

Tidak ada periode netral di perusahaan B2B SaaS. Reorganisasi terjadi. Reset OKR mendarat di minggu ke-8. Siklus kinerja merujuk apa pun yang Anda lakukan di kuartal pertama Anda. Desainer yang dipromosikan di tahun kedua adalah mereka yang mengukir waktu discovery sebelum antrean Jira mengunci mereka.

Saya pernah bergabung dengan perusahaan Series C di mana desainer produk sebelumnya bertahan sembilan bulan dan pergi dengan "kelelahan." Saya membaca riwayat Figma mereka. Mereka merilis 47 spesifikasi. Mereka tidak menjalankan satu pun panggilan pelanggan. Mereka tidak berkontribusi apa pun ke design system. Ketika organisasi dirombak di bulan ketujuh, kepemimpinan tidak bisa mengartikulasikan apa yang mereka miliki, jadi mereka dipindahkan ke produk yang akan dihentikan. Itulah biaya melewatkan 30 hari pertama.

Pola di bawah ini adalah apa yang akan saya jalankan pada hari pertama peran baru. Ini opinionated. Sesuaikan angkanya, jangan strukturnya.

Hari 1-30: Dengarkan dan Petakan

Satu-satunya tujuan bulan pertama adalah memahami sistem sebelum Anda mengubahnya. Anda akan tergoda untuk merilis di minggu ke-2. Jangan. Perilisannya terjadi di bulan dua, dan akan lebih baik jika Anda menghabiskan bulan pertama melakukan empat hal spesifik.

Jalankan 10 panggilan pelanggan

Bukan "wawancara pengguna." Panggilan. Ikuti CS pada tiga panggilan pelanggan langsung. Duduk di dua demo sales. Baca 50 tiket dukungan dan pilih lima untuk dihubungi kembali. Ikuti percakapan perpanjangan kontrak jika perusahaan Anda mengizinkan. Total: 10 percakapan dengan pelanggan yang membayar, dicatat dengan kutipan.

Anda tidak menjalankan proses discovery di sini. Anda melakukan kalibrasi. Anda ingin mendengar bahasa yang digunakan pelanggan, solusi sementara yang mereka bangun, layar yang mereka kutuk, fitur yang mereka pikir ada tapi tidak ada. Pada panggilan ke-10, Anda harus bisa melanjutkan kalimat pelanggan tentang produk Anda.

Skrip praktis untuk panggilan yang Anda inisiasi:

Halo [nama], saya baru bergabung sebagai desainer produk yang bekerja pada [area]. Saya menghabiskan bulan pertama berbicara dengan 10 pelanggan untuk memahami bagaimana Anda sebenarnya menggunakan produk. Ini bukan sesi umpan balik dan kita tidak akan merilis apa pun dari panggilan ini. Saya ingin 30 menit untuk melihat Anda melakukan [tugas] dan mengajukan beberapa pertanyaan. Apakah Selasa atau Kamis bisa?

Tiga hal yang dilakukan skrip ini: jujur tentang peran Anda, menghilangkan kekhawatiran "apakah mereka akan menawarkan sesuatu?", dan meminta perilaku (lihat Anda melakukan X), bukan pendapat.

Audit tiga layar dengan lalu lintas tertinggi

Tarik analitik produk. Pilih tiga layar dengan pengguna aktif mingguan paling banyak. Untuk masing-masing, dokumentasikan: pekerjaan yang coba dilakukan pengguna, alur saat ini, titik gesekan, dan data tingkat layar (rage click, drop-off, waktu di layar).

Jangan usulkan desain ulang dulu. Jangan bahkan membuat sketsa. Audit adalah dokumen referensi yang akan Anda gunakan di bulan dua dan tiga ketika seseorang bertanya "haruskah kita mendesain ulang dashboard?" Anda sudah akan punya jawabannya.

Pelajari design system dari ujung ke ujung

Setiap token. Setiap komponen. Setiap pengecualian yang terdokumentasi. Jika DS Anda memiliki 80 komponen, Anda perlu mengetahui semua 80 pada minggu ketiga. Ini pekerjaan yang tidak glamor. Lakukan bagaimanapun.

Mengapa: cara tercepat untuk kehilangan kepercayaan engineering adalah mendesain sesuatu yang "terlihat sedikit tidak tepat" karena Anda menggunakan bayangan kustom padahal ada token untuknya. Cara tercepat untuk mendapatkan kepercayaan adalah merilis file Figma di mana catatan tinjauan engineering berkata "tidak ada perubahan, semua komponen DS." Itu terjadi sekali, dan Anda sudah menabung kredit yang akan Anda habiskan di bulan ketiga.

Duduk bersama engineering dan produk

Dua sprint penuh bersama engineering. Itu berarti standup, perencanaan, retro, dan setidaknya satu tinjauan PR di mana seseorang memandu Anda melalui codebase. Tujuan: pahami apa yang mahal untuk diubah dan apa yang murah.

Dua siklus perencanaan dan grooming bersama PM. Tujuan: pahami bagaimana roadmap sebenarnya dibuat, dari mana tekanannya berasal (sales? kepemimpinan? pelanggan tertentu?), dan pertempuran mana yang sudah kalah.

Pada akhir minggu keempat, Anda harus bisa menggambar grafik pengambilan keputusan organisasi di papan tulis. Siapa yang sebenarnya memutuskan apa yang dirilis. Hampir tidak pernah seperti yang Anda duga dari bagan organisasi.

Minggu demi minggu, bulan pertama

Hasil terakhir itu adalah jembatan ke bulan dua.

Hari 31-60: Rilis Kecil, Raih Kepercayaan

Bulan dua adalah tempat desainer produk baru kehilangan arah. Godaannya adalah mengambil ringkasan 1 halaman dari minggu keempat dan mempresentasikan visi desain ulang enam bulan. Jangan. Ajukan satu taruhan kecil. Jalankan satu sprint discovery. Kontribusikan satu pola DS. Tiga hal, semuanya kecil, semuanya dirilis.

Jalankan satu sprint discovery pada masalah yang terbatas

Bukan epic roadmap. Sesuatu yang berdekatan: sprint 2 minggu pada masalah yang diabaikan karena "terlalu kecil untuk diprioritaskan" tapi Anda memperhatikannya dalam panggilan pelanggan. Tolok ukur untuk masalah itu: Anda memiliki setidaknya tiga kutipan pelanggan tentangnya, dan perbaikannya kemungkinan menghabiskan kurang dari dua minggu engineering.

Contoh yang berhasil:

• Halaman pengaturan di mana 4 dari 10 pelanggan Anda berkata mereka tidak bisa menemukan tombol ekspor
• Kondisi kosong fitur yang hanya mengalami aktivasi 12%
• Breakpoint mobile alur yang mengonversi 40% di desktop tapi 8% di mobile

Output sprint discovery Anda adalah satu halaman: masalah, bukti, arah yang diusulkan, metrik keberhasilan, estimasi biaya engineering. Tunjukkan ke PM dan EM Anda. Minta dua minggu engineering.

Ketika PM berkata "tapi roadmap..." (dan mereka akan berkata itu), gunakan skrip ini:

Saya mengerti, epic roadmap adalah prioritas. Saya tidak meminta untuk menukarnya. Saya meminta dua minggu engineering untuk perbaikan terbatas ini yang memiliki [X kutipan pelanggan] di baliknya, akan menggerakkan [metrik] sekitar [Y%], dan memberi saya sesuatu yang bisa saya tunjukkan dalam laporan 90 hari saya. Jika kita merilis-nya dan tidak menggerakkan jarum, saya akan mengarahkan 100% ke roadmap untuk Q3.

Ini berhasil karena kecil, dibatasi waktu, didukung bukti, dan memberi PM jalan keluar. Sebagian besar PM akan berkata iya. Yang berkata tidak memberi tahu Anda sesuatu yang berguna tentang apakah tim ini akan membiarkan Anda melakukan desain.

Rilis satu taruhan kecil dari ujung ke ujung

Sprint discovery Anda menghasilkan satu halaman. Sekarang rilis. Dari ujung ke ujung berarti: Anda menulis spesifikasi (bersama PM, bukan untuk mereka), Anda mendesainnya dalam komponen DS, Anda merilis-nya melalui code review, Anda mendefinisikan metrik keberhasilan sebelum peluncuran, dan Anda memantaunya.

Pilih sesuatu di mana sebelum/sesudah bisa diukur dalam 30 hari. Perbaikan pola. Penyederhanaan alur. Desain ulang satu layar. Tolok ukurnya bukan "transformatif." Tolok ukurnya adalah "dirilis, diukur, dan Anda bisa menceritakan kisahnya."

Contoh nyata dari desainer produk yang saya mentor: dia merilis desain ulang kondisi kosong fitur otomasi workflow. Sebelum: 12% pengguna baru membangun workflow pertama mereka di minggu pertama. Sesudah: 31%. Desain ulangnya adalah empat layar. Dua minggu engineering. Dia menggunakan satu grafik itu dalam setiap percakapan selama setahun berikutnya.

Kontribusikan satu pola DS yang bisa digunakan kembali

Design system Anda memiliki celah. Anda menemukannya dalam audit bulan pertama. Pilih satu, sebaiknya yang muncul saat Anda mendesain taruhan kecil, sehingga ia berperan penting daripada spekulatif.

Alur kontribusi:

1. Buka proposal DS di repo design system tim Anda (atau file Figma). Dokumentasikan celahnya, tiga tempat ia akan digunakan, dan pola draft.
2. Dapatkan tinjauan DS lead sebelum keterlibatan engineering. Pekerjaan mereka adalah mengatakan tidak untuk 80% proposal. Pekerjaan Anda adalah memudahkan mereka berkata iya dengan menunjukkan celahnya nyata.
3. Dapatkan tinjauan engineering untuk kelayakan teknis. Pola harus murah untuk diimplementasikan dan dikelola.
4. Rilis sebagai bagian dari taruhan kecil Anda, atau sebagai tindak lanjut mandiri.

Satu pola di bulan dua. Bukan desain ulang DS. Satu pola. Desainer yang mencoba "memperbaiki design system" di kuartal pertama mereka dengan sopan dikeluarkan dari percakapan DS, secara permanen.

Daftar periksa bulan dua

• Satu sprint discovery 1-halaman, dibagikan kepada PM dan EM
• Satu taruhan kecil dirilis, dengan metrik keberhasilan yang didefinisikan dan dilacak
• Satu proposal pola DS, ditinjau dan digabungkan
• PM dan EM memiliki hal positif yang tidak diminta untuk dikatakan tentang bekerja dengan Anda

Yang terakhir bersifat kualitatif tapi penting. Dalam 1:1, tanya manajer Anda: "bagaimana kesan tim sejauh ini?" Jika jawabannya "kamu mudah diajak bekerja sama dan kamu merilis," kamu berada di jalur yang benar. Jika jawabannya "kamu pendiam" atau "kamu banyak menolak," perbaiki arah di bulan ketiga.

Hari 61-90: Miliki Sebuah Problem Space

Bulan ketiga adalah tempat Anda berhenti menjadi desainer baru dan menjadi desainer yang memiliki sesuatu. Tiga hasil.

Pilih satu metrik produk yang akan Anda pengaruhi

Tingkat aktivasi. Waktu-menuju-nilai-pertama. Adopsi fitur pada permukaan tertentu. Retensi segmen tertentu. Berpasangan dengan PM Anda untuk memilihnya. Ini tidak bisa dinegosiasikan, karena jika PM tidak setuju bahwa metrik itu milik mereka untuk dipengaruhi, Anda akan mengerjakan tujuan bayangan yang tidak dipedulikan siapa pun saat waktu kinerja tiba.

Kriteria untuk metriknya:

• Bergerak dalam cakrawala 4-12 minggu (bukan 2 hari, bukan 12 bulan)
• Pekerjaan desain Anda secara masuk akal bisa menggerakkannya 5%+
• PM dan EM akan berkata "ya itu metrik nyata untuk tim kita" tanpa ragu
• Ia terhubung ke hasil pelanggan, bukan angka vanitas

Presentasikan laporan 90 hari

Dek singkat. Lima slide. Bukan daftar file Figma.

1. Yang saya pelajari. 3 wawasan teratas dari 10 panggilan pelanggan. Satu kalimat masing-masing.
2. Yang saya rilis. Taruhan kecil, dengan metrik sebelum/sesudah. Pola DS, dengan di mana ia digunakan.
3. Yang saya pertaruhkan. Problem space yang Anda klaim untuk H2.
4. Metriknya. Satu metrik produk, dengan baseline saat ini dan target 90 hari.
5. Yang saya butuhkan. Kapasitas engineering, waktu riset, keputusan yang Anda butuhkan dari kepemimpinan.

Presentasikan kepada manajer, PM, dan skip-level Anda. 25 menit. Tujuannya bukan tepuk tangan. Tujuannya adalah bahwa tiga bulan dari sekarang, ketika seseorang bertanya "apa yang dilakukan [nama Anda]?", tiga orang berbeda memberikan jawaban yang sama.

Usulkan rencana desain H2 Anda

Satu halaman. Dua atau tiga area masalah yang akan Anda kerjakan dalam enam bulan ke depan. Untuk setiap area: hipotesis, metrik keberhasilan, pekerjaan discovery yang akan Anda butuhkan, estimasi biaya engineering.

Ini adalah dokumen yang melindungi waktu Anda. Ketika PM mencoba menjatuhkan tiket poles-spesifikasi-ini kepada Anda di bulan kelima, Anda menunjuk rencana H2 dan bertanya "apakah ini dalam rencana?" Jika tidak, percakapan menjadi keputusan prioritas nyata alih-alih iya-default.

Jebakan Umum, dan Cara Menghindarinya

Inilah empat cara rencana 90 hari gagal. Saya sudah menyaksikan semuanya terjadi.

Menerima loop poles-spesifikasi di minggu ke-1

PM memberi Anda file Figma di hari ke-4. Anda memoles-nya. Sekarang Anda adalah orang poles. Solusinya bukan menolak, karena itu membakar hubungan. Solusinya adalah pengalihan halus:

Senang melihatnya. Sebelum saya menyentuh visual, bisakah kita habiskan 15 menit pada alur yang mendasarinya? Saya ingin memastikan saya memahami masalahnya sehingga poles-nya benar-benar membantu. Jika alurnya solid, saya akan mengembalikannya kepada Anda sebelum akhir minggu.

Delapan dari sepuluh kali, percakapan 15 menit mengungkapkan alurnya memiliki masalah, dan Anda pada akhirnya melakukan pekerjaan desain nyata. Dua dari sepuluh kali, alurnya benar-benar baik dan Anda memoles-nya. Bagaimanapun, Anda telah menetapkan bahwa "desainer produk = kolaborator yang bijaksana" bukan "desainer produk = pengatur piksel."

Melewatkan panggilan pelanggan karena PM sudah melakukan riset

PM melakukan wawancara. Mungkin mereka melakukannya dengan baik. Tidak masalah. Interpretasi mereka tentang masalah pelanggan disaring melalui otak PM. Milik Anda perlu disaring melalui otak desainer. Jalankan 10 panggilan bagaimanapun. Biayanya 10 jam dalam sebulan. Nilainya adalah memiliki model pengguna Anda sendiri yang bisa Anda bela melawan model PM ketika Anda tidak setuju.

Mendesain ulang design system sebelum mendapatkan hak

DS Anda "ketinggalan zaman." Token Anda "berantakan." Komponen "tidak konsisten." Mungkin. Juga: Anda baru tiga minggu di sini. Setiap desainer produk yang bertahan lebih lama dari Anda sudah mencoba memperbaikinya. Beberapa berhasil dalam cara-cara kecil. Beberapa dipecat.

Hak untuk mendesain ulang DS diperoleh, bukan diberikan. Itu datang setelah Anda merilis 3-5 kemenangan kecil, berkontribusi 2-3 pola, dan DS lead mempercayai penilaian Anda. Itu adalah proses minimal setahun. Di bulan ketiga, pekerjaan Anda adalah satu pola, bukan dek visi.

Mempresentasikan laporan 90 hari sebagai daftar file Figma

"Ini 23 layar yang saya kerjakan." Tidak ada yang peduli. Kepemimpinan peduli tentang: apa yang Anda pelajari, berapa biayanya, apa yang dikembalikannya, apa yang Anda lakukan selanjutnya. Hasil, bukan artefak. Jika laporan 90 hari Anda memiliki lebih banyak layar daripada kalimat, Anda melakukan yang salah.

Template untuk Dicuri

Daftar singkat artefak yang harus Anda miliki pada hari ke-90:

• Skrip wawancara 10 panggilan (varian B2B SaaS). Pertanyaan berbasis perilaku, bukan berbasis pendapat. "Ceritakan kapan terakhir kali Anda melakukan X" mengalahkan "apa pendapat Anda tentang fitur Y" setiap saat.
• Template audit alur. Satu halaman per layar: pekerjaan, alur saat ini, titik gesekan, data, 3 hipotesis teratas untuk perbaikan.
• 1-halaman "mengapa ini sprint discovery, bukan spesifikasi fitur" untuk PM Anda. Gunakan ketika Anda perlu membela pekerjaan eksplorasi terhadap tekanan roadmap.
• Garis besar dek laporan 90 hari. Lima slide. Hasil, bukan layar.
• Satu halaman rencana H2. Dua atau tiga area masalah, hipotesis, metrik.

Anda tidak perlu satupun dari ini dipoles. Anda perlu kesemuanya ada dan bisa ditemukan di Notion atau Confluence tim Anda.

Mengukur Keberhasilan pada Hari ke-91

Lima hal. Jika Anda bisa mencentang semuanya, kuartal berikutnya dimulai dengan fondasi yang kuat.

• 10 panggilan pelanggan tercatat dengan kutipan yang bisa Anda sebutkan dari ingatan
• Satu taruhan yang dirilis dengan metrik sebelum/sesudah yang PM setujui nyata
• Satu pola DS yang digabungkan dan digunakan di suatu tempat di luar pekerjaan Anda sendiri
• PM dan EM bisa mengartikulasikan problem space Anda tanpa Anda ada di ruangan
• Anda memiliki jawaban satu kalimat untuk "apa yang sedang kamu kerjakan?" yang bukan nama fitur, melainkan sebuah masalah atau metrik

Jika Anda bisa mencapai kelima itu pada hari ke-90, Anda bukan lagi desainer baru. Anda adalah desainer yang memiliki problem space, sudah merilis, dan memiliki rencana. Itulah posisi yang Anda negosiasikan dari bulan keempat. Itulah kisah yang diceritakan manajer Anda dalam pemeriksaan kinerja H2 Anda.

Pola PM-sebagai-pelempar-spesifikasi tidak akan pergi. Itu hanya berhenti menjadi gravitasi yang memerangkap Anda. Anda memilih keluar, Anda memiliki bukti bahwa Anda bisa melakukan pekerjaan yang lebih sulit, dan 90 hari berikutnya adalah milik Anda untuk didefinisikan.

Pelajari Lebih Lanjut

• Job Description Desainer Produk
• Pekerjaan Discovery sebagai Desainer Produk
• Kepemilikan Ujung ke Ujung: Dari Masalah ke Rilis ke Pembelajaran
• Jebakan Umum Desainer Produk