Bahasa Indonesia

AI dalam Alur Kerja Manajer Produk: Di Mana Membantu, Di Mana Gagal

Setiap tool PM kini punya tombol "AI". Notion AI menyusun draf PRD Anda. Linear merangkum sprint Anda. Productboard mengekstrak tema dari feedback. Jira menulis kriteria penerimaan. Tombol itu ada di mana-mana, dan sebagian besar yang keluar darinya adalah output asal-asalan. Spec asal-asalan yang berhenti dibaca engineer pada minggu ketiga. Rangkuman riset asal-asalan yang meratakan satu kutipan aneh yang sebenarnya justru merupakan insight-nya. Prioritisasi asal-asalan yang dengan percaya diri memberi peringkat pada fitur yang tidak diminta siapa pun.

PM yang menyalin-tempel draf PRD dari Notion AI ke Jira adalah PM yang tim engineering-nya diam-diam berhenti membaca PRD. Saya pernah melihat ini terjadi pada tiga tim dalam setahun terakhir. Polanya identik: PM jadi lebih cepat, tim engineering jadi lebih diam, dan enam minggu kemudian seseorang merilis hal yang salah karena spec-nya ditulis oleh model yang belum pernah bertemu pelanggan.

Jadi inilah kerangka jujurnya. AI adalah alat pengungkit untuk bagian tengah alur kerja Anda yang membosankan. Ia bukan pengganti untuk dua hal yang sebenarnya menjadi tanggung jawab Anda: penilaian dan kebenaran pelanggan. Sisa artikel ini adalah pandangan seorang PM aktif tentang di mana AI memberi nilai, di mana ia sama sekali tidak membantu, pola alur kerja yang bertahan di bawah tekanan, dan rencana 30 hari untuk membangun keterampilan tersebut.

Di Mana AI Membantu (Gunakan Setiap Hari)

Bagian tengah yang membosankan itu nyata. Itulah 60% pekerjaan PM yang berupa sintesis mekanis, penyusunan draf, pemindaian, dan pemeriksaan pola. AI sangat baik dalam hal ini jika Anda menjaganya tetap dalam kendali ketat.

Sintesis transkrip wawancara. Ini adalah tempat memulai dengan ROI tertinggi. Ambil transkrip Gong atau Grain, tempel teks lengkapnya ke Claude (bukan rangkuman, melainkan teks lengkap), dan minta kutipan verbatim yang dikelompokkan berdasarkan tema spesifik. Struktur prompt yang berhasil: "Ekstrak kutipan verbatim tentang keberatan harga dari transkrip ini. Kelompokkan berdasarkan persona jika ada beberapa pembicara. Jangan parafrasekan. Jika seorang pembicara ragu-ragu, sertakan keraguannya." Kalimat terakhir itu penting karena model cenderung menghasilkan rangkuman yang percaya diri dan Anda kehilangan teksturnya.

Draf spec. Draf pertama dari user story, kasus tepi, kriteria penerimaan, dengan brief terstruktur yang Anda tulis sendiri. Brief itulah pekerjaannya. Drafnya hanya soal mengetik. Jika Anda memberinya pernyataan masalah Anda, asumsi model data Anda, dan tiga kasus tepi yang sudah Anda ketahui, ia akan menghasilkan kerangka yang bisa dipakai. Anda tetap akan menulis ulang separuhnya. Itu wajar. Anda menghemat separuh yang tidak Anda tulis ulang.

Pemindaian kompetitif. Masukkan delapan changelog kompetitor ke dalam sebuah model, minta perbandingan terhadap roadmap Anda. Tanyakan rilis mereka mana yang menyasar segmen pelanggan yang juga Anda layani. Ini adalah pekerjaan kasar yang dulu menghabiskan separuh hari Jumat. Sekarang ia hanya makan 20 menit dan sisa waktunya Anda gunakan untuk memutuskan apa yang harus dilakukan terhadapnya, yang merupakan pekerjaan sesungguhnya.

Salinan varian fake door. Membuat enam judul landing page untuk A/B test? Boleh. Membuat strategi di balik fake door mana yang akan dijalankan? Tidak boleh. Model itu baik di permukaan, buruk dalam pilihan. Gunakan untuk permukaannya.

