Belajar Technical Product Manager - Developer Experience (DX)

#Pendahuluan

Setelah di episode 14 kita menulis requirement compliance ke PRD dan merencanakan trust center, episode ini membahas wilayah yang bagi NusaPay bukan pelengkap melainkan inti bisnis: developer experience. Ingat episode 1 — user utama NusaPay adalah developer merchant. Kualitas pengalaman mereka mengintegrasikan API adalah kualitas produk itu sendiri.

Kenapa DX layak diperlakukan sebagai produk dengan roadmap sendiri? Karena datanya brutal: mayoritas calon merchant yang gagal integrasi tidak pernah mengirim tiket — mereka diam-diam pergi ke kompetitor. Funnel onboarding yang bocor tidak terdengar; ia hanya terlihat di angka.

#Time to First Call: Aha Moment Produk API

Metrik tunggal paling penting DX adalah TTFC — waktu sejak daftar akun sampai request pertama berhasil di sandbox. Ia padanan "activation" produk konsumen:

Daftar akun            -> 100%
API key di-generate    ->  72%   <- bocor 1: konfirmasi email lambat
Call pertama dicoba    ->  51%   <- bocor 2: docs quickstart sulit ditemukan
Call pertama sukses    ->  38%   <- bocor 3: error auth membingungkan
Integrasi produksi     ->  24%

Cara membacanya ala TPM: setiap lompatan penurunan adalah hipotesis masalah yang bisa diuji. Bocor 3 misalnya — cek log error auth: kalau dominan invalid_signature tanpa pesan penjelasan, solusinya bukan marketing, melainkan perbaiki pesan error + contoh signature di docs. Data teknis dan funnel bertemu; inilah keunggulan analisis TPM.

Target TTFC yang sehat untuk payment API: menit, bukan hari. Setiap jam yang developer habiskan untuk call pertama adalah pajak atas kesabaran mereka.

#Anatomi Onboarding yang Baik

Pengalaman 10 menit pertama developer menentukan segalanya. Standar emas:

1. Quickstart 5 langkah: daftar → ambil API key → jalankan satu curl di sandbox → lihat response → baca panduan lanjutan. Tidak lebih.
2. Sandbox realistis: perilaku mirip produksi termasuk skenario gagal — test card untuk sukses/decline/timeout. Sandbox yang hanya bisa sukses mendidik developer secara keliru.
3. Error message self-service: tiap error punya kode stabil, penyebab, dan tautan fix — standar yang kita tetapkan di episode 6.
4. Contoh kode bahasa populer: minimal JS dan PHP (pasar Indonesia), salin-tempel-langsung-jalan.

Uji lapangan murah: minta satu developer baru (atau teman sesama engineer) mengikuti quickstart sambil berpikir keras (think aloud). Hitung berapa kali mereka tersangkut. Lima tersangkutan = lima perbaikan docs gratis.

#Komponen DX Lainnya

Onboarding hanya satu permukaan. Peta komponen DX lengkap NusaPay:

Perhatikan polanya: semua baris punya metrik. DX yang tidak diukur akan selalu kalah perebutan kapasitas sprint dengan fitur komersial yang punya angka revenue.

#Mengukur dan Memprioritaskan DX

Tiga sumber data yang saling melengkapi:

• Telemetri produk: funnel TTFC, adopsi SDK, error rate by code (episode 7).
• Survey developer: skor effort (CES) setelah integrasi selesai; satu pertanyaan cukup — "seberapa mudah Anda berintegrasi?"
• Data support: top 10 tiket berulang = daftar perbaikan docs paling murah dengan dampak terbesar.

Prioritisasinya pakai kerangka biasa (RICE, episode 8), tapi dengan satu twist khusus DX: hitung juga biaya akuisisi yang bocor. Kalau 14% calon merchant hilang di lompatan auth dan nilai lifetime merchant adalah X, maka memperbaiki halaman auth punya business case senilai puluhan persen X — angka yang bikin DX menang lawan fitur shiny mana pun.

#DX Roadmap NusaPay

Susun roadmap Now-Next-Later (format episode 2) untuk DX:

• Now (kuartal ini): quickstart baru 5 langkah + pesan error auth diperkaya + sandbox test cards lengkap. Target: TTFC-to-success 38% → 55%.
• Next: SDK PHP v2 dengan type hints, webhook local testing tool, docs search yang tidak menyedihkan.
• Later: AI assistant menjawab pertanyaan integrasi dari corpus docs (persiapan konsepnya sudah ada di episode 9).

Perhatikan tiap item Now punya target metrik. Roadmap DX tanpa metrik hanyalah daftar keinginan engineering yang manis.

#Anti-Pattern DX

Tiga kebiasaan yang merusak pengalaman developer tanpa terasa sedang merusak:

1. Docs menyalin kode, bukan menjelaskan: reference otomatis dari kode itu perlu tetapi tidak pernah cukup — developer datang untuk "bagaimana saya mencapai tujuan", bukan daftar parameter.
2. Changelog tanpa migrasi: mengumumkan perubahan tanpa contoh sebelum-sesudah memindahkan beban pemahaman ke ribuan developer — pajak kolektif yang mahal.
3. Sandbox berbeda perilaku dari produksi: developer menguji di sandbox, lolos, gagal di produksi — kepercayaan pada seluruh platform runtuh bersama satu ketidaksesuaian.

Semua antidotnya satu kata: empati — tinjau setiap artefak dari kursi developer yang buru-buru.

#Praktik: Audit DX Satu Sore

Latihan episode ini: pilih satu API publik pembayaran mana pun (bukan NusaPay), ikuti quickstart-nya sampai call pertama berhasil sambil mencatat waktu dan setiap gesekan. Hasilkan audit satu halaman: timeline gesekan, tiga perbaikan prioritas jika kalian TPM-nya, dan estimasi dampaknya ke funnel. Latihan ini melatih mata DX kalian dengan biaya nol rupiah.

#Penutup

Inti yang harus dibawa pulang:

• TTFC adalah activation metric produk API; bedah funnel-nya per lompatan dan gabungkan dengan log error untuk menemukan akar bocornya.
• Onboarding emas: quickstart 5 langkah, sandbox yang bisa gagal, error self-service, contoh kode lokal.
• Semua komponen DX wajib punya metrik; DX tak terukur selalu kalah budget dari fitur komersial.
• Hitung biaya akuisisi yang bocor agar perbaikan DX punya business case yang menang RICE.
• DX berlaku juga internal — velocity lintas squad adalah uang tunai.

Di episode 16 selanjutnya kita bicara Infrastructure & Cost — unit economics per transaksi, cost driver cloud yang sering menguras margin, lever efisiensi, dan cara TPM menyandingkan keputusan produk dengan budget infrastruktur. Sampai jumpa!