Fakta: Komunikasi peluncuran produk bermasalah

Tujuan dari catatan peluncuran produk adalah untuk memberitahu tim internal Anda (dari teknik hingga dukungan pelanggan) dan pemangku kepentingan eksternal Anda (pelanggan dan mitra) bahwa telah terjadi perubahan pada produk. Di teknologi, di mana semuanya bergerak dengan kecepatan cahaya, mengirimkan pembaruan produk melalui catatan rilis sebenarnya adalah masalah yang sudah ada sejak lama.

Setiap perusahaan tempat saya bekerja telah berjuang untuk mendapatkan catatan rilis “yang benar”. Namun, ini adalah hal yang sulit untuk dilakukan dengan benar; pentingnya setiap perubahan atau peluncuran produk akan bervariasi berdasarkan audiens, bagaimana perubahan itu mengubah interaksi kelompok tertentu dengan fitur, dan bagaimana kelompok itu menggunakan produk secara keseluruhan setiap hari.

Komunikasi peluncuran produk ini (yang biasanya dikenal sebagai catatan rilis) perlu disampaikan kepada audiens yang peduli tentang berbagai hal. Sebagai pemimpin Pemberdayaan Pendapatan di Guru, konstituen saya adalah siapa pun yang kemampuannya untuk melakukan pekerjaan mereka dipengaruhi oleh peta jalan produk, termasuk:

• Tim Produk/Desain/ Teknik
• Tim Penjualan (Operasi penjualan, Penjualan dalam, Eksekutif Akun di berbagai segmen)
• Pengalaman Pelanggan (Manajer Sukses dan anggota dukungan)
• Tim Pemasaran (Pemasaran Produk, Pemasaran Pertumbuhan, Merek, Konten yang akan memimpin strategi GTM dan penjangkauan pers untuk produk tersebut)
• Pengembangan Bisnis dan Mitra

Semua mitra ini harus mencerna pembaruan produk dan segera mengetahui sejauh mana mereka perlu menerapkan pembaruan tersebut dalam pekerjaan mereka. Mereka juga perlu mempertimbangkan bagaimana mereka dapat membantu pengguna akhir memahami dampak yang akan ditimbulkan oleh setiap perubahan pada mereka.

Orang (atau tim) yang menyusun komunikasi rilis perlu mempertimbangkan semua audiens yang akan mengonsumsi pengetahuan produk. Apa implikasi dari rilis ini bagi seorang insinyur backend dibandingkan dengan calon pelanggan di industri ritel?

Bagaimana Tidak Mendekati Catatan Rilis

Meskipun sulit untuk mempertimbangkan kebutuhan dari berbagai audiens, juga tidak skalabel bagi Manajer Produk atau Manajer Pemasaran Produk (PMM) untuk menulis lima versi berbeda dari catatan rilis internal. Dalam pengalaman saya, catatan rilis biasanya terlalu panjang dan tidak terfokus atau tidak cukup teknis. Catatan rilis statis tidak memberikan wawasan ini dan sering kali ditulis untuk penulis, bukan untuk orang yang perlu memahami apa yang telah berubah. Jujur saja, mereka biasanya adalah peluang yang terlewatkan.  

Saya telah menghadiri panggilan catatan rilis mingguan yang berlangsung selama satu jam di mana suara monoton dari manajemen produk membahas poin-poin di slid. Setelah panggilan berakhir, manajer produk yang sama menerima email, panggilan telepon (ingat itu?), Slacks, dll., dari semua orang mulai dari dukungan pelanggan hingga penjualan yang ingin tahu apa arti perubahan tersebut bagi mereka, pelanggan mereka, dan calon pelanggan. Jika Anda melewatkan panggilan tersebut, Anda melewatkan nuansa dan konteks, dan hanya mendapatkan catatan perubahan mentah.

Tetapi bukan tugas manajer produk untuk melakukan terjemahan sakral ini; tugas mereka adalah membangun produk yang menyelesaikan masalah untuk pasar. Tugas PMM adalah menerjemahkan itu maksud agar pasar memahami nilainya.

Rahasia menulis catatan rilis perangkat lunak yang hebat

Saya adalah penggemar besar Sound of Music (mengejutkan, saya tahu) dan sebagai profesional pemberdayaan, pelajaran abadi dalam film itu terasa benar. "Mari kita mulai dari awal yang sangat baik, it's a very good place to start," muncul di kepala saya setiap minggu. Jadi, dalam membentuk atau membentuk kembali proses pengiriman produk, Anda harus belajar bahasanya sebelum Anda dapat mengajarkan subjeknya.

1. Kembangkan glosarium internal

