An essay for whoever takes this seat next
“Pekerjaan terbaik seorang PM bukan mengatur orang — tapi membuat mereka tidak perlu diatur.”
Tulisan ini bukan tutorial. Kalau kamu butuh teori Agile atau Scrum, buka saja PMI Knowledge Library atau Atlassian Agile Coach — jauh lebih lengkap. Ini cuma catatan pribadi. Hal-hal yang saya pelajari dari mengoordinasikan tim, melihat proyek melenceng, memperbaiki rencana yang kelewat optimis, dan kadang-kadang menyelamatkan situasi tepat sebelum semuanya keburu hancur.
Kenapa sekarang? Karena semuanya bergerak lebih cepat dari yang saya kira. Di Emveep, saya lihat sendiri — dulu bikin MVP klien butuh 6 minggu, tim 4 orang. Sekarang satu engineer pakai Claude Code, Codex, atau Lovable bisa kelar versi awalnya dalam satu akhir pekan. Pertanyaannya bergeser: bukan lagi "bagaimana cara membangun ini?" tapi "apakah ini memang layak dibangun, untuk siapa, dan apa risikonya kalau kita salah baca?"
Di situlah PM masih punya tempat. Bukan sebagai pencatat task — Trello, Notion, Jira, AI agent sudah bisa handle itu. Tapi karena seseorang tetap harus pegang konteks: konteks bisnis, pengguna, tim, waktu, dan politik kecil yang tidak pernah tertulis di dokumen mana pun. Hal-hal begitu tidak masuk prompt. Padahal di sanalah keputusan yang paling penting dibuat.
Yang kamu baca ini bukan kebenaran mutlak. Cuma hal-hal yang saya harap ada orang bilang ke saya lebih awal. Ambil yang berguna, tinggalkan sisanya. Pada akhirnya kamu tetap harus cari jalanmu sendiri.
Setiap Gantt chart yang saya buat di awal karier ternyata fiksi. Bukan karena timnya buruk — tapi karena saya kira planning itu soal memprediksi waktu. Padahal sebenarnya soal memetakan ketidakpastian.
Yang paling mahal saya pelajari: jadwal proyek itu bukan kontrak dengan kenyataan. Itu hipotesis. Setiap deadline yang kamu tulis sebenarnya penuh asumsi tersembunyi — dependency bakal selesai tepat waktu, requirement tidak berubah, orangnya tidak sakit, scope creep tidak terjadi. Hofstadter's Law mengatakannya paling baik: "It always takes longer than you expect, even when you take into account Hofstadter's Law."
Jadi sekarang saya melakukan dua hal yang berbeda dari kebanyakan PM:
Setiap milestone diikat dengan asumsi yang harus benar. Kalau asumsinya berubah, jadwalnya otomatis berubah. Ini bukan ide saya — saya pinjam dari framework BCG tentang Discovery-Driven Planning dan konsep assumption mapping yang juga dibahas di Strategyzer.
Stakeholder boleh tahu perkiraan, tapi yang mengikat cuma komitmen. Perkiraan itu pekerjaan kamu — komitmen itu janji. Banyak konflik PM-stakeholder muncul gara-gara dua hal ini dicampur jadi satu.
Risk register paling efektif yang saya temukan bukan tabel di Confluence yang tidak pernah di-update. Tapi 5 menit di awal setiap weekly: "Apa yang bikin kamu khawatir minggu ini?" Cuma itu. Jawaban tim selalu lebih jujur daripada apa pun yang ditulis di dokumen formal. Soal kenapa ini bekerja, baca riset psychological safety dari Amy Edmondson di Harvard dan studi Project Aristotle Google.
Pelajaran mahal lainnya: mengelola stakeholder itu bukan keterampilan komunikasi — itu keterampilan politik. Dan saya tidak bermaksud negatif. Setiap stakeholder punya KPI sendiri, tekanan dari atasannya sendiri, dan ketakutannya sendiri. Tugas kamu: pahami semua itu sebelum kamu perlu minta sesuatu dari mereka. Stakeholder Analysis dari MindTools titik awal yang oke, dan artikel HBR soal influence management melengkapi sisanya.
Bukan opini. World Economic Forum Future of Jobs Report 2025 menaruh AI literacy di posisi kedua skill paling dicari. Datanya sudah jelas.
Dulu saya skeptis. Saya pikir AI cuma bisa bikin ringkasan rapat yang dangkal dan email yang kedengarannya palsu. Ternyata yang salah bukan AI-nya — saya yang salah pakai. Saya perlakukan AI seperti asisten yang disuruh-suruh. Begitu saya ubah jadi thinking partner yang menantang asumsi saya, hasilnya beda jauh.
Istilah "prompt engineering" sudah mulai usang. Yang lebih penting sekarang: context engineering — gimana caranya kasih AI konteks yang cukup supaya dia bisa berpikir bareng kamu, bukan cuma menjawab. Anthropic dan Latent Space sudah menulis soal ini dengan baik.
Contoh kecil: saya tidak pernah lagi ketik "buatkan saya project plan". Saya tulis dulu konteksnya 5–10 menit — siapa stakeholder-nya, batasannya apa, sejarah masalahnya gimana, gaya komunikasi timnya seperti apa. Baru minta bantuan. Hasilnya beda jauh.
Daftar lengkap ada di bagian Stack. Tapi prinsipnya: pilih 3–4 tools, pakai dalam-dalam. Bukan koleksi. a16z juga bilang hal yang sama soal ekonomi GenAI — nilainya ada di kedalaman penggunaan.
Dua tahun lalu semua ribut soal chat. Tahun lalu soal tools. Sekarang yang dominan: agents — AI yang bukan cuma menjawab, tapi mengeksekusi. Dan itu mengubah definisi "tim" yang kamu kelola.
Beberapa bulan lalu saya coba men-deploy agen otonom di VPS berbayar — Openclaw — untuk workflow competitive intelligence yang biasanya makan waktu 3 hari analis junior. Agen ini jalan 24/7: menelusuri sumber, kirim ringkasan harian ke WhatsApp saya, eksekusi task ringan. Hasil pertama keluar dalam 40 menit, kualitasnya setara. Tapi tetap — saya harus review, arahkan ulang, dan putuskan. Agen menggantikan eksekusi, bukan penilaian.
Definisi yang saya pakai dari "Building Effective Agents" oleh Anthropic: agen adalah sistem di mana LLM secara dinamis mengarahkan proses dan penggunaan toolnya sendiri. Bedanya dengan workflow biasa: agen memutuskan sendiri langkah selanjutnya, bukan mengikuti alur yang sudah di-hardcode.
Lucunya, prinsip mengelola agen ternyata mirip banget dengan onboarding anggota tim baru:
Kalau baru mulai, ada dua jalur. Pilih tergantung seberapa besar kamu peduli soal kontrol data:
Jalur 1 — Managed (cepat mulai, tapi data di server orang lain):
Jalur 2 — Self-hosted (data di tangan kamu, perlu sedikit setup):
Saya sendiri pakai kombinasi keduanya. Managed untuk workflow yang melibatkan service luar (Notion, email klien). Self-hosted untuk yang sensitif atau yang saya mau kontrol penuh.
Tools seperti Lovable, Claude Code, dan Codex sudah mengubah ekonomi pembuatan MVP. Yang dulu butuh 2 sprint sekarang bisa selesai 2 hari. Kalau kamu masih mengukur produktivitas dari velocity story points, kamu mengukur hal yang salah.
Saya baru percaya setelah lihat sendiri: engineer di tim Emveep bangun fitur internal lengkap — frontend, auth, database — dalam satu malam pakai Lovable. Bukan prototype. Functional MVP. Kerjaan yang dulu butuh 3 orang selama sebulan.
Discovery jadi lebih penting dari delivery. Kalau membangun jadi murah, pertanyaan yang paling mahal adalah "haruskah kita bangun ini sama sekali?" Marty Cagan dan Teresa Torres sudah lama bilang ini — sekarang argumennya makin sulit dibantah.
PM harus bisa bikin prototype sendiri. Bukan untuk menggantikan engineer — tapi supaya kamu bisa:
Definisi "ready" berubah total. Karena MVP jadi murah, saya menyaring lebih ketat di depan. Mending batalkan 3 ide buruk lewat AI prototype dalam seminggu daripada bangun 1 ide buruk selama sebulan pakai tim penuh. Andrew Chen di The Cold Start Problem juga bicara soal pentingnya ini di tahap awal.
Saya lihat banyak PM yang kelewat semangat terus langsung pakai output AI tools untuk produksi tanpa review teknis. Itu berbahaya. Untuk prototype dan validasi — silakan. Tapi untuk produksi customer-facing, kamu tetap butuh engineer yang review keamanan, skalabilitas, dan maintainability. Guillermo Rauch (founder Vercel) juga menulis soal ini.
Bab-bab sebelumnya banyak bicara soal tools. Tapi kalau dipikir-pikir, kemampuan PM yang paling penting justru yang paling susah didelegasikan ke AI. Membaca ruangan. Bangun kepercayaan. Tahu kapan harus diam.
Engineer senior yang biasanya vokal tiba-tiba diam di meeting — itu sinyal. Designer merespons ide kamu dengan "menarik" — itu sinyal. Stakeholder cuma balas email dengan "Noted." — itu sinyal. PM yang baik menangkap semua ini real-time. AI tidak bisa. HBR menyebutnya contextual intelligence.
Saya butuh waktu bertahun-tahun untuk belajar memberi feedback dengan baik. Dua framework yang paling membantu:
Dua engineer debat soal arsitektur? Itu bukan drama. Itu informasi tentang trade-off teknis yang sedang dipertaruhkan. Tugas PM bukan meredam konflik, tapi memastikan konfliknya soal ide, bukan soal orang. "Five Dysfunctions of a Team" dari Patrick Lencioni framework yang paling berguna untuk ini.
Nasihat paling tidak berguna yang pernah saya terima: "rencanakan jenjang kamu 5 tahun ke depan." Dunia bergerak terlalu cepat untuk itu. Yang saya pelajari justru kebalikannya: jangan optimasi untuk posisi — optimasi untuk kemampuan dan jangkauan.
Saya mencuri framework ini dari Henrik Karlsson dan menyesuaikan untuk PM:
Saya menyesal tidak mulai menulis lebih awal. PM-PM yang saya kagumi punya satu kesamaan: mereka semua punya output publik — tulisan, podcast, atau karya. Bukan untuk jadi influencer, tapi untuk kejelasan berpikir. Paul Graham menjelaskan alasannya lebih baik dari saya.
Setiap kuartal saya menulis ulang jawaban untuk 4 pertanyaan ini. Mereka membantu saya tetap jujur:
Industri tech suka sekali narasi "10x harder, 10x faster". Saya pernah hidup begitu. Saya juga pernah burnout karenanya. Yang akhirnya saya sadari: karier panjang dibangun dari keberlanjutan, bukan intensitas. Cal Newport di "Slow Productivity" menulis soal ini dengan baik. Tidak semua hal harus dikerjakan sekarang. Tidak semua kesempatan harus diambil.
Reasoning panjang, analisis dokumen, drafting komunikasi sensitif, dan deep research. Context window besar membuat analisis lintas dokumen tetap menjaga nuansa.
Saya pakai sebagai second opinion. Ketika satu model setuju, oke. Ketika dua model setuju di sudut yang berbeda — saya lebih percaya keputusan saya.
Visual kanban yang sudah teruji. Untuk proyek klien dan tim yang butuh lihat status dengan cepat tanpa belajar tool baru. Simpel, jelas, langsung jalan.
Single source of truth untuk semua dokumentasi proyek. PRD, retrospective, knowledge base klien, hingga personal SOP — semua di satu tempat.
Untuk validasi konsep klien dalam hitungan jam, bukan minggu. Sebagai PM di software house, ini mengubah cara saya melakukan scoping — saya bisa menunjukkan demo, bukan mockup.
Agen AI otonom self-hosted yang bisa mengeksekusi aksi nyata — bukan sekadar chatbot. Berjalan di mesin sendiri, terintegrasi dengan WhatsApp/Discord, dan punya akses ke tools seperti browsing, email, dan kalender. Inilah yang membuat "agen" bukan hanya konsep.
Kombinasi yang saya pakai untuk competitive intelligence. Claude untuk reasoning & sintesis mendalam, Openclaw sebagai agen yang menelusuri internet real-time, memonitor sumber, dan mengirim hasilnya langsung ke WhatsApp saya.
Untuk PM software house, kemampuan membaca dan mendiskusikan kode bukan opsional. Dua tools ini membantu saya tetap relevan dalam diskusi teknis dengan tim engineering.
Transcription + action items otomatis untuk setiap meeting klien dan internal. Saya tidak perlu sibuk mencatat — saya bisa hadir dan benar-benar mendengarkan.
Teori yang tidak diuji adalah opini. Berikut beberapa proyek yang saya tangani — masing-masing mengajari saya pelajaran yang berbeda. Beberapa berhasil. Beberapa hampir gagal. Semua mengubah cara saya berpikir.
Catatan: Sebagian besar proyek di atas berada di bawah NDA, jadi nama klien dan detail teknis spesifik tidak bisa saya bagikan secara publik. Tapi pelajarannya — itu yang ingin saya wariskan. Untuk diskusi lebih mendalam tentang salah satu proyek di atas, silakan hubungi saya langsung.
Tools bisa diganti besok. Konteks bisnis, pengguna, dan tim yang kamu bangun — itu yang tahan lama.
PM yang baik bertanya 5x lebih banyak daripada memberi pernyataan. Pertanyaan membuka jalan, pernyataan menutupnya.
Versi 1 yang dikirim mengalahkan versi sempurna yang tidak pernah ada. Selalu.
Kalau proyek bergantung pada satu orang menjadi pahlawan, sistemnya rusak. Bangun proses, bukan ketergantungan.
Tulisan memaksa kejelasan. Pikiran yang tidak bisa ditulis biasanya pikiran yang tidak jelas.
Sebagian besar PM tidak punya otoritas formal. Kekuatan datang dari kredibilitas. Bangun pelan-pelan. Sekali rusak, hampir tidak bisa diperbaiki.
Saya tidak tahu siapa yang akan baca ini. Mungkin kamu baru mulai jadi PM. Mungkin sudah lama tapi sedang bertanya-tanya soal arah. Yang pasti, tantangan kamu akan beda dari punya saya.
Tools bakal berubah. Tim juga. Stakeholder datang dan pergi. Bahkan definisi "project manager" mungkin kedengarannya aneh lima tahun dari sekarang.
Yang saya tinggalkan bukan peta. Ini cuma kompas.
Bab-bab di atas adalah cara saya membaca dunia kerja per Mei 2026. Sebagian mungkin tetap relevan. Sebagian lagi mungkin sudah basi sebelum kamu selesai membaca.
Terserah kamu mau ambil yang mana dan tinggalkan yang mana.
Tapi kalau ada satu hal yang saya percaya tidak akan cepat usang: orang-orang di sekitarmu.
Engineer yang stuck di bug Jumat malam. Designer yang diam-diam tidak yakin dengan hasilnya. Stakeholder yang takut terlihat gagal di depan atasan. Junior yang sebenarnya butuh arahan, tapi terlalu takut bertanya.
Mereka semua butuh seseorang yang melihat mereka.
Yang bikin mereka aman untuk bicara jujur. Yang bantu mereka lihat prioritas. Yang cukup peduli untuk bertanya — bukan cuma menagih.
Itu pekerjaan kita yang sesungguhnya.
AI tidak mengambil bagian itu. Malah sebaliknya — kalau dipakai dengan benar, AI membebaskan waktu kita untuk melakukannya lebih baik.
Pergilah membuat sesuatu yang baik.
Pergilah merawat orang-orangmu.
Dan semoga kamu menjadi PM yang lebih baik daripada saya.