Presentasi di Indonesia Product Conference? | Glenn Rumindo
Berdiri di depan ratusan product people paling senior di Indonesia Product Conference, pertanyaannya bukan lagi soal insight baru apa yang bisa dibagikan — tapi soal kalibrasi apa yang bisa dipicu.
Bagi Glenn Rumindo, Head of Product at Adira Finance, presentasi yang berhasil bukan yang meninggalkan audiens dengan jawaban lengkap, melainkan yang meninggalkan pertanyaan yang bikin mereka mempertanyakan ulang cara kerja yang selama ini dianggap normal.
Jadi, apa rasanya presentasi di Indonesia Product Conference?
"Buat gue, presentasi yang bagus itu ninggalin pertanyaan, bukan cuma jawaban. Kalau habis sesi orang balik ke timnya dan mulai mempertanyakan satu cara kerja yang selama ini dianggap normal, itu udah berhasil."
Glenn Rumindo
T& (T&DON): Di conference seperti IPC, apa yang bikin sebuah presentasi terasa worth listening to buat audiens yang sudah expert?
GR (Glenn Rumindo): Ini datang dari pengalaman gue sendiri sebagai audiens. Kalau gue datang ke sebuah sesi, biasanya bukan buat sekadar nambah pengetahuan, tapi buat kalibrasi. Pertanyaan di kepala gue: cara kerja gue selama ini udah bener belum, sih? Atau ada orang lain yang udah nemu approach yang lebih masuk akal? Jadi yang bikin sebuah sesi layak didengerin itu bukan cuma insight-nya, tapi action-nya. Insight sekarang udah gampang banget didapat. Micro insight aja bisa kita dapat dari social media tiap hari. Yang jarang dibagi itu, "what we gonna do?" setelah punya insight tersebut. Step by step-nya kayak gimana, dan trade-off apa yang diambil di tiap langkah. Bagian trade-off ini yang hampir selalu di-skip, padahal justru paling useful. Dan buat gue, presentasi yang bagus itu ninggalin pertanyaan, bukan cuma jawaban. Kalau habis sesi orang balik ke timnya dan mulai mempertanyakan satu cara kerja yang selama ini dianggap normal, itu udah berhasil.
T&: Seberapa jauh technical detail perlu masuk supaya tetap practical, tapi nggak kehilangan audiens?
GR: Buat gue, patokannya bukan seberapa dalam, tapi seberapa relevan technical detail itu sama keputusan atau action needed yang lagi audiens hadapi. Technical detail layak masuk kalau tanpa itu orang nggak bisa ngerti kenapa sebuah keputusan diambil. Cara gue nyaringnya sederhana: tiap slide gue tanya, ini kepakai buat orang mutusin sesuatu Senin depan atau nggak? Kalau iya, masuk. Kalau cuma bikin kagum, keluar. Contohnya di sesi kemarin, gue tetap tunjukin tools dan tahapannya karena tanpa itu framework-nya jadi ngambang. Tapi, gue nggak masuk terlalu dalam ke urusan implementasi event taxonomy atau struktur data. Yang perlu diingat juga, di conference seperti IPC, audiens-nya campur. Ada yang udah sangat senior, ada yang baru setahun jadi PM, dan mereka datang dari industri yang beda-beda. Jadi, gue biasanya bawa satu lapis konsep yang semua orang bisa pegang, lalu contoh konkretnya baru gue turunin ke konteks yang lebih detail. Yang senior dapat detailnya, yang lain tetap dapat kerangkanya. Dan sisanya bisa disimpan buat Q&A atau obrolan setelah sesi. Justru di situ diskusi teknis paling berguna, karena orang nanya sesuai konteks masing-masing. Panggung itu buat ngasih arah, bukan buat transfer semua yang lo tahu.
T&: Dalam product development, real-world challenge apa yang menurut kamu paling penting dibawa ke panggung?
GR: Masalah paling real bukan soal ide atau eksekusi, tapi soal 'why'. Kita sebenarnya mau menyelesaikan apa, dan kenapa itu yang harus diselesaikan sekarang? Kedengarannya basic, tapi ini yang paling sering dilewati karena biasanya semua orang buru-buru jump to solution. Padahal begitu why-nya jelas, itu akan jadi good input buat semua proses di belakangnya. Dan good input inilah yang bakal ngasih high quality outcome. Alignment juga jadi lebih gampang karena semua orang udah on the same page soal problem statement yang mau diselesaikan. Debat yang tadinya muter-muter soal initiative atau feature bisa berubah jadi diskusi soal cara paling efektif menyelesaikan masalah yang sama. Case study biasanya mulai dari "We identified problem X," padahal realitanya lo baru sampai ke problem X setelah berbulan-bulan tarik-ulur soal siapa yang sebenarnya punya masalah itu dan kenapa itu penting. Ini yang justru layak dibawa ke panggung. Bukan karena inspiratif, tapi karena realistis. Bahkan saat mencari hypothesis lewat data, kalau why-nya masih unclear, perspective-nya juga bisa tidak sesuai. Ini yang sering nggak kelihatan di case study. Sebaliknya, kalau why-nya belum beres, mau serapi apa pun datanya tetap bisa jadi bahan debat, bukan bahan ambil keputusan.
T&: Framework atau cara kerja apa yang kamu bawa ke presentasi karena memang kepakai sehari-hari?
GR: Yang paling konsisten gue pakai adalah "start with why". Bukan cuma pas nyusun roadmap atau PRD, tapi sampai ke cara gue nyusun slide. Di deck IPC kemarin pun urutannya sama: gue taruh problem statement dan pain points-nya dulu, baru masuk ke solusi. Balik lagi ke prinsip tadi, good inputs equal high quality outcomes. Kalau problem statement-nya udah tajam, solusinya biasanya ngikut sendiri. Nah, buat sampai ke why yang beneran crystal clear, gue pakai first-principle thinking. Jadi why-nya gue breakdown sampai ke paling bawah: user sebenarnya lagi mau menyelesaikan apa? Kenapa cara yang ada sekarang belum cukup? Mana yang beneran fakta vs. asumsi, yang kita inherit dari roadmap quarterly lalu atau dari kompetitor? Sering kali begitu di-breakdown sampai situ, solusinya ternyata jauh lebih sederhana. Atau malah ketahuan memang nggak perlu di-build. Ini framework yang gue pakai untuk product decisions. Yang kedua, ada satu urutan pertanyaan yang tiap minggu gue lempar ke tim: kita ini lagi, nggak tahu what's happening? Udah tahu tapi belum tahu kenapa (Visibility ke Insight)? Atau udah tahu kenapa dan tinggal pilih action (Foresight)? Kenapa ini practical? Karena tiga kondisi itu butuh effort yang beda jauh. Tim sering pengen lompat ke tahap tiga, padahal masih nyangkut di tahap satu. Sekali pertanyaan ini dilempar di ruangan, diskusi prioritisasi biasanya kelar jauh lebih cepat. Orang jadi sadar apakah mereka lagi minta sesuatu yang fondasinya sudah firm, belum firm, atau bahkan belum ada.
T&: Kalau ada satu hal yang paling relevan buat product team hari ini, bagian mana yang paling kamu ingin mereka bawa pulang?
GR: Kalau harus milih satu: fakta bahwa sebagian besar fitur yang kita bangun ternyata jarang, atau bahkan nggak pernah dipakai user. Ini yang gue taruh di slide "Product Development Dilemma". Datanya dari Pendo, mereka menganalisis penggunaan fitur di ratusan produk software dan menemukan bahwa 80% fitur itu rarely or never used. Buat gue, itu bukan statistik buat nakut-nakutin, tapi cermin. Dan ini berlaku juga ke tim gue. Praktisnya, coba geser cara ngukur diri. Bukan dari berapa banyak yang berhasil di-ship, tapi dari berapa banyak yang beneran dipakai. Begitu ukurannya diganti, cara kerjanya ikut berubah. Fitur yang akhirnya nggak kepakai biasanya bukan karena eksekusinya jelek, tapi karena dari awal problem statement-nya memang belum jelas. Lo jadi lebih rela drop ide, lebih berani nunda, dan lebih sering nanya, "kalau ini nggak dipakai, kita tahunya dari mana?" Dan itu balik lagi ke why tadi.
3 practical tips we can learn from Glenn's experience:
1. Bantu audiens ambil keputusan.
Sebelum masukin slide, tanya: ini bantu orang ambil keputusan Senin depan nggak? Kalau cuma bikin kagum tapi nggak kepakai, mending keluar.
2. Mulai dari "why"-nya dulu.
Sebelum ngomongin solusi, pastikan problem yang mau dibahas benar-benar jelas. Jangan sampe lompat ke kesimpulan tanpa pijakan yang jelas.
3. Simpan detail teknis di momen yang tepat.
Panggung utama buat kasih arah. Detail yang terlalu spesifik bisa dibawa ke Q&A atau diskusi setelah sesi.