Langkah pertama dari menggali proses ini adalah mendapatkan seluruh tim berbicara dengan bahasa yang sama. Menyerukan terminologi yang dibagikan terlihat jelas, tetapi mungkin tidak terjadi di seluruh organisasi Anda. Tidak mengetahui akronim dan salah memahami bahasa dapat mengasingkan, menciptakan kebingungan dan silo di seluruh tim.

Contoh: Tim pemasaran kami menggunakan istilah “peluncuran” untuk menggambarkan kapan dan bagaimana kami akan memasarkan fitur. Namun, tim teknik menggunakan kata “peluncuran” untuk menggambarkan kapan fitur telah dirilis ke lingkungan staging kami. Peluncuran fitur spesifik "selesai" untuk teknik sebelum pelanggan kami mengetahuinya. Ini membingungkan dan bertentangan secara internal.

Tidak ada yang ingin menjadi orang yang berbicara di depan umum yang mengakui bahwa mereka tidak tahu apa artinya dengan bertanya untuk definisi. Solusi kami: Dalam kelompok kerja lintas fungsi (dengan perwakilan dari teknik, produk, pemasaran produk), kami merinci nuansa tersebut dan mendokumentasikan definisi rilis produk kami:

Catatan: Jika ada Kartu yang gagal dimuat, cukup segarkan halaman!

2. Apa yang harus disertakan dalam catatan rilis Anda

Setelah bahasa yang dibagikan ditetapkan dan tim Anda dapat mengartikan terminologi rilis, Anda dapat menulis catatan Anda. Hal termudah adalah membuat template yang dapat digunakan kembali untuk menulis catatan rilis. Dengan cara ini, pemangku kepentingan menjadi akrab dengan format setelah beberapa iterasi, dan menyelamatkan Anda dari kesulitan harus menciptakan kembali roda setiap kali.

Setidaknya, catatan rilis yang baik mencakup:

• Tanggal rilis
• Internal dan eksternal
• Deskripsi fitur atau bug
• Produk yang terdampak (jika Anda memiliki lebih dari satu)
• Jika Anda memiliki beberapa produk perangkat lunak, Anda juga mungkin ingin menyertakan nomor versi
• Di mana pertanyaan dapat diajukan secara internal

Namun, catatan rilis yang baik juga mencakup:

• Pertanyaan yang sering diajukan (FAQ) yang diantisipasi
• Tautan ke dokumentasi publik baru, jika tersedia
• Untuk fitur:
• Nama fitur
• Gambar screenshot dari fitur
• Video bagaimana cara mendemokan fitur
• Mengapa fitur itu ada
• Bagaimana itu mempengaruhi persona pembeli/pelanggan yang relevan

Ini template yang kami gunakan secara internal (silakan salin!):

💡Catatan: Sangat berguna untuk menetapkan individu yang bertanggung jawab secara langsung untuk tugas ini (daripada membiarkannya sebagai upaya kelompok di mana tidak ada yang memilikinya). Manajer Teknik atau Produk harus memiliki sisi teknis dari catatan (nama/versi/produk/tanggal/screenshot), sementara Manajer Pemasaran Produk atau Insinyur Penjualan harus memiliki informasi kontekstual (persona pembeli/mengapa itu penting).

Menerapkan strategi proses pengiriman produk

Buat format komunikasi yang konsisten

Sekarang setelah Anda menyatukan terminologi dan menulis template Anda, langkah berikutnya adalah menyetujui medium pengiriman yang konsisten (misalnya: Slack, email, Loom, Guru, Google Docs) dan metodologi. Medium pengiriman yang konsisten memastikan konstituen catatan rilis Anda tahu di mana mereka harus pergi atau melihat atau berlangganan (untuk mengambil) agar mengetahui rilis.

Ini juga penting untuk manajemen perubahan karena Anda umumnya harus memberi tahu seseorang beberapa kali agar mereka sepenuhnya menyerapnya. Tergantung pada jenis rilisnya, perubahan pada UI/UX (antarmuka pengguna dan pengalaman pengguna), dan dampaknya terhadap pelanggan, audiens catatan rilis Anda perlu didorong pengetahuan produk (untuk didorong). Di Guru, kami mengadopsi metodologi dorong dan tarik.

Tarik: Di mana menemukan pengetahuan

Bagi kami, pemangku kepentingan dapat mengikuti saluran #release-notes di Slack kami, di mana ada format yang konsisten dan mudah dicerna untuk semuanya mulai dari perbaikan bug hingga fitur baru. Perlu diingat bahwa audiens masing-masing Anda tidak hanya perlu menyadari bahwa rilis sedang terjadi (melalui penarikan di Slack atau email) tetapi lebih penting, mereka perlu tahu mengapa rilis itu penting dalam konteks.