Pemeriksaan kewarasan analisis cohort. Tempel tabel hasil SQL, tanyakan "apa yang hilang di sini, apa yang akan dibantah oleh seorang data scientist yang skeptis?" Anda tidak meminta analisis. Anda meminta sepasang mata kedua untuk memeriksa apakah cohort Anda terkontaminasi, jendela waktu Anda aneh, atau filter Anda mengecualikan populasi yang penting. Ia menangkap hal-hal bodoh. Itu sepadan.

Di Mana AI Gagal (Lakukan Ini Sendiri, Setiap Saat)

Inilah bagian yang dilewati sebagian besar artikel "AI untuk PM" karena tidak menjual tool. Tapi inilah bagian yang menentukan apakah Anda mempertahankan pekerjaan Anda dalam dua tahun.

Pembingkaian masalah. Satu kalimat yang menyatakan "apa yang sebenarnya kita selesaikan dan untuk siapa" adalah pekerjaan Anda. Selalu. Sebuah model akan menghasilkan pembingkaian yang terdengar fasih seperti setiap pembingkaian lain yang pernah dibacanya. Pembingkaian Anda harus spesifik terhadap pelanggan Anda, data Anda, momen Anda di pasar. Jika pembingkaian Anda terbaca seolah bisa berlaku untuk perusahaan mana pun di kategori Anda, berarti Anda telah mengalihdayakan kalimat terpenting dalam spec.

Bobot prioritisasi. Angka RICE dan ICE dari sebuah LLM hanyalah perkiraan kasar. Angka reach berasal dari percakapan nyata dengan tim marketing tentang segmen mana yang mereka sasar kuartal berikutnya. Angka effort berasal dari percakapan 10 menit dengan tech lead Anda. Angka confidence berasal dari berapa banyak pelanggan yang benar-benar Anda ajak bicara tentang hal ini. Tidak satu pun angka itu ada dalam data pelatihan sebuah model untuk roadmap spesifik Anda. Jika Anda membiarkan AI menghasilkan skornya, Anda telah mengotomatiskan bagian prioritisasi yang paling tidak bernilai (perhitungan) dan melewati bagian yang paling bernilai (percakapan trade-off yang menghasilkan masukan-masukan itu).

Kebenaran pelanggan. Jangan pernah membiarkan AI merangkum 12 wawancara menjadi 3 tema tanpa Anda membaca transkrip mentahnya. Model memampatkan ke arah median. Insight sesungguhnya hampir selalu adalah outlier: satu pelanggan yang mengatakan sesuatu yang tidak dikatakan orang lain, dengan cara yang membingkai ulang asumsi Anda. Pemampatan membunuh outlier. Bacalah transkripnya. Gunakan AI untuk mengekstrak kutipan, bukan untuk mengekstrak kesimpulan.

Keputusan penilaian soal pemangkasan ruang lingkup. Sebuah model bisa mendaftar setiap opsi untuk memangkas ruang lingkup menjelang tenggat. Ia tidak bisa menguasai ruangan ketika engineering lelah, design defensif, dan GM menginginkan komitmen awal. Itu bukan masalah prompt. Itu masalah "Anda harus benar-benar hadir di sana".

Pola Alur Kerja yang Benar-Benar Berhasil

Beberapa pola yang saya jalankan tiap minggu. Tidak ada yang pintar. Intinya justru pola itu membosankan dan dapat diulang.

Gong/Grain plus Claude untuk sintesis wawancara. Polanya persis: rekam panggilan (Gong jika itu discovery call yang menyertai penjualan, Grain jika murni riset). Ambil transkrip lengkap. Tempel ke percakapan Claude yang baru. Gunakan prompt ekstraksi yang ketat, bukan prompt rangkuman. Verifikasi dengan membaca transkrip asli untuk dua atau tiga kutipan teratas yang dimunculkan model. Jika model memparafrasekan apa pun yang material, buang outputnya dan beri prompt ulang dengan bahasa yang lebih ketat. Langkah verifikasi itulah pekerjaannya. Lewati langkah itu dan Anda akan mengutip pelanggan mengatakan sesuatu yang tidak mereka katakan, yang merupakan langkah penghancur karier dalam pemaparan kepada pemangku kepentingan.

