Langkah sederhana untuk meminimalisir resiko Product
Minggu lalu saya membaca thread dari pak Jonathan Kho, beliau adalah seller ternama di beberapa marketplace, nama tokonya Om Botak. Disana dia menjelaskan kalau banyak barang di Dept. Store di Sabah (Malaysia), rusak karena sirkulasi udara yang kurang baik selama masa lockdown di Malaysia. Tidak lama kemudian saya melanjutkan validasi berita ini dan benar saja Kompas dan beberapa media mainstream lainnya sudah mengulas tentang isu ini.
Mungkin kasus ini hanya sebagian kecil yang terlihat akibat fase lockdown di Malaysia, yang mau tidak mau harus dilakukan untuk menekan angka penyebaran covid19 ini.
Saya jadi berpikir bagaimana dengan kursi-kursi di bioskop? Bagaimana mesin pesawat atau kendaraan yang biasanya beroperasi tapi harus bersandar di garasinya karena masa PSBB (Pembatasan Sosial Berskala Besar) ini?
Ah sudahlah, sepertinya saya akan cepat tua kalau memikirkan hal itu.
Wake-up Call untuk Seorang Product Manager
Sebagai seorang Product Manager hal diatas menjadi wake-up call buat saya. Bagaimana merancang product yang baik, terutama ketika product tersebut menghadapi hal yang tidak diharapkan? Bagaimana membantu Operation team ketika hal yang tidak diharapkan terjadi? Hingga bagaimana cara recovery dari situasi tersebut?
Kita sama-sama tahu kalau Product Manager adalah middle man dari berbagai stakeholder, misalnya tim engineer, design, business dan operation. Jadi untuk menghadapi situasi ini jangan pernah berpikir sendirian dan kurang-kurangilah berasumsi. Akan lebih baik kita ajak diskusi stakeholder terkait dan kita tentukan bersama initiative apa yang bisa dilakukan untuk menangani hal-hal yang tidak diharapkan ini. Simplenya lakukanlah collaborative problem solving.
Rencanakan dan pikirkan hal terburuk
Sebagai Product Manager pastinya kita sudah tahu dong tentang happy path dan unhappy path. Nah, untuk happy path atau flow positive-nya biasanya Product team sudah tahu betul kemana dan bagaimana product itu dapat berjalan. Tapi bagaimana dengan unhappy path?
Saya akan coba berbagi pengalaman saya ketika mengembangkan produk Tokopedia Play, sebuah produk yang menjadi main entry point ketika Tokopedia melakukan strategic campaign yang namanya “Semarak Ramadan Ekstra” (tahun 2019) di beberapa televisi nasional. Yang menjadi tekanan buat saya dan tim adalah “beberapa televisi nasional”. Itu berarti kalau produk ini sukses maka akan membawa nama baik untuk perusahaan tapi kalau gagal bisa jadi sebaliknya bukan?
Akhirnya tim yang terlibat di Semarak Ramadan Ekstra (ada Offline Marketing, Data, Business, Product, Tech dan Customer Experience team) berdiskusi tentang kemungkinan terburuk yang mungkin terjadi saat dan setelah acara Semarak Ramadan Ekstra.
Dan kami menemukan beberapa “blind spot” yang potensial menjadi masalah besar apabila tidak ditangani. Disini saya semakin menyadari pentingnya collaborative problem solving yang menurut saya harus selalu jadi sebuah kebiasaan yang baik. Apabila ini jadi sebuah kebiasaan, tim Product pun harus terbuka dengan masukan dari tim lainnya. Singkat cerita, bersyukur acara tersebut lancar dan jadi new achievement untuk tim Tokopedia Play saat itu, buat yang kepo result-nya bisa dilihat disini ya. 👌
Kesimpulan untuk point ini sebenernya simple, lakukan terus collaborative problem solving dan pastikan setiap product yang kamu kembangkan dan punya potential issue, memiliki mekanisme circuit breaker yang flow-nya cukup diterima oleh pengguna ketika terjadi error, seperti yang dilakukan GOJEK yang dibahas disini.
Jadi kalaupun user akan “failing” pastikan mereka akan “failing gracefully”.
Buat to-do listnya
Masih menyambung dengan cerita di poin sebelumnya. Ketika kita melakukan collaborative problem solving tadi pastikan didokumentasikan dengan baik, sehingga output-nya bisa menjadi sebuah action item list yang jelas.
Pada pengalaman tersebut, biasanya saya dan tim akan membagi action item yang sifatnya perlu development dan release phase atau action item yang sifatnya operational ways. Pastikan juga setiap action item itu ada nama PIC nya, untuk memberi kejelasan kepada team, pekerjaan ini akan dikerjakan oleh siapa. Dan kalau membutuhkan pengerjaan masukkan juga estimasi pengerjaannya.
Setelah pembahasan to-do list cukup jelas, tentukan estimasi waktu kapan to-do list tersebut bisa disimulasikan bersama, boleh dibilang seperti rehearsal tapi dengan scale yang kecil (internal team) dan kemudian bertahap ke scale yang lebih besar lagi. Yang akan saya bahas di poin selanjutnya.
Sebenarnya bagian ini cukup straight forward intinya kita mau set apa yang harus dikerjakan, siapa yang mengerjakan dan kapan waktu pengerjaan tersebut selesai. Ini adalah tips untuk melakukan alignment terutama kalau tim yang akan terlibat cukup luas. Semakin jelas alignment-nya akan semakin mengurangi miscommunication dan bisa kita review di waktu retrospective nantinya.
Buat yang mau tau formatnya, bisa cek disini ya! 📝
Simulasi, simulasi dan simulasi
Tibalah saatnya semua yang direncanakan akan disimulasikan. Jangan pernah kita rilis product kita ke public, tapi product itu sendiri belum pernah dicoba atau disimulasikan ke internal. Sebelum kita memulai simulasi, pastikan kita sudah booking agenda orang-orang yang terlibat agar fokus waktu tersebut hanya untuk simulasi saja. Dan pastinya rundown untuk simulasi juga disiapkan jadi usahakan simulasi semirip mungkin dengan expected condition nantinya.
Mungkin akan ada yang bertanya, “apa bedanya tahap simulasi dengan fase testing?”. Menurut saya yang membedakan disini adalah tim yang terlibat didalamnya, kalau simulasi tim yang dilibatkan lebih banyak, bukan hanya tim Tech, Product saja, tapi kalau fase testing umumnya tim yang terlibat adalah tim Tech, Product saja. Jadi kembali lagi dengan product/project-nya itu sendiri, apakah memerlukan keterlibatan yang intens dengan tim lain misal operational team atau cukup standalone feature yang sudah bisa memenuhi product goals itu sendiri.
Lalu apa sih yang waktu itu disimulasikan untuk project ini? Secara garis besar kami mensimulasikan dua hal, yang pertama adalah flow kerjasama antara team yang ada di studio televisi dengan team di kantor Tokopedia dan satu lagi kami mensimulasikan realibility dari product Tokopedia Play dengan melakukan load testing / stress testing. Tapi bukan simulasi namanya kalau kita juga tidak mensimulasikan hal-hal buruk yang sudah terpikirkan, bagaimana kerjasama yang harus dilakukan ketika hal itu terjadi. Dan bagaimana “quick heal” -nya karena “show must go on!”.
Poin ini mau menjelaskan kalau simulasi adalah proses yang penting. Terlebih lagi untuk product/project yang melibatkan banyak stakeholder karena kita perlu membangun alur kerjasama supaya pada hari-H nanti tidak kaget.
Belajar dari pengalaman waktu itu, jujur saya agak panik karena ada beberapa hal yang tidak diekspektasi terjadi plus di ruangan simulasi saat itu, ada tim manajemen yang mengikuti simulasi ini. Tapi pada akhirnya saya sadar ini hanyalah simulasi justru yang penting adalah mencatat apa yang kurang untuk segera dibahas bersama ke tim internal agar pada hari-H nya tidak terjadi lagi.
Kembali ke cerita awal ditulisan ini, dampak saat covid19 dan setelah covid19 rasanya akan menjadi tantangan untuk kita. Jadi jangan hanyut dengan pemberitaan yang ada, tapi bagaimana mengubah berita tersebut menjadi wake-up call atau bahkan peluang baru buat kita para innovator!
Tidak lupa juga akhir dari tulisan ini saya mau berterima kasih kepada Tokopedia, khususnya Squad Tokopedia Play untuk bantuan dan kerjasamanya, kalian luar biasa! 💪 🙇♂️