Pengetahuan bahwa rilis akan terjadi atau telah terjadi tidak berharga kecuali tim Anda dapat melakukan sesuatu dengan pengetahuan itu. Untuk mengembangkan format yang konsisten yang akan memberikan konteks yang tepat, saya mensurvei perwakilan penjualan, perwakilan pengembangan akun, orang-orang pengembangan bisnis (dan seterusnya), untuk menetapkan template pengiriman produk kami yang kami sebut “Kartu Rincian Fitur”, yang dapat Anda temukan di atas.

Ketika seorang Manajer Teknik mulai mengembangkan fitur baru, individu yang bertanggung jawab diberitahu melalui Asana untuk membuat Kartu Rincian Fitur khusus fitur menggunakan template catatan rilis. Kartu Rincian Fitur baru menjadi sumber kebenaran yang kuat atau “otak fitur” yang kami luncurkan. Para ahli materi pelajaran (SME) — seperti PMM dan insinyur penjualan — menyertakan rincian tentang mengapa rilis itu berharga, bagi siapa yang paling penting, dan di mana relevan, panduan tentang cara mendemokan fitur sebagai bagian dari cerita yang lebih besar.

Pemangku kepentingan catatan rilis, terutama Eksekutif Akun, kembali ke kartu yang sama berulang kali karena mereka telah belajar bahwa pengetahuan dinamis di Kartu Rincian Fitur itu dipercaya, relevan, dan dapat diterapkan. Audiens kini berbicara dengan bahasa yang sama dan membaca dari buku panduan (dinamis) yang sama. Kembali ke Kartu Rincian Fitur masih merupakan bagian dari metode “tarik” karena hal itu dilakukan dengan kecepatan sendiri, dan dilakukan untuk mempersiapkan panggilan penjualan atau dukungan, atau jika prospek memiliki pertanyaan tentang peta jalan.

Dorong: Memberikan pengetahuan secara proaktif

Metode Push datang ke play ketika pengetahuan tentang rilis itu sensitif terhadap waktu, dan krusial bagi tim tertentu. Di sini, ini dicapai melalui fungsi pengumuman Guru. Berdasarkan dampaknya terhadap audiens internal saya, saya mendorong sebuah pengumuman melalui Guru kepada kelompok yang relevan. Saya dapat melihat laporan tentang mereka yang telah mengakui atau membaca peringatan itu dan mengingatkan mereka yang belum.  

Mengapa budaya berbasis pengetahuan adalah kunci 🗝

Meskipun semua di atas, tidak sebenarnya sesederhana menyepakati terminologi, menulis catatan rilis yang hebat, dan menciptakan mekanisme untuk pengiriman produk yang dinamis. Tim perlu mampu berkolaborasi dalam pengetahuan dan memberikan umpan balik seiring waktu. Bagi kami, itu berarti bahwa ketika konsumen pengetahuan (dalam hal ini, pemangku kepentingan catatan rilis) memiliki pertanyaan atau belajar sesuatu yang baru, mereka berkomentar pada Kartu Rincian Fitur.

Bagi kami, itu berarti bahwa ketika konsumen pengetahuan (dalam hal ini, pemangku kepentingan catatan rilis) memiliki pertanyaan atau mempelajari sesuatu yang baru, mereka mengomentari Kartu Pembagian Fitur. Kami juga menggabungkan pertanyaan yang diajukan dan dijawab di Slack dengan memberikan komentar sebagai cara untuk terus meningkatkan pengetahuan. Ahli materi pelajaran (biasanya PMM) akan meninjau dan memasukkan pengetahuan atau pertanyaan relevan baru itu, meletakkannya dalam konteks di kartu Rincian Fitur tertentu.

Kami juga membuat semua catatan rilis kami dengan mudah diakses dengan mencantumkannya di bagian yang akan datang atau diluncurkan dari Papan Rincian Fitur kami, di mana mereka dapat lebih terorganisir secara internal. Dengan cara itu, mereka mudah diikuti dengan sekilas. Jika Anda tidak menggunakan Guru, kami merekomendasikan untuk mencoba membuat halaman catatan rilis, atau changelog yang terhubung.

Seperti proses lainnya, yang satu ini terus berkembang. Pengiriman produk dan catatan rilis tidak pernah sesederhana satu kali selesai. Seiring dengan perubahan kebutuhan bisnis Anda, proses, tanggung jawab, dan template Anda harus berubah bersamanya. Namun dengan berusaha untuk pemahaman yang mudah, konteks, dan kegunaan, Anda tidak akan kalah.