Sebuah prompt yang memberi nilai, secara verbatim:

Anda sedang mengekstrak kutipan dari transkrip wawancara pelanggan. Saya akan menempel transkripnya di bawah ini. Tugas Anda: ambil setiap kutipan langsung di mana pembicara menyebut harga, anggaran, atau pengadaan. Jangan parafrasekan. Jangan rangkum. Pertahankan keraguan, jeda, dan kontradiksi pembicara secara persis. Kembalikan sebagai daftar berpoin dengan stempel waktu jika tersedia. Jika tidak ada kutipan yang relevan, katakan "tidak ada kutipan ditemukan", dan jangan mengarang.

Baris "jangan mengarang" itu penting. Tanpanya, model berhalusinasi menghasilkan kutipan yang terdengar masuk akal.

Cursor sebagai akselerator spec. Berguna hanya ketika tim engineering Anda juga menggunakannya. Cursor (atau tool AI-pair coding apa pun yang diadopsi tim) berarti engineer membaca spec Anda sambil menyusun kode di editor yang sama. Jika mereka menggunakannya dan Anda tidak, spec Anda menyimpang dari bagaimana kode itu sebenarnya ditulis. Jika tidak ada di antara Anda yang menggunakannya, baik, tulis spec dengan cara lama. Jebakannya adalah ketika PM menggunakannya sendirian dan menganggap tim engineering mengalami spec dengan cara yang sama seperti Anda. Tanyakan. Cocokkan dengan alur kerja mereka.

Jebakan "PRD yang ditulis AI". Engineer langsung mengenali PRD palsu. Tanda-tandanya: kasus tepi yang generik ("tangani kegagalan jaringan dengan baik"), kriteria penerimaan yang terdengar benar tetapi melewatkan model data sesungguhnya ("pengguna dapat menyimpan preferensi mereka"), dan ketiadaan yang mencurigakan dari kekhususan berantakan yang muncul dari benar-benar menggunakan produk itu. Uji baunya: jika Anda tidak bisa mempertahankan setiap baris spec dalam standup, hapus sebelum standup.

Daftar periksa uji bau PRD yang layak dijalankan sebelum Anda merilis dokumennya:

  • Bisakah saya menyebut nama pelanggan yang meminta ini, dan mengutip mereka?
  • Bisakah saya menggambar model data di papan tulis tanpa catatan?
  • Apakah kasus tepi saya merujuk pada keadaan error nyata kami, bukan yang generik?
  • Apakah saya mendaftar setidaknya satu hal yang secara eksplisit tidak kami bangun, dan alasannya?
  • Apakah tech lead saya akan membaca spec ini dan mempelajari sesuatu yang belum mereka ketahui?

Jika ada jawaban yang tidak, spec-nya terlalu tipis. AI tidak membantu Anda. Ia membantu Anda merilis draf yang tidak bisa Anda pertahankan.

Lensa ACE Framework (Opsional)

Jika Anda membaca cukup banyak deck strategi, Anda akan menemui ACE Framework: Ingest, Analyze, Predict, Generate, Execute. PM duduk paling dekat dengan Analyze dan Generate (sintesis dan penyusunan draf). Di situlah persisnya pengungkit dalam artikel ini berada. Ingest (perpipaan data, ETL, pipeline embedding) biasanya menjadi milik data engineering. Execute (otomatisasi alur kerja yang berjalan tanpa manusia dalam loop) biasanya menjadi milik ops atau platform.

Anda tidak perlu menghafal ini. Tapi layak untuk mengetahui kosakatanya karena begitu fitur AI mendarat di roadmap Anda, eng lead dan tim data Anda akan menggunakan kata-kata ini. Anda akan menghemat satu rapat jika sudah tahu kapabilitas mana yang Anda beli versus bangun.

Rencana 30 Hari Anda untuk Membangun Keterampilan

Empat minggu. Satu alur kerja dalam satu waktu. Tanpa penyebaran tool berlebihan. Intinya adalah membangun sekumpulan kecil langkah yang dapat diulang dan Anda percayai di bawah tekanan tenggat.

