Belajar Product Manager - Collaboration dengan Engineering

#Pendahuluan

Setelah di episode 9 kita menulis PRD dan acceptance criteria, pada episode ini kita belajar bagaimana tim bekerja bersama. PRD yang sempurna tanpa kolaborasi yang baik tetap menghasilkan produk yang buruk. PM dan engineering harus punya "cara kerja" yang disepakati bersama — working agreements.

Banyak organisasi mengalami friction antara PM dan engineering: PM merasa engineering terlalu lambat, engineering merasa PM terlalu sering berubah. Working agreements yang jelas mengurangi friction ini dengan menetapkan ekspektasi di awal.

#Working Agreements

Working agreements adalah kontrak sosial antara PM dan engineering tentang cara kerja. Contoh working agreements:

Aspek	Contoh Kesepakatan	Mengapa Penting
Communication	Update slack setiap hari jam 10	Transparansi tanpa meeting
Decision making	PM decide product, Eng decide tech	Clear ownership
Scope changes	Discussed in refinement, not mid-sprint	Prevent scope creep
Estimation	Engineering estimates, PM doesn't override	Respect expertise
Code review	PR reviewed within 24 hours	Blocking prevention

Working agreements harus ditulis secara eksplisit dan direview secara berkala. Yang tidak ditulis, tidak akan diikuti.

#Backlog Management

#Struktur Backlog

Backlog yang sehat punya struktur hierarchical:

Backlog Hierarchy

Epic (inisiatif strategis)
  └── Story (user-facing value)
       └── Task (technical work)
            └── Subtask (granular action)

#Backlog Health

Backlog harus dibersihkan secara berkala. Tanda backlog yang sakit:

Lebih dari 100 story yang belum di-prioritaskan.
Story yang sudah ada lebih dari 6 bulan tanpa tindakan.
Tidak ada perbedaan antara "nice to have" dan "must have."
Banyak story yang tidak terhubung ke epic atau OKR.

#Grooming / Refinement

Refinement adalah proses menjaga backlog tetap sehat. PM dan engineering harus menghabiskan waktu 1-2 jam per minggu untuk:

Review story yang akan masuk sprint berikutnya.
Tambahkan detail, estimasi, dan acceptance criteria.
Hapus atau deprioritaskan story yang tidak lagi relevan.

#Sprint Planning

#Sebelum Sprint Planning

PM harus memastikan:

Story yang masuk sprint sudah punya acceptance criteria jelas.
Dependency sudah diidentifikasi (external service, design, data).
Prioritas sudah ditetapkan berdasarkan value dan urgency.

#During Sprint Planning

Planning yang efektif:

PM present: prioritaskan story berdasarkan value.
Engineering estimate: berapa besar effort masing-masing story.
Tim decide: berapa banyak story yang realistis masuk sprint.
Commitment: tim berkomitmen pada scope, bukan deadline.

#Estimasi

#Story Points

Story points mengukur kompleksitas relatif, bukan waktu. Skala umum: 1 (sangat mudah), 2 (mudah), 3 (sedang), 5 (sulit), 8 (sangat sulit), 13 (eksklusif).

#T-Shirt Sizing

Untuk perencanaan awal (sebelum detail cukup untuk story points), pakai T-Shirt sizing: S (1-2 hari), M (3-5 hari), L (1-2 minggu), XL (lebih dari 2 minggu).

Note

PM sebaiknya tidak memaksakan estimasi ke engineering. Jika PM merasa estimasi terlalu besar, tanyakan: "apa yang bisa kita kurangi untuk membuat ini lebih kecil?" — bukan "bisakah lebih cepat?"

#Penutup

Inti yang harus dibawa pulang:

Working agreements harus ditulis secara eksplisit — yang tidak ditulis, tidak akan diikuti.
Backlog harus dibersihkan secara berkala — story yang sudah 6 bulan tanpa tindakan harus dihapus.
Sprint planning adalah komitmen pada scope, bukan deadline — engineering menentukan berapa banyak yang realistis.
Estimasi adalah hak engineering — PM bisa menantang scope, tetapi bukan estimasi waktu.

Di episode 11 selanjutnya kita akan membahas launch & go-to-market — launch plan, positioning, pricing dasar, dan distribusi. Topik ini menghubungkan build yang sudah selesai dengan cara menghadirkannya ke pasar. Tetap semangat!