The Things I Wish Someone Told Me & Wish I Knew Sooner.

Planning bukan tentang jadwal. Tentang asumsi.

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:

Saya membuat asumsi eksplisit, bukan jadwal

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.

Saya selalu memisahkan komitmen dari perkiraan

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 itu bukan dokumen — tapi kebiasaan

Risk register paling efektif yang pernah saya punya cuma 5 menit di awal setiap weekly: “Apa yang bikin kamu khawatir minggu ini?” Tabel di Confluence yang tidak pernah di-update kalah jauh. 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.

Stakeholder mapping dilakukan sebelum kamu butuh

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.

AI tools tidak menggantikanmu. Tapi PM yang tidak pakai AI akan tergantikan.

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.

Pergeseran mental: dari prompt ke konteks

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.

Empat tempat AI mengubah pekerjaan harian saya

• Synthesis rapat & dokumen — Claude buat merangkum 1 jam rapat jadi action items, open questions, dan decision log. Bukan transkrip — tapi ringkasan yang bisa langsung ditindaklanjuti. Microsoft Work Trend Index bilang rata-rata pekerja hemat 30 menit per hari dari ini saja.
• Stakeholder communication — Nulis email ke stakeholder itu susah, apalagi kalau lagi frustrasi. AI bantu saya atur ulang nada tanpa kehilangan substansi. Menurut survey HBR, komunikasi memang use case nomor satu.
• Risk & pre-mortem analysis — Saya suruh AI jadi “PM senior yang skeptis” dan kritik rencana saya. Teknik pre-mortem dari Gary Klein jadi jauh lebih tajam kalau ada sparring partner yang tidak capek.
• Knowledge retrieval — Notion AI dan Atlassian Intelligence bisa cari konteks lintas dokumen. “Keputusan kita soal X tiga bulan lalu apa?” — jawaban dalam hitungan detik.

Tools yang saya pakai aktif setiap hari

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.

Tahun 2026 adalah tahun agen. Tapi mereka butuh PM.

Dua tahun lalu semua ribut soal chat, tahun lalu soal tools. Sekarang gilirannya agents: AI yang mengeksekusi, bukan cuma menjawab. Buat PM, ini mengubah apa yang disebut “tim”.

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.

Apa itu “agen” sebenarnya?

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.

Mengelola agen = mengelola tim baru

Lucunya, prinsip mengelola agen ternyata mirip banget dengan onboarding anggota tim baru:

• Onboarding adalah investasi besar di depan. Beri agen konteks lengkap — dokumen, contoh hasil yang baik, batas yang jelas. Riset “Prompt Patterns” di arXiv mendukung ini.
• Tetapkan “definition of done” yang ketat. Agen jago mengejar metrik, payah menebak intent. Jadi tulis semuanya eksplisit.
• Review awal, kemudian sampling. Awal-awal: review 100% output. Setelah kepercayaan terbangun: sample 10–20%. Sama seperti mengelola junior.
• Human-in-the-loop di setiap titik berisiko tinggi. Approval, eksekusi yang tidak bisa dibatalkan, atau keputusan dengan implikasi reputasi — selalu human gate. Ini adalah inti rekomendasi NIST AI Risk Management Framework.

Stack agen sederhana yang saya jalankan

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):

• Zapier Agents atau Make — Automation visual untuk task berulang.
• Lindy atau Relay.app — Workflow AI-first yang lebih natural.
• MCP (Model Context Protocol) — Standar terbuka dari Anthropic untuk menghubungkan AI ke tools yang sudah kamu pakai (Jira, Notion, Linear, Gmail). Ini akan menjadi standar industri.

Jalur 2 — Self-hosted (data di tangan kamu, perlu sedikit setup):

• Openclaw — Agen AI otonom open-source yang berjalan di mesin sendiri (PC, VPS, atau Raspberry Pi). Yang bikin beda, dia bisa mengeksekusi aksi nyata (membaca/menulis file, menjalankan skrip, mengirim pesan) lewat WhatsApp atau Discord. Saya pakai ini sebagai asisten pribadi 24/7 — monitoring sumber riset, ringkasan harian, dan eksekusi task ringan. Dan data tidak pernah meninggalkan mesin saya, itu alasan utama saya pilih ini.
• OpenRouter — Akses ke berbagai LLM (GPT, Claude, Gemini) dalam satu API. Berguna untuk agen self-hosted yang butuh fleksibilitas model.

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.

Ketika MVP dibuat dalam akhir pekan, peran PM berubah.

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.

Tools yang saya pakai dan untuk apa