Minggu 1: Pilih satu alur kerja dan jalankan dua kali. Sintesis transkrip adalah tempat memulai dengan ROI tertinggi. Pilih satu wawancara pelanggan dari minggu ini. Sintesiskan secara manual terlebih dahulu. Baca transkripnya, tuliskan tiga hal yang mengejutkan Anda, daftar kutipan verbatim yang mendukungnya. Lalu jalankan transkrip yang sama melalui Claude dengan prompt ekstraksi. Bandingkan. Anda akan mempelajari dua hal: di mana model menambah kecepatan, dan apa yang diam-diam ia hilangkan. Keduanya penting.

Minggu 2: Tulis pustaka prompt Anda sendiri. Empat hingga enam prompt, terkontrol versi dalam dokumen bersama. Satu untuk ekstraksi transkrip. Satu untuk kerangka spec dari sebuah brief. Satu untuk pemindaian kompetitif. Satu untuk pemeriksaan kewarasan SQL. Mungkin satu untuk varian salinan fake door. Itu saja. Jika Anda punya lebih dari enam prompt, Anda mengumpulkan tool alih-alih menggunakannya. Setiap prompt harus punya format input yang jelas, format output yang jelas, dan catatan satu baris tentang apa yang perlu diverifikasi sebelum memercayai outputnya.

Minggu 3: Tunjukkan kepada satu rekan tim. Serahkan prompt Anda ke PM lain atau tech lead Anda. Minta mereka menggunakan salah satunya pada tugas nyata. Jika mereka tidak bisa mereplikasi output Anda tanpa Anda mendampingi, prompt-nya terlalu rapuh. Prompt yang rapuh adalah titik kegagalan tunggal. Pada hari Anda sakit, alur kerja Anda berhenti. Perketat prompt sampai bisa dialihkan.

Minggu 4: Audit. Dua kolom. Kolom kiri: apa yang AI hemat untuk Anda bulan ini (jam kerja, keputusan yang dipercepat, draf yang tidak perlu Anda ketik). Kolom kanan: apa biayanya bagi kepercayaan dengan engineering, dengan pelanggan, dengan penilaian Anda sendiri. Jujurlah. Jika sebuah prompt menghasilkan spec yang dibantah engineering, tulis itu. Jika sebuah sintesis melewatkan outlier yang Anda tangkap kemudian, tulis itu. Pangkas yang tidak layak. Pertahankan yang layak. Sekarang Anda punya alur kerja, bukan sekadar kira-kira.

Saya mencoba versi ini pada satu siklus discovery kuartal lalu. Minggu 1 saya curiga. Pada minggu 3 saya sudah memangkas waktu sintesis wawancara saya kira-kira setengahnya, tetapi nyaris saja merilis rangkuman tema yang belum saya verifikasi terhadap transkrip mentah. Audit minggu 4, prompt sintesis tetap bertahan. Prompt "rangkum 12 wawancara menjadi tema" dihapus. Itulah keterampilannya.

Argumen Penutup yang Tenang

PM yang akan menang dalam dua tahun ke depan bukanlah mereka yang paling banyak menggunakan AI. Bukan mereka dengan tumpukan tool terpanjang atau pustaka prompt paling banyak dibintangi di Notion. Mereka adalah yang tahu persis di mana AI berhenti bekerja dan melindungi bagian pekerjaan itu. Pembingkaian masalah. Bobot prioritisasi. Kebenaran pelanggan. Keputusan penilaian di bawah tekanan tenggat.

Selebihnya boleh dipakai. Gunakan tool-nya. Hemat waktunya. Tapi gunakan waktu yang Anda hemat untuk bagian pekerjaan yang tidak bisa dilakukan model: duduk bersama pelanggan sampai Anda benar-benar memahami apa yang mereka katakan, memperjuangkan pemangkasan ruang lingkup yang tepat di dalam ruangan, menulis satu kalimat di puncak spec yang membuat 12 minggu berikutnya bagi tim menjadi koheren.

Itulah pekerjaannya. AI adalah pengungkit, bukan pengganti.

Pelajari Lebih Lanjut