Belajar Technical Product Manager - Peran & Posisi (PM ↔ Engineer)

#Pendahuluan

Setelah di episode 0 kita menyiapkan skill dasar, tool, dan studi kasus NusaPay, pada episode ini kita memahami siapa TPM sebenarnya. Pertanyaannya terdengar sederhana, padahal inilah sumber kebingungan paling umum: banyak engineer mengira TPM adalah "PM yang bisa ngoding", dan banyak PM mengira TPM adalah "penghubung ke tim teknis". Keduanya kurang tepat.

Mengapa penting memahami peran dengan presisi? Karena cara kalian mengukur kesuksesan sendiri menentukan keputusan harian: apa yang kalian tulis, rapat apa yang kalian pimpin, dan konflik apa yang berani kalian ambil. TPM yang salah paham tentang perannya akan jatuh menjadi project manager biasa atau, lebih buruk, messenger antara bisnis dan engineering.

#Definisi Kerja TPM

Definisi kerja yang kita pakai di seluruh series ini:

TPM menjembatani product goals dengan technical feasibility: ia paham sistem sampai ke dalam (bukan hanya permukaannya), sehingga bisa membuat keputusan produk yang realistis secara teknik dan keputusan teknik yang berpihak pada bisnis.

Ada dua kata kunci yang sering terlewat:

Paham sistem dalam: bukan sekadar tahu "ini pakai microservices", tapi tahu trade-off-nya — kenapa dibagi begitu, apa yang mahal diubah, dan di mana risikonya.
Membuat keputusan, bukan hanya meneruskan informasi: TPM yang baik tidak bertanya ke engineering "bisa tidak?" lalu melaporkan jawabannya. Ia ikut merumuskan opsi dan konsekuensinya.

Di NusaPay, contohnya: merchant besar meminta fitur settlement T+0 (dana cair hari yang sama). PM biasa mencatat permintaan dan menanyakan estimasi. TPM membuka arsitektur settlement, melihat bahwa payout engine saat ini berjalan batch per malam, lalu merumuskan tiga opsi — batch tambahan siang, streaming real-time, atau partnership bank — lengkap dengan biaya, risiko, dan waktu masing-masing.

#Posisi di Antara Peran Lain

Kebingungan terbesar ada di batas-batas peran. Tabel ini merangkumnya:

Aspek	Product Manager	Technical PM	Engineering Lead	Software Architect
Fokus utama	Nilai bisnis & user	Nilai bisnis lewat keputusan teknis	Kesehatan tim & eksekusi	Desain sistem jangka panjang
Deliverable khas	PRD, roadmap	PRD teknis, feasibility memo, trade-off analysis	Sprint plan, growth engineer	Architecture decision records
Metrik sukses	Adoption, revenue	Dampak bisnis dari keputusan teknis	Velocity, retensi talent	Kualitas & umur panjang sistem
Kedalaman teknis	Permukaan	Dalam tapi tanpa otoritas kode	Dalam + otoritas manajerial	Paling dalam, lintas tim

Perhatikan bahwa TPM tidak menggantikan architect maupun eng lead. Di squad Payments Core misalnya: architect menetapkan pola desain, eng lead mengatur kapasitas sprint, dan TPM memastikan semua itu mengarah ke tujuan bisnis — misalnya menolak refactoring besar yang indah tetapi tidak memindahkan metrik kuartal ini, atau justru mendukungnya dengan data downtime.

Note

Aturan praktis: jika sebuah diskusi butuh pemahaman teknis untuk diputuskan DAN keputusannya mengubah arah produk, itulah wilayah TPM. Jika hanya butuh salah satunya, PM atau eng lead cukup menanganinya.

#Tanda Organisasi Butuh TPM

Tidak semua produk butuh TPM. Sinyal-sinyal ini menunjukkan peran tersebut mulai wajib ada:

Produk API/platform — user utama adalah developer; requirement teknis adalah produk itu sendiri (NusaPay berada di titik ini).
Keputusan arsitektur mulai mengunci produk — misalnya monolith lama membuat fitur baru selalu lambat, dan tidak ada yang bisa menjelaskan trade-off-nya ke bisnis.
Enterprise customers masuk — mereka menanyakan SSO, audit log, SLA, dan compliance; pertanyaan yang butuh jawaban teknis sekaligus komersial.
Komunikasi bisnis-engineering sering meleset — fitur "sederhana" ternyata mahal karena constraint tak terlihat; estimasi selalu meleset.
Produk AI/LLM — nondeterminisme, evaluasi kualitas, dan biaya inference membuat keputusan produk tanpa pemahaman teknis sangat berisiko.