• Lovable — Aplikasi full-stack lengkap dengan database & auth. Bagus untuk MVP SaaS dan demo cepat ke klien. Ini favorit saya untuk validasi konsep awal.
• Claude Code — Terminal-based, paling kuat untuk codebase yang sudah ada. Saya pakai untuk internal tools dan diskusi teknis dengan tim engineering.
• Codex — Sebagai pelengkap Claude Code. Pendekatan yang berbeda terhadap masalah yang sama sering memberi insight baru.
• Tools lain yang relevan untuk diketahui: v0 by Vercel (komponen UI), Bolt.new (browser-based full-stack), Cursor (IDE AI-native). Pilih yang sesuai konteks pekerjaanmu.

Apa artinya bagi peran PM?

Discovery jadi lebih penting dari delivery. Kalau membangun jadi murah, pertanyaan yang paling mahal adalah “apa ini memang perlu dibangun?” 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:

• Validasi ide tanpa nunggu antrian development
• Komunikasikan spesifikasi lewat demo, bukan dokumen
• Tes asumsi UX sama user nyata dalam hitungan jam
• Pahami batasan teknis secara nyata, bukan cuma teori

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.

Catatan penting: vibe coding bukan rekayasa perangkat lunak

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.

Hal yang AI tidak akan pernah bisa lakukan untukmu.

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.

Membaca ruangan bukan keterampilan lunak — itu pekerjaan kerasmu

Engineer senior yang biasanya vokal tiba-tiba diam di meeting. Designer merespons ide kamu dengan “menarik”. Stakeholder cuma balas email dengan “Noted.” Semua itu sinyal, dan PM yang baik menangkapnya real-time. AI tidak bisa. HBR menyebutnya contextual intelligence.

Tiga hal yang saya lakukan untuk membangun trust dengan tim

• 1:1 yang sungguh-sungguh, bukan status update. Saya tidak pernah membuka 1:1 dengan “bagaimana progress X?”. Saya buka dengan “bagaimana kabarmu minggu ini?”. Status ada di tools. 1:1 untuk hal yang tidak ada di tools. Lihat panduan 1:1 dari Lattice untuk frameworknya.
• Mengakui ketidaktahuan secara publik. “Saya tidak tahu, mari kita cari tahu” mengembalikan banyak credibility, bukan menghilangkannya. Konsep ini diteliti oleh Brené Brown di “Dare to Lead”.
• Mengambil tanggung jawab penuh ketika ada masalah, kredit penuh untuk tim ketika berhasil. Kedengarannya klise, tapi saya belum nemu penggantinya.

Memberi feedback itu bisa dilatih

Saya butuh waktu bertahun-tahun untuk belajar memberi feedback dengan baik. Dua framework yang paling membantu:

• Radical Candor — Kim Scott — “Care personally, challenge directly”. Satu pilar tanpa yang lain malah jadi berbahaya.
• The Feedback Fallacy — HBR (Buckingham & Goodall) — Argumen kontra-intuitif bahwa banyak praktik feedback standard justru merusak.

Konflik itu informasi

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.

Berhentilah mencari “career path”. Bangun career portfolio.

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.

Tiga jenis modal yang harus dikembangkan PM

Saya mencuri framework ini dari Henrik Karlsson dan menyesuaikan untuk PM:

• Modal pengetahuan — Pemahaman teknis, industri, dan domain. Investasi: belajar terus-menerus. Sumber favorit saya: Stratechery (Ben Thompson) untuk strategi, Not Boring (Packy McCormick) untuk industri, Lenny’s Newsletter untuk PM craft.
• Modal jaringan — Bukan hanya jumlah koneksi, tapi kualitas dan keragaman. PM yang baik tahu cara mendapat jawaban dari orang yang tepat, cepat. “Never Eat Alone” — Keith Ferrazzi klasik di topik ini.
• Modal reputasi — Apa yang orang katakan tentang kamu saat kamu tidak ada di ruangan. Bangun ini dengan: pengiriman konsisten, transparansi tentang kegagalan, dan kemurahan hati.

Belajarlah output secara publik, bukan hanya konsumsi

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.

Pertanyaan untuk menemukan kelebihanmu sendiri

Setiap kuartal saya menulis ulang jawaban untuk 4 pertanyaan ini. Mereka membantu saya tetap jujur:

• Apa yang saya kerjakan dengan mudah, padahal orang lain susah?
• Topik apa yang saya bicarakan tanpa lelah, di mana pun?
• Skill apa yang akan jadi langka 3 tahun lagi, dan saya bisa kembangkan sekarang?
• Saya iri sama siapa, dan sebenarnya iri soal apa?

Dan akhirnya: tentang ambisi yang masuk akal

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.