Belajar Technical Product Manager - Engineering Collaboration

#Pendahuluan

Setelah di episode 7 kita membangun metric framework — north star, input metrics, eksperimen dengan guardrail — kini kita hadapi realitas eksekusi: semua keputusan itu dieksekusi oleh manusia-manusia di squad engineering. Kualitas hubungan TPM dengan engineering menentukan apakah data dan strategi kalian berubah jadi software, atau hanya jadi slide.

Kenapa topik ini layak satu episode penuh? Karena kegagalan TPM jarang berupa kegagalan teknis — hampir selalu berupa kegagalan kolaborasi: backlog yang tidak dipercaya engineer, trade-off yang dinego seperti tawar-menawar pasar, dan tiket yang ditulis seolah engineer adalah mesin. Episode ini memberi playbook untuk mencegah ketiganya.

#Kontrak Kerja dengan Eng Lead

Eng lead adalah partner terpenting kalian. Bangun kontrak kerja eksplisit — pembagian yang disepakati, bukan diasumsikan:

Ritual yang menjaga kontrak ini tetap hidup: sync mingguan 30 menit (metrik + prioritas + blocker), review roadmap bersama tiap awal kuartal, dan kesepakatan bahwa pertanyaan "kenapa ini penting?" serta "berapa biayanya?" boleh diajukan bebas tanpa terasa menyerang.

Trust dibangun dari dua arah: eng lead percaya kalian saat kalian membela tim dari permintaan tak masuk akal, dan kalian percaya eng lead saat angka estimasinya jujur termasuk kabar buruk. Satu pelanggaran kecil di salah satu arah butuh berbulan-bulan diperbaiki.

#Framework Prioritisasi

Dua framework yang cukup untuk 95% kasus:

#RICE

Skor = (Reach × Impact × Confidence) / Effort. Contoh nyata backlog Payments Core:

Angka absolutnya tidak sakral; nilai RICE ada di transparansi asumsi. Saat stakeholder menantang urutan prioritas, kalian tidak lagi berdebat opini — kalian mengaudit asumsi reach atau impact per item. Itu diskusi yang bisa diselesaikan.

#Impact-Effort Matrix

Untuk sesi brainstorm cepat: plot inisiatif pada kuadrant dampak vs effort. Kuadrant high impact-low effort dieksekusi duluan; high impact-high effort dipecah; low impact-high effort ditolak secara eksplisit dengan catatan alasannya — penolakan tertulis mencegah isu sama kembali setiap bulan.

#Seni Negosiasi Trade-off

Pertanyaan "fitur A atau refactoring B?" akan datang setiap pekan. Tiga prinsip agar negosiasi sehat:

1. Terjemahkan ke mata uang yang sama: bandingkan dampak revenue/retensi vs risiko insiden dalam satuan bisnis, bukan "penting vs penting". Downtime ledger 2 jam kuartal lalu = kerugian X rupiah + Y merchant komplain — pakai angka itu.
2. Tawarkan opsi bertingkat: bukan "semua atau tidak", melainkan versi minimal (2 minggu), standar (5 minggu), lengkap (9 minggu) dengan nilai berbeda. Stakeholder merasa memilih, engineering tetap punya ruang desain.
3. Catat keputusan: decision record singkat — konteks, opsi, pilihan, alasan. Enam bulan kemudian, dokumen ini menyelamatkan kalian dari "dulu siapa bilang jangan?"

Ketika tetap buntu: eskalasi bukan kekalahan — membawa trade-off ke pemilik akun metrik yang tepat adalah bagian pekerjaan, asalkan dibawa lengkap dengan opsi dan konsekuensi, bukan sebagai keluhan.

#Tiket yang Engineer Hormati

Tiket buruk boros waktu tim dua kali: saat engineer menebak maksudnya, dan saat hasilnya dikembalikan. Bandingkan:

Implementasikan webhook retry.
Ref PRD settlement T+0.

Webhook payment.succeeded harus tahan terhadap endpoint merchant down.
 
Konteks:
- 8% webhook gagal karena timeout merchant; tidak pernah dicoba ulang.
- Merchant menerima data basi di sistem mereka (tiket support #4410).
 
Acceptance criteria:
- Retry dengan backoff eksponensial: 1m, 5m, 30m, 2h (total 4 percobaan).
- Berhenti retry setelah sukses (HTTP 2xx) atau 24 jam berlalu.
- Dashboard menampilkan status delivery per webhook + tombol resend manual.
 
Non-goal:
- Perubahan format payload (sudah stabil sejak v1).
 
Open question:
- Rate limit per merchant untuk resend manual? (owner: TPM, due Jumat)

Perhatikan tiket yang baik tetap ringkas namun membawa konteks, criteria terukur, batasan non-goal, dan open question ber-owner. Pola ini identik dengan disiplin PRD di episode 5 — karena tiket hanyalah potongan PRD yang bisa dieksekusi.

#Ritual Agile Tanpa Menjadi Admin Proyek

TPM hadir di ritual, tetapi perannya spesifik:

• Planning/refinement: memastikan tiap story punya criteria dan konteks; menjawab "kenapa", bukan mengatur "bagaimana".
• Standup: mendengar sinyal blocker yang butuh intervensi lintas tim atau ke stakeholder; bukan forum minta status per orang.
• Review/demo: menunjukkan hasil ke user/stakeholder, mengumpulkan reaksi nyata.
• Retro: mengangkat tema sistemik (estimasi selalu meleset, requirement sering berubah) dan menutupnya dengan perubahan proses.

Ukuran keberhasilan kalian di ritual: keputusan yang tercepat dan tim yang tidak perlu menebak niat. Kalau kalender kalian penuh mengurus kartu Jira, kalian sedang melakukan pekerjaan project manager — ingat peringatan episode 1.

#Penutup

Inti yang harus dibawa pulang:

• Sepakati kontrak kerja tertulis dengan eng lead: siapa membawa apa di prioritas, scope, estimasi, dan insiden.
• RICE membuat prioritas bisa diaudit lewat asumsinya; simpan sebagai dokumen hidup dan revisi mingguan.
• Negosiasi trade-off sehat: satuan mata uang sama, opsi bertingkat, dan decision record tertulis.
• Tiket baik membawa konteks, acceptance criteria terukur, non-goal, dan open question ber-owner.
• Hadir di ritual agile sebagai pemutus dan penghubung — bukan admin kartu.

Di episode 9 selanjutnya kita masuki gelombang terbesar profesi ini: AI & LLM Products (Dasar) — cara kerja LLM secukupnya untuk TPM, kenapa produk AI beda dari software biasa, empat pola fitur AI, dan studi kasus menerjemahkan permintaan "tambahkan AI" menjadi fitur fraud alert yang bisa dieval. Sampai jumpa!