#Sehari-hari Seorang TPM

Untuk membuatnya konkret, beginilah minggu tipikal TPM di squad Payments Core:

Senin: review metrik mingguan — success rate pembayaran, p95 latency API, adopsi fitur baru; catat anomali untuk didiskusikan dengan eng lead.
Selasa: refinement tiket — memecah epik jadi tiket dengan acceptance criteria yang testable, menjawab pertanyaan konteks engineer.
Rabu: discovery — interview dua merchant tentang pain integrasi, lalu menulis feasibility memo bersama engineer senior.
Kamis: sinkron eksekutif — menerjemahkan status migrasi payment processor menjadi dampak bisnis (risiko revenue, timeline).
Jumat: menulis dan mereview dokumen — update PRD, decision record, dan roadmap Now-Next-Later.

Perhatikan polanya: sebagian besar aktivitas adalah menerjemahkan dan memutuskan, bukan memproduksi kode ataupun desain visual. Waktu terbesar habis untuk artefak tertulis dan percakapan berkualitas tinggi.

#Konteks 2026: Kenapa Peran Ini Makin Dicari

Tiga gelombang membuat demand TPM naik tajam:

Gelombang produk AI/LLM: hampir semua company menambahkan fitur AI, dan kegagalan paling mahal terjadi di lapisan teknis — hallucination, latency, cost inference — bukan di mockup Figma. Keputusan seperti "pakai model besar atau small model fine-tuned" adalah keputusan produk.
Platformisasi: banyak perusahaan bertransformasi dari aplikasi menjadi platform/API; menjual API butuh TPM yang paham developer experience dan versioning.
Tekanan reliability & cost: di ekonomi yang lebih ketat, uptime dan unit economics jadi bahasan board; butuh orang yang bisa menghubungkan error budget dengan revenue.

Akibatnya profil hybrid — engineer yang belajar produk, atau PM yang serius belajar teknis — jadi salah satu profil paling dicari. Series ini dirancang persis untuk jalur tersebut.

Warning

Jebakan paling umum TPM baru: ikut melakukan pekerjaan eng lead (mengatur tiket harian) sampai lupa pekerjaan strategisnya. Kalau kalender kalian penuh administikatif dan hampir tidak ada jam untuk discovery, data, dan penulisan dokumen — peran kalian sedang erosi diam-diam.

#Mitos vs Kenyataan

Untuk menutup pembahasan peran, empat mitos yang layak diluruskan sejak awal:

Mitos	Kenyataan
TPM harus bisa menulis kode produksi	Cukup membaca alur kode dan diagram; judgment lebih penting dari syntax
TPM adalah PM junior yang belum siap	Jalur paralel dari engineering; banyak Senior TPM lebih senior dari PM di tim sama
TPM hanya ada di company besar	Startup API/platform justru paling butuh karena constraint teknis langsung jadi risiko bisnis
Sukses TPM = fitur rilis tepat waktu	Sukses TPM = keputusan teknis-bisnis berkualitas, termasuk yang menghentikan proyek salah

Mitos terakhir patut digarisbawahi: kontribusi terbesar seorang TPM kadang adalah menghentikan kerja yang salah lebih awal — sesuatu yang tidak terlihat di roadmap mana pun tetapi menyelamatkan satu kuartal penuh kapasitas tim.

Note

Tidak yakin jalur TPM cocok untukmu? Uji murahnya: ambil satu fitur kecil di pekerjaanmu sekarang, tuliskan trade-off teknis-bisnisnya satu halaman, lalu minta pendapat eng lead dan PM. Reaksi mereka menjawab lebih jujur daripada artikel karier mana pun.

#Penutup

Inti yang harus dibawa pulang:

TPM menjembatani product goals dengan technical feasibility, dan ikut memutuskan — bukan sekadar meneruskan pesan.
Batas perannya jelas: dalam tapi tanpa otoritas kode (beda dengan eng lead) dan berorientasi nilai bisnis (beda dengan architect).
Lima sinyal organisasi butuh TPM: produk API, arsitektur yang mengunci produk, enterprise customers, komunikasi yang sering meleset, dan produk AI.
Era 2026 — AI products, platformisasi, tekanan reliability & cost — membuat profil hybrid ini makin bernilai.

Di episode 2 selanjutnya kita masuk fase strategi: Technical Strategy & Vision — bagaimana menyusun tech product vision yang tidak sekadar slogan, menghubungkan company goals dengan technical bets, dan menyusun roadmap Now-Next-Later yang dipercaya engineering. Sampai jumpa di episode 2!