Saya punya dua buku yang membentuk cara saya berpikir soal produk: Inspired, dari Marty Cagan, dan Gestão de Produtos, dari Joca Torres, yang bahkan pernah menjadi mentor saya. Selama bertahun-tahun keduanya adalah peta saya: apa itu PM, apa itu product designer, apa itu engineer, siapa mengerjakan apa. Tiap peran dengan garis yang jelas.
Setahun terakhir, melihat tim saya bekerja dengan AI di Prolog, saya mulai merasakan garis-garis itu menggeser. Bukan berarti buku-bukunya menjadi salah: lapisan tempat setiap peran terjadi yang naik.
Di tulisan pertama seri ini saya menceritakan rasa tidak nyaman yang membuat saya mulai membangun ulang tech di Prolog, dan di tulisan kedua, apa itu harness, infrastruktur yang membuat AI benar-benar bekerja. Di akhir tulisan pertama saya berjanji membuka satu bagian spesifik: bagaimana pekerjaan setiap posisi berubah ketika AI yang menjadi pembangun. Itulah topiknya di sini.
Pekerjaan tidak hilang, ia naik satu lapisan
AI tidak menghapus peran setiap profesi, ia mengubah lapisan tempat peran itu terjadi.
Bacaan yang mudah, yang menjual rasa takut, adalah “AI akan menggantikan posisi X”, dan bukan itu yang saya lihat terjadi. Yang saya lihat adalah isi pekerjaan berpindah tempat: yang tadinya mengerjakan menjadi mengarahkan dan mengkritik yang mengerjakan.
Engineer, yang menulis kode, sekarang meninjau apa yang ditulis agent. PM, yang menulis spec, sekarang menilai prototipe yang keluar darinya dalam hitungan jam. Orangnya sama, alat di tangannya yang berubah.
Ketika saya kembali ke Cagan dan Joca dengan itu di kepala, semuanya jatuh pada tempatnya dengan cara berbeda. Keduanya mendeskripsikan, dengan hati-hati, eksekusi setiap peran (tugas konkret, deliverable, apa yang keluar dari tangan Anda di penghujung hari), dan itulah persis yang sedang diambil alih AI. Yang tersisa untuk manusia adalah separuh lainnya: memutuskan apa yang layak dibangun, menemukan lubang di apa yang sudah dibangun, punya taste untuk tahu apa yang bagus. Judgment, bukan eksekusi.
Jadi saya akan melakukan apa yang saya lakukan pada diri saya sendiri: ambil definisi tiap peran dari buku-buku itu, lalu tanya bagian mana yang dimakan AI dan bagian mana yang tersisa (dan jadi lebih mahal).
Tim bertiga, menurut buku-buku itu
Sebelum memisahkan peran satu per satu, ada baiknya mengingat bagaimana buku-buku itu menyusun tim. Joca lugas: sebuah produk yang sukses harus diinginkan, layak, dan mungkin dibangun, dan itu mendefinisikan “tiga fungsi esensial untuk menciptakan produk yang sukses” (bab 2): UX designer, product management, dan developer, trio yang ia sebut core team. Cagan, di Inspired, mendeskripsikan peran yang sama di bab pembuka, “Key Roles and Responsibilities”.
Keduanya menekankan satu poin yang akan saya angkat lagi di akhir: ini bukan hubungan atasan dan bawahan. Dalam kata-kata Joca, “product engineering, product management, dan UX adalah satu tim, tidak ada hubungan subordinasi di antara kelompok-kelompok ini” (bab 31), dan pada Cagan gagasan yang sama muncul sebagai PM dan engineering sebagai “rekan sejajar, tidak ada posisi yang berada di bawah yang lain” (bab 5, terjemahan saya). Dan ketika AI masuk ke tengah trio itu, kemitraan inilah yang paling banyak berubah bentuk.
Tabel: setiap profesi di tech naik satu lapisan. Engineering dari produsen kode jadi kritikus agent; produk, dari penulis spec jadi arsitek iterasi; desain, dari produsen layar jadi konduktor eksperimen; kualitas, dari penguji jadi pembangun validasi.
Peran setiap profesi di tech
Peran yang sama, satu lapisan di atas
eksekusi jadi milik agent · judgment tetap milik Anda: memutuskan, mengkritik, punya taste
Engineer: dari produsen kode menjadi kritikus agent
Untuk engineering, yang penting berhenti menjadi seberapa banyak kode yang Anda produksi: menjadi seberapa baik Anda mengkritik apa yang diproduksi agent.
Definisi Joca begitu jelas sampai perih membacanya sekarang: “product engineering bertanggung jawab mengembangkan produk dan menjaganya tetap beroperasi”, dan, sedikit lebih jauh, engineering “membangun produk” (bab 31). Membangun adalah kata kerjanya. Cagan melengkapinya dari sisi lain, bicara soal hubungan dengan produk: “product manager bertanggung jawab mendefinisikan solusi, tapi tim engineering paling tahu apa yang mungkin, dan merekalah yang pada akhirnya mengantarkan solusi itu” (bab 5, terjemahan saya). Mendefinisikan di satu sisi, mengantarkan di sisi lain.
Sekarang pengantaran versi pertama adalah milik agent. Yang tidak berubah, dan jadi lebih mahal, adalah semua yang Cagan lekatkan pada engineer sebagai sumber inovasi: “engineer lebih tahu dari siapa pun apa yang mungkin” (bab 5). Tahu apa yang mungkin, menemukan lubang di rencana yang diusulkan agent, melihat trade-off performa atau keamanan yang tidak ia lihat, memutuskan kapan turun tangan dan kapan membiarkannya berjalan. Ini makin berat bobotnya tiap bulan. Hafalan sintaks, boilerplate ditulis tangan, menyisir Stack Overflow, volume kode sebagai piala pribadi: itu makin ringan bobotnya.
Di Prolog saya bilang ini terang-terangan ke tim: tidak ada yang akan dinilai dari baris kode. Yang selalu jago “mencari lubang” jadi lebih bernilai, dan yang mengidentikkan diri dengan “memproduksi banyak kode dengan cepat” harus mengkalibrasi ulang ke mana ia berinvestasi. Dan ini tidak mengecilkan engineering. Nilainya selalu lebih pada tahu apa yang layak ketimbang memproduksi cepat, dan sekarang itu hanya jadi eksplisit.
PM: dari penulis spec menjadi arsitek iterasi
PM merasakannya ketika prototipe jadi murah: pekerjaannya berhenti menjadi menulis dokumen dan menjadi memilih ide mana yang layak mendapat waktu tim.
Cagan tegas soal inti pekerjaan: “seseorang harus menemukan apa solusinya, produknya, termasuk fitur-fiturnya, pengalaman pengguna, dan kriteria peluncuran. Orang itu adalah product manager, dan tugas itu adalah inti dari pekerjaannya” (bab 1, terjemahan saya). Joca memberi garis besarnya yang lebar: product management adalah “fungsi yang bertanggung jawab atas seluruh aspek sebuah produk software, sepanjang siklus hidup produk itu, dari konsepsi hingga akhir hidupnya” (bab 2).
Perhatikan bahwa pada keduanya kata kuncinya adalah menemukan, bukan menspesifikasikan. Cagan punya satu bab penuh hanya untuk membela bahwa pekerjaannya adalah discovery, bukan “requirements”: software punya dua tahap, “menemukan apa yang dibangun (produk yang benar) dan membangun (produk dengan cara yang benar). Yang pertama didominasi discovery, yang kedua adalah eksekusi” (bab 12, terjemahan saya). Itu selalu pesannya, dan AI hanya membuatnya harfiah.
Karena ketika build runtuh dari minggu ke jam, bottleneck berhenti menjadi membangun dan menjadi memutuskan apa yang layak dibangun. Spec panjang yang ditinjau komite, planning kuartalan yang tertutup, status report sebagai deliverable, kontrol lalu lintas antara engineering dan design: semua itu makin ringan bobotnya. Yang makin berat adalah discovery cepat (prototyping untuk memahami, bukan menspesifikasikan untuk membangun), kurasi hipotesis (ide mana yang layak mendapat waktu tim), dan memutuskan apa yang tidak dikerjakan, lebih sering. Beberapa perusahaan sudah menyebut PM ini “Editor” atau “Arsitek”. Ini bukan lebih sedikit PM: ini PM yang lain, yang mengurasi, yang memutuskan dengan taste, yang memberi arah. Yang tadinya sentral di peran lama, menulis spec, itulah yang jadi ringan.
Product designer: dari produsen layar menjadi konduktor eksperimen
Di design, unit kerja beranjak dari layar dan pindah ke sistem yang memproduksi layar, dan product designer beralih memilih variasi mana yang bertahan.
Pada Joca, definisi UX adalah memahami untuk mendesain: “UX bertanggung jawab memahami secara mendalam pengguna dan masalah yang ingin dipecahkan untuk pengguna itu” (bab 32). Dan alur yang ia deskripsikan adalah ritual yang semua orang tahu: prototipe kertas, lalu wireframe, lalu “visual designer UX mulai memberi warna dan bentuk pada layar-layar itu”. Cagan memotong peran itu jadi dua dengan logika yang sama: interaction designer “mengembangkan pemahaman mendalam tentang pengguna dan menciptakan task, navigasi, dan alur”, memetakannya ke wireframe dan mengoperkannya ke visual designer, yang “memberi daging pada wireframe” (bab 4, terjemahan saya).
Rangkaian ini, memahami, membuat sketsa, memperhalus layar demi layar, justru itulah yang dipangkas AI. Unit kerja berhenti menjadi “layar” dan menjadi “sistem yang menghasilkan layar”. Mengulang variasi yang sama lima kali di Figma, menspesifikasikan komponen demi komponen, handoff pixel-perfect sebagai ritus: makin ringan bobotnya. Prototyping dengan kecepatan iterasi (beberapa opsi paralel, buang yang jelek), mendefinisikan sistem visual alih-alih tiap layar terpisah, dan kritik visual cepat (melihat AI mengusulkan sesuatu dan langsung sadar itu salah sebelum pengguna sadar): makin berat bobotnya.
Dan di sini Cagan bilang, jauh di 2008, sesuatu yang melindungi product designer dari mengira dirinya jadi penekan tombol: pekerjaannya tidak pernah cuma menggambar bagus. “Produk yang bagus butuh pengalaman pengguna yang bagus. Dan pengalaman yang bagus butuh kolaborasi erat antara produk dan design” (bab 4, terjemahan saya). AI menghasilkan variasinya, dan yang memutuskan variasi mana yang layak sampai ke pengguna tetaplah manusia dengan taste.
QA: dari penguji menjadi pembangun validasi
QA adalah kasus yang paling menarik, karena ini peran yang nyaris tidak diisolasi buku-buku itu, dan ini yang paling banyak diubah AI.
Perhatikan: di trio Joca (designer, PM, developer) dan di peran-peran Cagan, kualitas muncul terlarut, sebagai tanggung jawab tim, bukan sebagai kursi tersendiri dengan metodenya sendiri. Untuk waktu yang lama itu masuk akal, tapi sekarang tidak lagi, dan alasannya sederhana: kalau agent membangun cepat dan validasi tetap manual, Anda cuma memproduksi utang teknis dengan kecepatan tinggi.
Maka QA berhenti menjadi orang yang menjalankan test case dengan tangan dan menjadi orang yang merancang testing harness, sistem yang menguji sistem: mengonfigurasi AI untuk menulis test bagi kode yang ditulis AI lain, mendeteksi regresi sebelum pengguna, memikirkan di mana cacat cenderung muncul. Dalam praktik, ia menjadi pertanyaan operasional yang kami adopsi: tiap bug yang lolos menjadi “bagaimana kami mendeteksi ini secara otomatis lain kali?”. Test manual yang melelahkan atas alur yang sudah dikenal, regresi dijalankan dengan tangan tiap rilis, QA sebagai satu-satunya gerbang sebelum naik: makin ringan bobotnya. Validasi sebagai sistem, bukan sebagai operan di ujung ban berjalan.
Ini peran yang paling naik lapisan justru karena ia yang paling tidak terdefinisi. Di tempat buku-buku itu tidak mengukir garis, AI sedang menggambar yang baru.
Konstantanya: apa yang buku-buku itu sudah bilang paling penting
Ada satu hal yang tidak berubah, dan ia bersembunyi di depan mata di kedua buku: apa yang mereka tempatkan sebagai karakteristik paling penting justru itulah yang tidak dilakukan AI.
Joca membuka bab tentang karakteristik PM yang baik tanpa berputar-putar: “yang paling penting dari semuanya, tanpa ragu, adalah empati” (bab 4). Ini bukan tabel fungsi atau deliverable: ini kemampuan menempatkan diri di posisi orang yang memakai. Cagan, di sisinya, menghabiskan seluruh buku membela discovery, taste, dan judgment di atas proses, dan keduanya, masing-masing dengan caranya, mengatakan hal yang sama: yang memisahkan yang bagus dari yang biasa tidak pernah bagian mekanis dari pekerjaan.
Dan bagian mekanis justru itulah yang pergi ke agent. Menulis spec, mendesain layar, menulis kode, menjalankan test. Yang tersisa, dan jadi lebih mahal, adalah sikap kritis, taste (tahu apa yang bagus), judgment di bawah ambiguitas, keingintahuan, kepedulian pada orang yang memakai apa yang Anda buat. Meringkasnya dalam kalimat yang saya pakai dengan tim: isi pekerjaan berubah, orang yang mengerjakan, tidak.
Diagram dua lapisan. Di atas, yang tetap milik kita dan jadi lebih mahal: taste (tahu apa yang bagus), judgment dalam ambiguitas, empati dengan yang memakainya, memutuskan apa yang tidak dikerjakan, apa yang buku-buku itu sudah bilang paling penting. Pekerjaan naik satu lapisan. Di bawah, yang pergi ke agent: menulis spec, mendesain layar, menulis kode, menjalankan test manual.
Tetap milik kita · dan jadi lebih mahal
apa yang buku-buku itu sudah bilang paling penting
pekerjaan naik satu lapisan
Pergi ke agent
Apa yang ini akan tagih (tanpa klise)
Saya tidak mau menutup ini terlalu rapi, karena memang tidak. Perubahan ini menagih hal-hal konkret, dan tidak ada satu pun yang nyaman.
Yang pertama adalah meninggalkan kebiasaan satu dekade. Yang sudah lima, sepuluh tahun di cara lama membawa pola-pola yang membantunya sampai di sini, dan justru pola-pola itulah yang memberatkan untuk berubah. Tidak ada jalan pintas, dan rasa tidak nyaman itu wajar.
Lalu, mengkritik AI sebanyak menciptakan dengannya: menerima saran yang muncul bukan pekerjaan; menemukan lubang di rencana yang ia usulkan, itu pekerjaan. Yang selalu mahal (pemikiran kritis, taste, judgment) jadi lebih mahal.
Ada juga salah sebagai tim, bukan sebagai individu. Kami tidak memecat engineer karena bug di produksi, kami memperbaiki review, dan ketika AI salah, harness-lah yang kami perkuat. Bug agent itu proses, bukan orang: sebuah komitmen, bukan slogan.
Dan yang paling tidak nyaman: menerima bahwa sebagian fungsi berubah lebih banyak dari yang lain. Ini menimbulkan ketidaknyamanan bagi yang selama ini berubah sedikit, dan tidak bisa berpura-pura semuanya sama. Yang bisa dilakukan adalah membawanya ke percakapan terbuka.
Dan supaya tidak terdengar seperti orang yang sudah sampai tujuan: Prolog masih awal dalam hal ini. Kami masih AI-assisted, dengan gain 10 sampai 20%, bukan AI-first 5x atau 10x. Saya sedang menceritakan sebuah arah yang kami bangun, dengan benar dan dengan salah, bukan sebuah kemenangan.
Apa yang saya bawa dari ini
Buku-buku itu tidak menjadi salah. Mereka mendeskripsikan eksekusi setiap peran dengan presisi yang baru benar-benar saya pahami sekarang (menulis spec, mendesain layar, membangun produk, menjalankan test), dan eksekusi itu sekarang milik agent. Dan yang tersisa untuk manusia adalah bagian yang lain, menilai, mengkritik, punya taste, peduli pada yang memakai, yang, kembali ke Cagan dan Joca, adalah apa yang mereka bilang paling penting sejak halaman pertama.
Mungkin itulah bagian bagusnya: pekerjaan yang diambil AI dari tangan kita adalah yang paling repetitif, dan yang ia tinggalkan adalah yang selalu paling sulit, dan paling menarik. Saya akan terus menceritakan bagaimana jalannya.
Sumber
- Marty Cagan, Inspired: How to Create Products Customers Love (edisi ke-1, 2008). Definisi peran berasal dari bab 1 (Key Roles and Responsibilities), 4 (Product Management vs. Design), 5 (Product Management vs. Engineering), dan 12 (Product Discovery). Terjemahan kutipannya milik saya.
- Joca Torres, Gestão de produtos: Como aumentar as chances de sucesso do seu software (Casa do Código). Definisinya berasal dari bab 2 (Apa itu manajemen produk software?), 4 (Karakteristik utama seorang product manager), 31 (Product engineering dan product management), dan 32 (UX dan product management).
- Bacaan tentang peran yang naik satu lapisan menopang seri ini: OpenAI, Harness Engineering, dan Peter Pang, CTO CREAO.