Belajar Technical Product Manager - AI & LLM Products (Dasar)

#Pendahuluan

Setelah di episode 8 kita merapikan kolaborasi harian dengan engineering — trust, RICE, tiket berkualitas — episode ini menyambangi gelombang terbesar yang mengubah pekerjaan TPM: produk AI. Di NusaPay, manajemen baru saja meminta "tambahkan AI di dashboard" — dan tugas kalian memastikan permintaan itu menjadi fitur bermakna, bukan demo yang mengesankan di rapat lalu mati di produksi.

Kenapa TPM wajib paham dasar LLM? Karena keputusan-keputusan paling mahal produk AI terjadi sebelum engineering menulis kode: apakah masalah ini butuh LLM sama sekali, model besar atau kecil, akurasi berapa yang bisa diterima, dan siapa yang menanggung biaya inference per bulan. Tanpa pemahaman dasar, kalian hanya bisa menunggu jawaban vendor.

#LLM dalam Lima Menit

Cukup lima konsep untuk bisa berdiskusi:

• Token: satuan potongan teks yang diproses model; biaya dan latensi dihitung per token. Dokumen panjang = mahal dan lambat.
• Context window: jumlah token maksimum yang bisa "dilihat" model sekali jalan. Konteks bukan ingatan permanen — semua yang dibutuhkan harus dimasukkan tiap kali.
• Temperature: knob keacakan. Tinggi = jawaban variatif dan kreatif; rendah = konsisten. Untuk klasifikasi fraud, temperature rendah; untuk draft copy, boleh lebih tinggi.
• Hallucination: model bisa menghasilkan klaim meyakinkan tapi salah. Ini bukan bug yang akan hilang di versi berikutnya — ia properti fundamental yang didesain sekelilingnya.
• Prompt & retrieval: instruksi plus data yang diberikan ke model. Pola umum produk enterprise adalah RAG — ambil dokumen relevan dulu, baru model menjawab berdasarkan itu.

Analoginya: LLM adalah pegawai yang membaca sangat luas, cepat, dan pandai merangkum, tetapi kadang mengarang dengan penuh percaya diri, lupa segalanya begitu giliran selesai, dan ditagih biaya per kata. Semua desain produk AI adalah jawaban atas empat sifat itu.

#Kenapa Produk AI Berbeda dari Software Biasa

Tiga pergeseran fundamental yang harus kalian masukkan ke PRD:

Konsekuensi praktisnya: fitur AI hampir selalu dirancang sebagai asisten dengan manusia memverifikasi, bukan otomatisasi penuh, pada iterasi awal. Dan setiap PRD fitur AI wajib punya bagian eval — persyaratan baru yang belum ada di template PRD episode 5.

#Empat Pola Produk AI

Hampir semua fitur AI bernilai jatuh ke empat pola. Kenali polanya supaya diskusi "tambahkan AI" langsung konkret:

1. Klasifikasi/routing: labeli input ke kategori tetap. Contoh: routing tiket support merchant otomatis. Risiko rendah, mudah dieval.
2. Ekstraksi: ubah teks tak terstruktur jadi data terstruktur. Contoh: ekstrak invoice dari email merchant ke form payout.
3. Copilot/asistensi: model membantu user menyelesaikan tugas, user tetap memutuskan. Contoh: copilot menjawab pertanyaan developer tentang API docs.
4. Generasi konten: buat draft baru. Contoh: generate deskripsi produk merchant. Paling mudah didemo, paling sulit dijaga kualitasnya di skala.

Untuk NusaPay, kandidat pertama yang layak bukan "chatbot keren", melainkan pola 1-2: klasifikasi dan ekstraksi punya ground truth jelas sehingga bisa dieval murah.

#Studi Kasus: Fitur Fraud Alert

Manajemen ingin "AI deteksi penipuan". Alih-alih menerima brief vagu, pecah menjadi spesifikasi TPM:

