Belajar Technical Product Manager - Technical Discovery

#Pendahuluan

Setelah di episode 2 kita menulis tech vision doc NusaPay dengan technical bets yang terhubung ke tujuan bisnis, episode ini membahas jembatan antara strategi dan eksekusi: technical discovery. Vision doc menyebut bet event-driven settlement; discovery adalah proses menguji apakah bet itu benar-benar bisa dibangun, berapa biayanya, dan apa risikonya — sebelum organisasi mempertaruhkan kuartal penuh.

Mengapa discovery sering dilewati? Karena tekanan "mulai saja" terasa produktif. Padahal biaya mengoreksi arah naik drastis seiring waktu: salah paham yang ditemukan saat desain diganti dengan revisi dokumen; yang ditemukan setelah rilis diganti dengan migrasi data dan merchant marah. Discovery sprint 1-2 minggu adalah asuransi termurah dalam pengembangan produk.

#Empat Dimensi Feasibility

Pertanyaan "bisa tidak dibangun?" terlalu sempit. Discovery yang matang menjawab empat dimensi:

Dimensi legal dan operasional adalah yang paling sering luput dari engineer muda — dan justru sering menjadi penentu di produk finansial. TPM adalah orang yang memastikan keempat dimensi dijawab, bukan hanya yang pertama.

#Spike, PoC, Prototype, MVP

Empat alat uji dengan tujuan berbeda — salah memilih alat = boros waktu:

Aturan praktisnya: spike menjawab "mungkinkah", PoC menjawab "bisakah dengan cara ini", prototype menjawab "akan dipakaikah", MVP menjawab "bernilaikah". Untuk settlement T+0 opsi batch siang, yang dibutuhkan bukan PoC penuh — cukup spike: jalankan simulasi batch pada snapshot data jam tersibuk, ukur durasi dan dampaknya ke trafik normal. Tiga hari kerja menjawab risiko terbesarnya.

#Risk Register: Inventaris Ketidakpastian

Keluaran discovery yang paling bernilai bagi stakeholder adalah risk register — daftar risiko dengan mitigasinya:

R1  Batch siang tabrakan dengan traffic peak QRIS
    Prob: Sedang   Dampak: Tinggi (latency semua channel)
    Mitigasi: spike simulasi jam 12.00; jika lewat ambang,
    jendela batch digeser atau kapasitas ditambah.
R2  Perbedaan perilaku pembulatan batch siang vs malam
    Prob: Tinggi   Dampak: Sedang (selisih ledger)
    Mitigasi: dual-run paritas 2 minggu sebelum aktif.
R3  Bank partner menolak file settlement dua kali sehari
    Prob: Rendah   Dampak: Tinggi (fitur batal)
    Mitigasi: konfirmasi tertulis partnership sebelum build.
R4  Tim ops overload saat insiden dobel-shift
    Prob: Sedang   Dampak: Sedang
    Mitigasi: runbook baru + rotasi on-call diperluas.

Format ini mengubah percakapan "aku khawatir soal X" menjadi tabel yang bisa diprioritaskan. Catatan penting: probabilitas boleh subjekif, tetapi mitigasi harus konkret dan berpemilik — kalau mitigasi R3 adalah "nanti tanya bank", discovery belum selesai.

#Discovery Sprint 5 Hari

Untuk inisiatif sedang-besar, struktur lima hari ini terbukti cukup:

• Hari 1 — Peta masalah: rumuskan hipotesis, daftar asumsi kritis (apa yang HARUS benar agar ide layak), susun pertanyaan spike/interview.
• Hari 2 — Data & wawancara: metrik historis (volume per jam, pola peak), bicara dengan ops/support/partner tentang dampak operasional.
• Hari 3 — Spike/PoC: engineer senior menjalankan uji teknis terpenting; TPM mengunci konfirmasi eksternal (bank, vendor).
• Hari 4 — Sintesis: isi risk register, hitung estimasi kasar tiga titik, draft opsi A/B/C dengan trade-off.
• Hari 5 — Feasibility review: presentasi 30 menit ke eng lead + stakeholder; putusan: go / go-with-conditions / pivot / no-go.

Perhatikan peran TPM di tiap hari: ia pemilik pertanyaan dan sintesis, bukan pelaksana spike — itu pekerjaan engineering. Discovery yang baik adalah kolaborasi ketat, bukan pekerjaan solo PM maupun solo engineer.

#Feasibility Memo: Keluaran yang Bisa Diputuskan

Semua temuan dikristalkan dalam memo satu halaman:

Keputusan yang diminta : go/no-go opsi A batch siang
Rekomendasi            : GO dengan 2 syarat (lihat R2, R3)
Temuan utama           : 4 bullet - spike lolos, bank OK,
                         paritas butuh dual-run, cost +Rp X/bln
Risk register          : link tabel R1-R4 dengan mitigasi
Estimasi kasar         : 6 minggu (rentang 5-9), 2 engineer
Yang belum diketahui   : perilaku nominal pecahan lama (Q4 spike)

Bagian "yang belum diketahui" adalah tanda kematangan: discovery yang jujur selalu menyisa ketidakpastian — yang penting ia dinamai dan diberi rencana, bukan disembunyikan. Memo ini yang akan dirujuk saat manajemen bertanya ulang tiga bulan kemudian.

#Praktik: Jalankan Mini Discovery

Latihan episode ini: pilih fitur "kartu tersimpan" dari episode 14, lalu tulis mini discovery-nya — 5 asumsi kritis, 2 pertanyaan spike dengan kriteria jawaban, risk register 3 baris dengan mitigasi ber-owner, dan draft feasibility memo pakai struktur di atas. Simpan di 02-discovery/.

#Penutup

Inti yang harus dibawa pulang:

• Discovery menjawab empat dimensi: teknis, operasional, legal/compliance, ekonomi — bukan cuma "bisa nggak dibangun".
• Pilih alat uji sesuai pertanyaan: spike untuk "mungkinkah", PoC untuk "bisakah begini", prototype untuk UX, MVP untuk nilai nyata.
• Risk register mengubah kekhawatiran menjadi tabel prioritas; mitigasi wajib konkret dan berpemilik.
• Discovery sprint 5 hari berakhir di feasibility review dengan putusan eksplisit — termasuk keberanian no-go.
• Feasibility memo satu halaman dengan rekomendasi dan sisa ketidakpastian yang dinamai adalah dokumen keputusan terbaik kalian.

Di episode 4 selanjutnya kita bekali diri dengan bahasa dasar profesi ini: Architecture & System Thinking — membaca arsitektur NusaPay level context dan container, trade-off klasik konsistensi-vs-availability sampai build-vs-buy, constraints tak terlihat, dan daftar pertanyaan tajam untuk architecture review. Sampai jumpa!