Belajar Technical Product Manager - Data-Informed Product Decisions

#Pendahuluan

Setelah di episode 6 kita membahas API sebagai produk — developer sebagai user, idempotency, versioning — kini kita bahas bahan bakar keputusan di balik semua itu: data. Keputusan TPM yang tidak berbasis data cepat atau lambat menjadi arena opini senioritas; siapa yang lebih tinggi jabatannya, dialah yang menang.

Mengapa episode ini penting bagi TPM khususnya? Karena TPM punya akses unik ke dua keluarga metrik sekaligus — metrik produk (adopsi, retensi) dan metrik teknis (latency, error rate) — dan justru di pertemuan keduanya insight paling bernilai lahir: success rate pembayaran yang turun 0.3% bisa berarti jutaan rupiah revenue hilang, meski grafiknya terlihat "hanya turun sedikit".

#Pohon Metrik: Dari North Star ke Input Metrics

Mulailah dengan satu north star metric — ukuran tunggal nilai yang produk ciptakan — lalu pecah jadi input metrics yang bisa digerakkan tim.

Untuk NusaPay, north star yang masuk akal: volume transaksi berhasil per bulan. Pecahannya:

Dua properti pohon metrik yang sehat: setiap input metric punya pemilik yang bisa bertindak atasannya, dan gabungan input metrics secara matematis benar-benar menjelaskan north star — bukan sekadar daftar angka kesukaan tiap orang.

TPM harus waspada satu penyakit klasik: metric yang mudah naik tapi tidak bernilai (vanity metric). Jumlah merchant terdaftar naik terasa enak, tetapi jika transaksi per merchant anjlok, north star tetap stagnan. Selalu pasangkan metrik dengan counter-metric-nya.

#Metrik Teknis Adalah Metrik Produk

Di produk infrastruktur seperti NusaPay, batas antara metrik teknis dan produk kabur. Empat metrik teknis yang wajib ada di dashboard TPM:

• Success rate: persentase transaksi berhasil; indikator kesehatan paling langsung ke revenue.
• p95/p99 latency: waktu respons endpoint inti; ekor lambat = developer merchant frustrasi.
• Error rate by code: pola error memberi tahu pain integrasi mana yang perlu docs lebih baik.
• Uptime/error budget burn: apakah reliability kita sesuai janji SLA (bedah lengkap di episode 13).

Cara membacanya sebagai satu cerita: success rate QRIS turun 0.4% minggu ini → breakdown by channel menunjukkan satu bank issuer menyumbang mayoritas kegagalan → keputusan TPM: eskalasi ke partnership bank tersebut, sementara comms proaktif ke merchant. Tanpa data teknis, kalian baru tahu masalah ini dari tweet merchant marah.

#Instrumentasi: Event yang Baik

Metrik hanya sebaik kualitas event di baliknya. Konvensi event yang sehat: nama konsisten (payment_attempted, payment_succeeded), properti kaya, dan satu skema yang didokumentasikan.

{
  "event": "payment_attempted",
  "timestamp": "2026-09-01T10:15:22Z",
  "properties": {
    "merchant_id": "MID-204",
    "channel": "qris",
    "amount_bucket": "100k-500k",
    "sdk_version": "js-3.4.1",
    "attempt": 1
  }
}

Perhatikan attempt: properti kecil ini membedakan percobaan pertama dari retry — tanpanya, success rate bisa terlihat lebih baik dari kenyataan karena kegagalan yang dicoba ulang dan akhirnya sukses dihitung dua kali. Detail semacam inilah yang hanya tertangkap kalau TPM ikut mereview skema event.

#Eksperimen: A/B Test Secukupnya

Untuk keputusan tentang UX onboarding, pricing page, atau copy docs, A/B test adalah standar emas. Disiplin minimum yang harus kalian pegang:

1. Hipotesis tertulis sebelum mulai: "sandbox baru menaikkan TTFC-to-success dari 45% menjadi 60%".
2. Sample size dihitung di depan: efek 15% pada funnel kecil butuh waktu berminggu-minggu; jangan berhenti di hari ketiga karena "trennya sudah kelihatan".
3. Satu variabel: sandbox baru sekaligus docs baru membuat hasil tak bisa diatribusikan.
4. Guardrail metrics: metrik yang TIDAK boleh rusak — misalnya saat optimasi onboarding, pastikan fraud sign-up tidak ikut naik.

Untuk perubahan teknis (migrasi processor, arsitektur settlement), eksperimen acak jarang layak; gantinya gunakan rollout bertahap plus perbandingan kohort — pola yang dibedah tuntas di episode 17.

#Metric Framework NusaPay

Praktik episode ini: susun satu halaman metric framework untuk Payments Core:

• North star + 4 input metrics dengan pemilik dan baseline saat ini.
• Untuk tiap input metric: counter-metric dan sumber datanya (dashboard mana, event apa).
• Satu hipotesis eksperimen kuartal ini lengkap dengan sample size dan guardrail metrics.

Simpan di 04-roadmap/metrics.md. Dokumen ini akan jadi rujukan saat kalian memprioritaskan backlog bersama eng lead di episode berikutnya.

#Spesifikasi Dashboard: Artefak Kecil yang Sering Terlupakan

Metrik hanya berguna kalau bisa dilihat orang yang tepat. Saat meminta dashboard ke tim data/engineering, spesifikasikan seperti spec fitur:

Audiens   : TPM, eng lead, head of product (baca 10 menit/pekan)
Baris 1   : North star + delta vs pekan lalu (angka + panah)
Baris 2   : Success rate per channel (QRIS/VA/kartu) vs target
Baris 3   : p95 latency API inti + error budget tersisa
Baris 4   : TTFC median pekan ini + funnel bocor terbesar
Anomali   : kolom teks - satu penyebab utama bila ada lonjakan
Sumber    : event X, tabel Y; update otomatis tiap Senin 08.00

Tanpa spesifikasi seperti ini, dashboard yang lahir biasanya terlalu banyak grafik dan terlalu sedikit keputusan. Uji kelayakannya satu kalimat: setiap baris harus punya aksi potensial — kalau tidak ada yang akan dilakukan walau angkanya berubah, hapus baris itu.

#Penutup

Inti yang harus dibawa pulang:

• Bangun pohon metrik: north star → input metrics dengan pemilik jelas; hindari vanity metric dengan selalu memasangkan counter-metric.
• Di produk infrastruktur, metrik teknis (success rate, p95, uptime) adalah metrik produk; baca mereka sebagai satu cerita sebab-akibat.
• Review skema event seperti review kode: detail kecil seperti properti attempt menentukan benar-salahnya analisis.
• Eksperimen butuh hipotesis tertulis, sample size, satu variabel, dan guardrail metrics — bukan sekadar tombol split 50/50.

Di episode 8 selanjutnya kita bicara Engineering Collaboration — cara bekerja dengan eng lead sehari-hari, framework prioritisasi RICE dengan contoh hitung nyata, seni negosiasi trade-off, dan menulis tiket yang engineer hormati. Sampai jumpa!