writing skill
Product Story

Pentingnya Kemampuan Menulis untuk Product Manager

Hari ini aku ingin membicarakan tentang sebuah kemampuan dasar yang wajib dimiliki oleh seorang product manager atau manager apapun itu, yakni kemampuan menulis. Mungkin sebagian orang beranggapan bahwa menulis itu sesuatu yang mudah dilakukan. Tapi nyatanya di lapangan, huh tidak banyak orang yang dapat menulis dengan baik apalagi menulis sebuah dokumen PRD.

Pemandangan ini nyata terjadi di lingkungan kerja bahkan di lingkungan rumah. Dimana ketika seseorang meminta orang lain untuk melakukan action dan menuliskannya di sebuah notes atau file doc, tetapi enggan atau-tidak-bisa menuliskan permintaannya dengan jelas.

Contoh Pertama

Ibu saya meminta tolong pada saya untuk membelikannya sesuatu, kemudian ia menulis:

Tolong, belikan gula

Hanya menulis seperti itu, tanpa ada keterangan tambahan dan ia berharap bahwa anak gadisnya ini membelikan gula sesuai dengan keinginannya.

Karena kebiasaan ia membeli gula sebanyak 1/2 kilogram, maka saya pun langsung eksekusi permintaannya itu dengan membelikan gula sebanyak 1/2 kilogram di warung terdekat. Tapi nyatanya, beliau membutuhkan gula lebih banyak yakni 1 kilogram, saya pun tidak tahu karena perintahnya hanya untuk membeli gula entah berapapun banyaknya itu.

Contoh Kedua

Kejadian ini belum lama terjadi, ada seorang rekan menulis dokumen permintaan testing dengan isi sebagai berikut

Error di halaman xx

Hanya menuliskan beberapa patah kata berharap yang menerima informasi bisa dengan jelas mengerti maksud dan tujuan dari si pemberi info. Come on! Ku bukan cenayang 🤣

Sebagai seorang tester yang teknis tentu informasi tersebut tidak cukup karena untuk menemukan akar masalah perlu dilakukan rekayasa ulang secara runut dari temuan eror tersebut. Informasi yang lengkap juga memudahkan tester tersebut menemukan pola masalah dengan cepat sehingga ia pun dapat menginformasikan kepada tim developer untuk segera memperbaikinya berdasarkan case yang telah ditemukan. Informasi yang lengkap dari tester ke developer juga akan mempermudah kerja dev untuk memperbaiki bugs dengan tepat dan cepat.

okay gif

Biasakan Menulis Menggunakan Format Ini

Saat menulis brief atau dokumen PRD, posisikan dirimu sebagai pembaca. Baca ulang tulisan di dalam file yang telah kamu buat, pastikan kamu sendiri memahami apa yang telah kamu tulis. Membaca ulang tulisan diri sendiri, dapat meminimalisir terjadinya kesalahpahaman atau menghindari kalimat bias atau yang memiliki makna ganda, dan dapat membantu si penerima informasi memahami maksud yang kita sampaikan. Setidaknya, biasakan diri untuk menulis sesuatu untuk menggunakan format 5W+H.

1. What

Ceritakan apa yang menjadi masalah atau request yang diinginkan entah itu fitur baru, enahncement fitur, dalam brief atau dokumen PRD.

2. Why

Jelaskan mengapa kamu membutuhkan sesuatu yang telah dijelaskan dalam what tersebut sehingga penerima informasi dapat mengerti bahwa kamu membutuhkan permintaan tersebut untuk segera dilakukan.

3. Where

Jelaskan dimana permintaan tersebut harus dilakukan. Misal di dalam aplikasi atau website.

4. When 

Tulis kapan tepatnya kamu ingin permintaan atau masalah tersebut dilakukan oleh penerima informasi. Kalau saya biasanya menggunakan format dd:mm:yy dan hh:mm:ss. Sesuaikan saja dengan kebutuhan.

5. Who 

Tuliskan juga keterangan kepada siapa informasi atau permintaan yang telah kamu tulis di dalam dokumen tersebut ditujukan. Misalnya sebagai product manager saya biasa menulis PRD ke tim developer dan QA untuk eksekusinya.

6. How

Tahap terakhir yang dapat mendukung suatu PRD atau brief lebih jelas yakni melampirkan HOW dari suatu case atau request sebuah fitur. Penjelasannya bisa menggunakan step by step by numbering atau lebih bagus menggunakan flow chart. LEBIH BAGUS LAGI jika ada screenshots atau wireframe/sketch (khusus untuk buat fitur atau enhancement) agar si penerima informasi lebih memahami brief yang kita tulis.

Jika dirasa keenam hal tersebut sulit dilakukan, dari pengalaman saya menggunakan what, why, when dan how juga sudah cukup asal yang dituliskan sudah jelas maksud dan tujuannya. 

Jangan Skip Komunikasi 2 Arah

Jika format penulisan yang baik dan benar serta JELAS tersebut sudah dilakukan, bukan berarti maslah telah selesai. Terkadang ada beberapa orang atau tim yang tidak cukup dengan hanya membaca dokumen penjelasan yang telah kita berikan. Terlebih pemahaman tiap orang akan suatu tulisan beda-beda, maka kita harus memaklumi bahwa penafsirannya pun akan beragam. Maka dari itu sebagai product manager jangan pernah skip untuk melakukan komunikasi kepada tim yang bersangkutan sampai akhirnya memiliki persepsi dan tujuan yang sama. 

Rangkuman 

Menulis biasa dianggap sebagai kegiatan yang sepele, ini seringkali ditemukan di berbagai lini dan tim, mau itu timnya besar ataupun tim kecil, dari start up hingga corporate. Kurangnya informasi yang disampaikan di dalam tulisan yang kita buat akan mudah sekali memicu kesalahpahaman dan konflik. Maka dari itu sebagai product manager atau manajer lainnya SANGAT PENTING UNTUK MENULIS SESUATU YANG CLEAR DAN MUDAH DIPAHAMI agar kerja dalam sebuah tim dapat dilaksanakan dengan tepat, efisien, tidak memakan banyak waktu. Jika sudah memiliki kemampuan menulis yang baik, jangan lupa juga untuk selalu mengkomunikasikannya secara verbal kepada tim terkait agar goal yang sama bisa diraih. Yuk, permudah diri sendiri dan tim yang terlibat.

Tulisan di dalam dokumen yang tidak jelas dan terlalu bertele-tele mudah menyebabkan kebingungan bagi penerima informasi dan pemrosesan untuk menerjemahkan kata-kata pun menjadi lebih lama.

Demikian tips kali ini, nantikan tulisan menarik lainnya tentang dunia product manager. Have a nice day ^^
Apa kamu punya komentar atau pengalaman yang sama? Yuk share di kolom komentar!

sumber ilustrasi

gambar1,

gambar2

1 Comment

  1. […] it and even beginners can understand easily when using figma for the first time. But for me, for product managers who not into design, I am not a fan of figma tho […]

Leave a Reply

Your email address will not be published. Required fields are marked *