• Masalah: merchant kecil kehilangan dana karena pola transaksi anomali tidak terlihat sampai terlambat; 12% churn merchant menyebut keamanan.
• Pola: mulai dari alert, bukan blokir otomatis — model memberi skor risiko, sistem memberi peringatan; keputusan tetap milik merchant.
• Output: skor 0-100 plus alasan ringkas ("15 transaksi kecil berturutan dari negara berbeda dalam 10 menit").
• Metrik: precision pada threshold alert (berapa % alert yang benar-benar fraud), dan guardrail: false positive rate — alert palsu yang mengganggu merchant normal.
• Eval minimum: dataset historis transaksi berlabel (fraud/bukan), ukur precision-recall, tetapkan threshold bersama tim risk.

#Eval Minimum Sebelum Fitur AI Rilis

Sebelum fitur AI kalian boleh tayang, tiga pertanyaan eval harus punya jawaban tertulis:

1. Dataset uji ada? Minimal 100-200 contoh nyata berlabel, termasuk edge case. Tanpa dataset, "kualitasnya bagus" hanya opini.
2. Rubrik dinilai siapa? Tentukan: akurasi klasifikasi dihitung otomatis; kualitas rangkuman dinilai reviewer manusia dengan skala tetap.
3. Ambang lolos berapa? Misal: precision minimal 80% pada threshold terpilih, else tidak rilis. Angka bisa dinego; keberadaannya tidak.

Topik ini kami perdalam di episode 21 (eval framework lengkap, guardrails, cost engineering) dan episode 22 (agentic products). Untuk sekarang, disiplin dataset + rubrik + ambang sudah membuat kalian lebih siap dari mayoritas tim.

#Pertanyaan TPM ke Vendor Model

Sebagian besar produk AI memakai model pihak ketiga. Sebelum kontrak, jawaban lima pertanyaan ini wajib ada di tangan kalian:

1. Data & privasi: apakah prompt kita dipakai melatih model mereka? Retensinya berapa lama? (kritis untuk data merchant — sambungkan ke kewajiban UU PDP).
2. Biaya & jaminan: harga per token saat ini, diskon volume, dan komitmen pemberitahuan bila harga berubah.
3. Stabilitas versi: apakah versi model bisa dipin (pinned), atau akan berganti diam-diam? Perubahan diam-diam merusak eval yang sudah lulus.
4. SLA & region: uptime API inference, dan apakah data bisa diproses di region tertentu.
5. Exit plan: seberapa mudah memindahkan beban ke provider lain — vendor lock-in adalah risiko produk, bukan hanya teknis.

Pertanyaan-pertanyaan ini biasanya menjawab dirinya lewat dokumen keamanan vendor — dan persis jenis due diligence yang kita latih di episode 14 dan 20.

#Penutup

Inti yang harus dibawa pulang:

• Lima konsep LLM yang wajib: token, context window, temperature, hallucination, prompt/RAG — semua keputusan desain AI adalah jawaban atas keterbatasan-keterbatasan ini.
• Produk AI probabilistik: output bervariasi, kualitas bergrediasi, biaya runtime nyata, dan kegagalan terjadi halus — masukkan ke PRD.
• Empat pola produk AI: klasifikasi, ekstraksi, copilot, generasi — pilih pola dengan ground truth termudah untuk kandidat pertama.
• Fraud alert NusaPay menunjukkan cara TPM menerjemahkan brief vagu jadi spesifikasi: pola alert-first, output berpenjelasan, metrik precision + false positive, eval berbasis dataset historis.

Di episode 10 selanjutnya kita bahas musuh senyap setiap roadmap: Technical Debt & Quality — definisi hutang teknis yang presisi, kuadran deliberate-reckless, cara menetapkan budget debt vs feature, dan menyusun debt register yang bisa dipertanggungjawabkan ke manajemen. Sampai jumpa!