Pahami dulu sebelum merancang
Jangan buru-buru bikin solusi sebelum ngerti problem yang sebenarnya.
TENTANG TEGAR
Gue mulai dari engineering dan entah gimana akhirnya nyasar ke product. Di tengah-tengahnya sempat ngulik IoT, mobility, education, sampai sekarang banyak berkutat di digital commerce. Industri dan kerjaannya ganti-ganti, tapi ternyata ada satu hal yang dari dulu konsisten gue suka: ngerti gimana sesuatu bekerja, kenapa dibangun seperti itu, dan apa yang perlu diubah kalau ternyata nggak bekerja dengan baik. Sekarang biasanya bentuknya jadi problem product yang lumayan messy—ketika kebutuhan user, kepentingan bisnis, data, operasional, dan keterbatasan teknis ketemu di satu tempat. Gue nggak selalu punya jawabannya dari awal. Yang penting buat gue, problem-nya cukup jelas supaya keputusan berikutnya jadi lebih gampang diambil.

SINGKATNYA
Kebanyakan problem product ternyata nggak pernah cuma soal product. Masalah di checkout aja bisa nyangkut UX, aturan payment, backend service, operasional, analytics, sampai kepentingan commercial sekaligus. Mungkin itu juga kenapa background engineering gue masih sering kebawa sampai sekarang. Biasanya gue pengen tahu dulu bagian-bagian yang terlibat, constraint-nya apa, dan problem sebenarnya ada di mana sebelum buru-buru ngomongin solusi. Gue nggak terlalu peduli siapa yang punya jawaban paling pintar di ruangan. Yang lebih penting, tim bisa sampai ke keputusan yang memang masuk akal dan bisa dijalankan.
PRINSIP KERJA
Jangan buru-buru bikin solusi sebelum ngerti problem yang sebenarnya.
Bikin secukupnya buat ngetes asumsi. Kalau memang salah, mending ketahuan dari awal.
Jangan sampai tujuan utama tenggelam gara-gara opini, ego, atau preferensi pribadi. Opini tetap boleh masuk, tapi bukan berarti otomatis benar. Balik lagi ke objective dan evidence yang kita punya.
Kalau problem-nya terasa ruwet, petakan dulu. Biasanya jauh lebih gampang dibahas kalau semua orang melihat gambaran yang sama.
Fitur jarang berdiri sendiri. Pahami dia bergantung ke apa, berdampak ke mana, dan apa yang terjadi setelah dirilis.
Data nggak mengambil keputusan buat kita. Tapi data bisa bantu kita bertanya lebih tepat dan nguji asumsi yang kita punya.
Nggak ada keputusan yang gratis. Kalau milih A, harus jelas apa yang kita korbankan dan kenapa itu masih worth it.
Begitu dirilis, asumsi akhirnya ketemu kenyataan. Lihat apa yang terjadi, pelajari, lalu perbaiki dari sana.
YANG SAYA BAWA
FOCUS AREAS
Domain produk yang paling sering muncul dalam work saya.
SKILLS & THINKING THEMES
Kemampuan dan pola pikir yang paling sering saya gunakan.
TOOLS & TECHNOLOGIES
Teknologi yang muncul di berbagai work saya, plus tools lain yang rutin saya gunakan.
DI LUAR PEKERJAAN
Rasa penasaran gue sebenarnya nggak berhenti setelah jam kerja. Cuma topiknya jadi lebih random. Kadang ngulik Raspberry Pi, bikin tools kecil yang nggak ada orang minta, baca sejarah yang entah kenapa tiba-tiba menarik, motret, atau pergi ke tempat baru cuma karena gue belum pernah ke sana. Kadang juga nyasar terlalu jauh baca soal teknologi, kota dan infrastruktur, bola, fashion, vespa, kopi, atau pertanyaan random apa pun yang kebetulan lagi ganggu kepala gue minggu itu. Kebanyakan ya nggak menghasilkan apa-apa. Sesekali malah kepake lagi buat kerjaan. Mungkin itu juga alasan gue nggak pernah benar-benar berhenti ngulik sesuatu.
NGOBROL YUK
Soal product, system, sesuatu yang lagi lo bangun, atau sekadar pengen tukar pikiran? boleh banget diobrolin.
SAY HI
Ceritain aja konteksnya secukupnya. Kalau nggak buru-buru, email paling enak. Kalau mau lebih cepat, WhatsApp biasanya lebih responsif.