Product Management
Inside Product Minds: How I Think About Product in 2026
Sembilan pertanyaan soal AI, judgment, strategy, framework, leadership, dan gimana gw melihat cara membangun product di 2026.

Pengaturan membacaAtur tampilan dan dengarkan artikel
Dibacakan dengan voice Bahasa Indonesia terbaik yang tersedia di perangkat ini.
Beberapa waktu lalu gw diajak Apiary Academy untuk jadi salah satu product person yang di-feature di campaign Inside Product Minds, bagian dari rangkaian Indonesia Product Conference 2026.
Gw dikasih beberapa pertanyaan seputar Product Management, AI, strategy, decision making, sampai gimana menurut gw role PM mulai berubah sekarang.
Jawaban original-nya sebenarnya gw tulis dalam Bahasa Inggris.
Sebagian kemudian dipilih, dipendekin, dan diadaptasi lagi buat format campaign mereka di Instagram.
Which makes sense.
Kayaknya gak ada juga yang pengen baca beberapa halaman ocehan gw di dalam carousel Instagram.
Tapi karena versi panjangnya sudah terlanjur gw tulis, sayang juga kalau akhirnya cuma hidup di Google Docs.
Jadi ya sekalian gw simpan di sini.
Ini bukan pandangan definitif tentang Product Management.
Bukan juga prediksi bahwa industri pasti akan bergerak persis seperti yang gw bilang.
Lebih ke snapshot tentang gimana gw melihat beberapa hal sekarang, setelah beberapa tahun bikin product, kerja di beberapa jenis organisasi, ketemu orang yang berbeda-beda, bikin kesalahan, berubah pikiran, dan melihat role Product Manager sendiri terus berkembang.
1. Di era AI-native products, skill Product Management apa yang justru jadi semakin penting dan sulit digantikan AI?
Menurut gw salah satu yang justru semakin penting adalah judgment.
AI sekarang sudah bisa bantu banyak hal.
Generate ide.
Summarize data.
Bikin prototype.
Nulis dokumentasi.
Bahkan sekarang coding pun bisa dibantu cukup jauh.
Tapi AI belum tentu benar-benar memahami seluruh konteks di balik product yang kita bangun.
Business-nya seperti apa.
Organisasinya seperti apa.
User-nya siapa.
Constraint teknisnya apa.
Political reality di dalam organisasi seperti apa.
Trade-off apa yang sebenarnya sedang terjadi.
Makanya menurut gw skill PM yang akan semakin valuable bukan sekadar hafal framework atau bisa nulis requirement yang bagus.
Tapi kemampuan buat memahami problem sebenarnya, memisahkan signal dari noise, challenge assumption, lalu menentukan apa yang memang layak dibangun.
Karena ketika biaya untuk menghasilkan solution semakin murah, kemampuan memilih problem yang tepat justru semakin penting.
Mungkin pertanyaan utama di era AI-native nanti bukan lagi:
Bisa gak kita bikin ini?
Tapi lebih ke:
Perlu gak kita bikin ini? Buat siapa? Dan kenapa sekarang?
Dan menurut gw judgment seperti itu masih sangat manusiawi.
2. Sekarang semua orang ngomongin AI features. Kapan sebuah product memang butuh AI, dan kapan sebenarnya gak perlu?
Jawaban paling sederhananya menurut gw:
Product butuh AI kalau AI memang membuat problem yang mau kita selesaikan jadi lebih baik.
Bukan karena tiba-tiba ada orang di meeting yang nanya:
AI feature kita mana?
Menurut gw AI masuk akal ketika problem-nya melibatkan ambiguity, data tidak terstruktur dalam jumlah besar, personalization, prediction, pattern recognition, atau sesuatu yang kalau dikerjakan manusia secara manual bakal makan waktu terlalu banyak.
Tapi kalau problem-nya sebenarnya bisa diselesaikan pakai deterministic rule, filter sederhana, UX yang lebih baik, atau bahkan cuma dengan memperbaiki flow existing yang rusak, ya gw kemungkinan besar akan mulai dari situ.
Kadang kita suka overcomplicate sesuatu karena AI kedengarannya jauh lebih exciting dibanding memperbaiki hal-hal fundamental yang boring.
Dan gw paham sih.
Kalimat:
We built an AI-powered experience.
jelas terdengar lebih seksi di deck dibanding:
Kita benerin filtering logic yang rusak.
Tapi user kemungkinan besar gak peduli.
Gw mending punya product boring yang menyelesaikan problem dengan sangat baik dibanding product dengan label AI-powered tapi sebenarnya gak ada yang ngerti kenapa AI harus ada di situ.
AI itu tool.
Tool yang sangat powerful.
Tapi objective-nya tetap menyelesaikan problem.
Bukan membuktikan bahwa kita berhasil memasukkan AI ke architecture.
3. Siapa yang paling mempengaruhi cara gw berpikir dan memimpin sebagai product professional?
Gw gak merasa punya satu role model yang pengen gw copy mentah-mentah.
Cara gw berpikir sekarang lebih banyak terbentuk dari orang-orang yang benar-benar pernah kerja bareng gw, ditambah beberapa ide yang entah kenapa nempel cukup lama di kepala.
Salah satunya The Lean Startup dari Eric Ries.
Buku itu cukup mempengaruhi cara gw melihat proses membangun product.
Kalau kita bahkan belum tahu apakah sebuah hypothesis benar, belum tentu kita harus langsung mulai dari versi yang kompleks atau investment yang besar.
Kadang pendekatan yang lebih masuk akal adalah bikin versi paling kecil yang cukup buat menjawab:
Asumsi kita ini sebenarnya benar gak sih?
Lalu ada orang-orang yang pernah kerja bareng gw.
Pak Qodri, former manager gw di Erajaya, cukup banyak ngajarin gw tentang empowering a team.
Kasih orang trust.
Delegasikan ownership yang beneran.
Kasih ruang buat orang berpikir sendiri daripada semua hal harus dikontrol sampai detail terkecil.
Salah satu hal yang gw suka juga, kami bisa disagree dan debat cukup terbuka tanpa harus menjadikan disagreement itu personal.
Menurut gw pengalaman kayak begitu malah lebih banyak membentuk cara gw melihat leadership dibanding banyak framework leadership yang pernah gw baca.
Lalu ada Jonathan, salah satu product leader yang pernah kerja bareng gw di Moladin.
Dari dia gw cukup banyak belajar hal lain:
Jangan terlalu cepat lompat ke solution.
Jangan jadi Yes Man.
Dan jangan takut challenge sebuah request kalau problem-nya sendiri bahkan belum clear.
Kami juga cukup sering debat.
Dan menurut gw itu sehat.
Di sisi lain...
gw juga cukup banyak belajar dari orang-orang yang gw gak pengen jadi seperti mereka.
Gw sudah cukup sering melihat bahwa title yang tinggi gak otomatis berarti judgment seseorang juga bagus.
Apalagi kalau seseorang masuk ke diskusi dalam keadaan sudah yakin dirinya benar, gak benar-benar mendengarkan, gak mencoba memahami context dengan cukup dalam, dan hampir gak memberi ruang ke orang-orang yang sebenarnya lebih dekat dengan problem untuk challenge assumption-nya.
Pengalaman seperti itu justru ngajarin gw sesuatu tentang leadership:
Semakin senior seseorang, seharusnya semakin besar juga kemauannya untuk mendengar dan memahami. Bukan malah semakin kecil.
Jadi kalau ditanya siapa yang membentuk product philosophy gw, jawabannya mungkin bukan satu orang.
Lebih kayak campuran dari buku, good leaders, difficult people, debat, kesalahan sendiri, dan beberapa tahun melihat apa yang benar-benar terjadi ketika situasinya mulai messy.
4. Di tengah budaya kerja yang semakin async dan remote, gimana caranya menjaga product alignment antar-team?
Buat gw, asynchronous work cuma bisa jalan kalau context-nya ditulis dengan benar.
Kalau product decision penting cuma hidup di dalam meeting, percakapan chat, atau kepala seseorang, lama-lama orang pasti punya interpretasi yang berbeda soal sebenarnya kita lagi membangun apa dan kenapa.
Makanya sebisa mungkin hal-hal penting dibuat explicit.
Problem apa yang sebenarnya sedang kita selesaikan?
Kenapa kita mengerjakannya?
Asumsinya apa?
Constraint-nya apa?
Decision apa yang akhirnya diambil?
Dan kadang yang gak kalah penting:
Apa yang secara sadar kita putuskan untuk gak dikerjakan?
Menurut gw alignment bukan berarti semua orang harus hadir di semua meeting.
Bahkan hadir di meeting yang sama pun belum tentu berarti semua orang aligned.
Bisa aja lima orang duduk satu jam di call yang sama, lalu selesai meeting masing-masing pulang dengan tiga interpretasi yang berbeda.
Buat gw alignment yang bagus itu ketika seseorang membuka dokumentasi dua minggu kemudian dan masih bisa memahami:
Oh, ternyata waktu itu kita milih keputusan ini karena alasan itu.
Written context juga jadi jauh lebih penting ketika ada orang yang gak ikut diskusi awalnya, baru join project beberapa bulan kemudian, atau ya simplemente semua orang sudah lupa detail keputusan yang dibuat setengah tahun lalu.
Tapi async juga bukan berarti:
Jangan pernah ngobrol.
Kalau topiknya complicated, controversial, emotionally sensitive, atau diskusinya sudah berubah jadi lima puluh message bolak-balik tanpa progress, kadang ngobrol lima belas menit memang jauh lebih efektif.
Tujuannya bukan menghilangkan meeting.
Cuma jangan menjadikan synchronous communication sebagai default solution untuk semua communication problem.
5. Apa satu kebiasaan kecil yang menurut gw punya impact cukup besar ke kualitas decision making?
Tanya satu pertanyaan sangat sederhana sebelum mulai bahas solution:
Sebenarnya problem apa yang lagi kita coba selesaikan?
Kedengarannya painfully basic.
Tapi gw cukup sering lihat diskusi langsung lompat ke feature, design, atau technical solution bahkan sebelum semua orang sepakat problem-nya apa.
Seseorang bilang:
Kita butuh filter baru.
Yang lain bilang:
Coba kasih AI recommendation.
Orang lain mulai ngomongin API.
Sepuluh menit kemudian baru sadar ternyata semua orang lagi menyelesaikan problem yang berbeda.
Bisa jadi problem sebenarnya adalah user susah menemukan category tertentu.
Atau search relevance-nya jelek.
Atau ternyata masalahnya inventory availability.
Atau discovery sama sekali gak bermasalah dan problem sebenarnya terjadi jauh lebih bawah di funnel.
Kalau problem-nya belum aligned, hampir semua solution bisa terdengar masuk akal.
Karena sebenarnya masing-masing orang sedang menjawab pertanyaan yang berbeda.
Pertanyaan sederhana tadi memaksa semua orang menyamakan mental model terlebih dahulu.
Dan menurut gw cukup banyak unnecessary product complexity yang sebenarnya bisa dicegah kalau kita konsisten melakukan itu.
6. Apa satu tren Product Management yang menurut gw mulai muncul di 2026?
Menurut gw boundary antara PM, designer, dan engineer mulai semakin blur, terutama di exploration phase.
Dengan AI coding tools, prototyping tools, dan agents sekarang, PM sudah bisa pergi jauh lebih jauh dibanding sekadar nulis requirement atau gambar box di Figma.
Lo bisa test API.
Query data.
Bikin prototype.
Simulate flow.
Bikin internal tool sederhana.
Atau kadang bikin cukup banyak dari idenya sendiri sampai kita punya sesuatu yang bisa diuji sebelum meminta engineering team invest effort yang jauh lebih besar.
Menurut gw ini bukan berarti PM harus berubah jadi engineer.
Bukan itu poinnya.
Yang menarik adalah cost untuk mengubah ide menjadi sesuatu yang tangible sekarang semakin rendah.
Dulu PM mungkin menjelaskan ide dan bikin mockup.
Setelah itu engineering dan design masih perlu effort cukup besar sebelum semua orang bisa benar-benar berinteraksi dengan ide tersebut.
Sekarang gap itu semakin pendek.
Makanya menurut gw expectation perlahan juga akan bergerak dari:
Can you explain the idea?
menjadi:
Can you show me?
Dan personally, gw cukup suka direction itu.
Prototype yang bisa disentuh sering jauh lebih cepat mengekspos assumption yang salah dibanding debat panjang tentang kira-kira nanti feature-nya akan terasa seperti apa.
7. Kalau cuma boleh kasih satu nasihat ke Product People generasi berikutnya, apa yang akan gw bilang?
Jangan jadi framework collector. Belajar cara berpikir.
Framework itu berguna.
RICE.
JTBD.
OKR.
Prioritization matrix.
Discovery framework.
Semuanya bisa membantu.
Tapi problem product di dunia nyata hampir gak pernah datang dalam bentuk case study yang sudah rapi.
Biasanya yang kita dapat justru:
Informasi setengah-setengah.
Requirement gak jelas.
Stakeholder yang maunya beda-beda.
Technical constraint.
User behavior yang aneh.
Resource terbatas.
Dan kadang orang yang gak terlalu ngerti problem atau complexity di baliknya, tapi tetap rajin bertanya:
Kapan selesai?
Dan belum tentu nadanya ramah juga.
Nah, justru di situ product thinking menurut gw mulai kepakai.
Lo harus bisa bertanya.
Menyusun sesuatu yang ambiguous jadi lebih terstruktur.
Challenge assumption.
Estimate sesuatu.
Memahami trade-off.
Lalu mengubah situasi yang berantakan menjadi sesuatu yang cukup jelas untuk benar-benar dikerjakan oleh team.
Lo juga butuh pemahaman yang cukup tentang business, user, data, dan technology supaya bisa tahu kapan sebuah timeline masih realistis, kapan sesuatu butuh investigation lebih lanjut, dan kapan jawaban yang paling benar justru:
Kita belum tahu.
Karena kerja sebagai PM di dunia nyata bukan soal membuka textbook lalu memilih framework yang paling cocok dengan bab yang sedang dibahas.
Lebih sering kita harus mencoba memahami:
messy problems, messy organizations, dan kadang messy human behavior.
Framework seharusnya membantu cara kita berpikir.
Bukan menggantikannya.
8. Kalau gw diminta ngajar kelas tentang product strategy, tiga hal apa yang pasti gw bahas?
Yang pertama:
Pahami problem sebelum memilih solution
Surprisingly banyak bad product decisions dimulai karena team jatuh cinta terlalu cepat sama solution.
Diskusinya dimulai dari:
Kita bikin X aja.
Bukan dari:
Sebenarnya apa yang terjadi, dan kenapa?
Begitu orang sudah terlalu attached ke suatu solution, discovery kadang diam-diam berubah fungsi.
Bukan lagi untuk mencari tahu apa yang benar.
Tapi mencari evidence yang bisa membenarkan sesuatu yang dari awal memang sudah pengen dibangun.
Jadi gw akan mulai dari sana.
Understand the problem first.
Yang kedua:
Trade-offs dan prioritization
Strategy bukan cuma menentukan apa yang mau kita bangun.
Strategy juga soal menentukan apa yang rela kita gak bangun.
At least for now.
Resource terbatas.
Engineering capacity terbatas.
Attention terbatas.
Bahkan kemampuan organisasi buat menyerap perubahan juga terbatas.
Kalau semuanya priority, basically gak ada yang benar-benar priority.
Lalu yang ketiga:
Context lebih penting daripada framework
Strategy yang brilliant di satu company bisa jadi completely stupid ketika dipakai di company lain.
Karena user-nya beda.
Business model-nya beda.
Technology-nya beda.
Distribution-nya beda.
Organizational capability-nya beda.
Timing-nya beda.
Constraint-nya beda.
Jarang sekali ada satu product strategy yang universally correct.
Biasanya yang ada adalah:
strategy yang paling masuk akal berdasarkan context yang kita punya saat itu.
Dan menurut gw distinction itu penting.
9. Apa framework, tool, atau cara kerja baru di 2026 yang paling mengubah cara gw membangun product?
Buat gw bukan satu framework tertentu.
Lebih ke AI-assisted building sebagai bagian dari product discovery.
Traditional flow dulu kurang lebih:
idea → requirement → design → development → test
Realitanya tentu gak pernah sebersih itu.
Tapi tetap ada jarak yang lumayan besar antara punya ide sampai akhirnya punya sesuatu yang bisa benar-benar disentuh dan dicoba.
Sekarang jarak itu semakin pendek.
PM bisa mulai dari hypothesis.
Generate prototype.
Connect mock data atau bahkan real data.
Test interaction.
Lalu membahas sesuatu yang sudah tangible bareng engineering dan design dalam waktu yang jauh lebih singkat.
Dan menurut gw itu mengubah kualitas conversation.
Daripada satu jam debat:
Kalau feature ini dibikin kira-kira rasanya gimana ya?
Kadang lebih baik pakai dua puluh menit buat bikin rough version-nya.
Begitu dicoba, kita langsung bisa lihat apa yang salah.
Flow-nya ternyata awkward.
Assumption tertentu ternyata gak masuk akal.
Bagian yang kita kira technically complicated ternyata gak terlalu penting.
Atau malah ternyata feature-nya memang gak useful.
Feedback loop itu yang menurut gw menarik.
Gw sebenarnya gak terlalu excited sama AI cuma karena sekarang kita bisa menghasilkan lebih banyak artifact.
Yang lebih menarik buat gw adalah ketika AI bisa memperpendek jarak antara sebuah hypothesis dan proses belajar apakah hypothesis tersebut masuk akal atau enggak.
Dan feeling gw, feedback loop seperti itu bakal jauh lebih valuable dibanding fancy Product Management framework apa pun yang kebetulan lagi populer tahun depan.
Setelah baca ulang semua jawaban ini
Pas gw baca semuanya sekaligus, gw baru sadar sebenarnya ada satu benang merah yang muncul berkali-kali.
Gw cukup peduli sama konsep thinking before doing.
Pahami problem sebelum memilih solution.
Pahami context sebelum menerapkan framework.
Pertanyakan apakah sesuatu memang layak dibangun sebelum sibuk memikirkan apakah secara teknis kita bisa membangunnya.
Tuliskan context penting daripada berasumsi semua orang akan selalu ingat.
Gunakan AI untuk memperpendek learning loop, bukan cuma untuk menghasilkan lebih banyak benda.
Dan nyaman dengan kemungkinan bahwa kadang jawaban paling benar memang:
Kita belum tahu.
Mungkin itu juga alasan kenapa semakin lama gw semakin gak terlalu tertarik melihat Product Management cuma sebagai kumpulan process dan artifact.
Bukan berarti semua itu gak penting.
PRD tetap berguna ketika memang dibutuhkan.
Analytics penting.
Roadmap penting.
Prototype penting.
Framework juga jelas bisa membantu.
Tapi gak ada satu pun dari benda-benda itu yang bisa mengambil keputusan buat kita.
Pada akhirnya tetap harus ada seseorang yang melihat informasi yang gak lengkap, kepentingan yang saling bertabrakan, resource terbatas, technical reality, user behavior, dan organizational constraints lalu mencoba menjawab:
Dengan semua yang kita tahu sekarang, sebenarnya apa yang paling masuk akal?
Buat gw itu salah satu bagian paling menarik dari kerjaan ini.
Dan mungkin juga bagian yang sampai sekarang masih terus gw coba pelajari.
Sedikit terima kasih juga buat Apiary Academy dan team di balik Indonesia Product Conference yang sudah ngajak gw menjadi salah satu product person yang di-feature dalam campaign Inside Product Minds.
Lumayan juga, gara-gara pertanyaan mereka gw jadi punya alasan buat duduk dan benar-benar menuliskan beberapa hal yang selama ini sebenarnya sudah ada di kepala, terutama soal gimana Product Management berubah, apa yang AI ubah dan gak ubah, dan hal-hal apa yang menurut gw tetap penting ketika tools di sekitar kita terus berkembang.
Seperti gw mention di awal, jawaban original untuk campaign ini sebenarnya gw tulis dalam Bahasa Inggris. Versi yang dipublish di Instagram kemudian diringkas dan diadaptasi supaya lebih cocok dengan format carousel.
Post Instagram di bawah adalah versi yang akhirnya dipublish sebagai bagian dari campaign tersebut.
Jadi anggap aja post-nya sebagai summarized version.
Sementara tulisan ini adalah versi director's cut yang kepanjangan.
Kalau lo kerja di product atau sekadar tertarik melihat perspektif orang-orang lain di industri product Indonesia, menurut gw worth checking juga apa yang sedang dibangun Apiary Academy lewat Indonesia Product Conference dan campaign seperti Inside Product Minds ini.
Thanks again buat team-nya sudah ngajak gw ikut jadi bagian kecil dari campaign ini.