SaaS

Anda merilis setiap dua pekan dan menulis tentangnya dua kali setahun

Tim perangkat lunak tidak kekurangan hal untuk dikatakan. Mereka kekurangan orang yang mengatakannya, karena menulis selalu menjadi tugas yang digeser ketika rilis terlambat — dan digeser setiap kali, sampai postingan terbaru blog berumur sebelas bulan dan berbunyi "memperkenalkan".

Kegagalannya struktural, bukan editorial

Setiap tim tahu bahwa mereka seharusnya menulis lebih banyak. Para insinyur bisa menulis; pendiri bisa menulis; biasanya ada seseorang yang menikmatinya. Masalahnya, menulis tidak punya tenggat sendiri, dan apa pun tanpa tenggat kalah oleh apa pun yang punya tenggat, setiap dua pekan, selamanya.

Sebuah rencana menyediakan tenggat yang hilang itu. Slot bertanggal dengan tema dan penulis yang ditetapkan adalah komitmen yang dibuat pada pekan yang tenang, diterapkan pada pekan yang tidak tenang, dan drafnya muncul entah ada yang ingat atau tidak. Menyetujuinya butuh beberapa menit; menulisnya dari nol butuh satu sore yang tidak pernah datang.

Itulah seluruh argumennya. Bukan karena sebuah model menulis lebih baik daripada tim Anda — tidak. Melainkan karena draf yang Anda sunting pada hari Selasa itu ada, sedangkan postingan yang Anda niatkan untuk ditulis tidak ada.

Roadmap adalah rencana yang sudah Anda tulis

Sebagian besar dari enam bulan itu sudah diputuskan. Anda tahu kira-kira apa yang dirilis dalam dua kuartal berikutnya, bagian produk mana yang sering disalahpahami, integrasi apa yang terus diminta orang, dan pertanyaan apa yang datang ke dukungan setiap pekan tanpa gagal.

Masing-masing itu adalah sebuah tema. Roadmap menyediakan kadensinya — satu rilis menjadi rangkaian slot, bukan satu entri changelog — dan dukungan menyediakan separuh evergreen-nya, karena pertanyaan yang diajukan dua puluh kali sebulan adalah tulisan yang layak ditulis sekali dan ditautkan selamanya.

Sisakan celah. Rilis bisa mundur, dan rencana tanpa slot kosong mengubah satu rilis yang mundur menjadi tiga postingan tentang sesuatu yang belum ada. Seperempat slot yang dibiarkan terbuka bukanlah kelonggaran berlebih; itu bagian dari rencana yang bertahan saat bertemu jadwal Anda yang sesungguhnya.

Cara kerja musiman dan celah →

Satu rilis, tiga postinganIlustrasi

1Blogday 0Apa yang dirilis dan mengapa itu ada. Masalahnya dulu, fiturnya kemudian.
2Facebook / Instagramday 0–2Versi satu kalimat, untuk orang yang tidak akan pernah membuka changelog.
3Blogday 12Bagaimana seseorang benar-benar memakainya. Konkret, dengan bagian canggungnya tetap disertakan.
·Jika melesetSlot-slotnya bergerak mengikuti rilis. Tidak ada yang mengumumkan sesuatu yang tidak ada.
4BlogevergreenPertanyaan dukungan yang akhirnya dijawab oleh rilis ini, ditulis sekali saja.

Roadmap menentukan iramanyaDukungan menentukan temanya

Changelog Anda bukan konten. Itu adalah bukti.

Dua penulis, kadang tiga

Yang menjelaskan produk, dan yang membicarakan perusahaan

Itu memang dua suara yang berbeda, dan menggabungkannya menghasilkan kehambaran khas yang dikenal dari blog perangkat lunak — sebuah tulisan yang bukan penjelasan teknis dan bukan pula kisah manusiawi tentang apa pun.

Penulis teknis

Menjelaskan apa yang dilakukan suatu fitur, secara tepat, tanpa kata sifat. Tahu untuk apa produk Anda dan bukan untuk apa, dan diizinkan mengatakannya. Inilah penulis yang tulisannya ditautkan dari tiket dukungan.

Suara perusahaan

Menulis tentang keputusan, pertimbangan, dan apa yang Anda tuju. Berguna dengan cara yang sulit diukur namun jelas terlihat dalam perekrutan, dalam panggilan penjualan, dan dalam alasan seseorang memilih vendor kecil dibanding yang besar.

Yang menjawab

Menangani komentar sesuai kebijakan Anda. Menjawab yang bisa dijawab, menandai yang tidak bisa, dan tidak pernah berspekulasi tentang roadmap. Apa pun yang menyerupai insiden dukungan langsung diteruskan ke manusia.

Gerbang persetujuan di sini benar-benar berfungsi

Untuk toko roti, tulisan yang belum disetujui hanyalah kejijikan kecil. Bagi perusahaan perangkat lunak, itu beban dukungan, keberatan penjualan, atau komitmen yang tidak disetujui siapa pun. Draf yang sedikit salah menggambarkan suatu batasan akan dikutip kembali oleh pelanggan, dan draf yang mengisyaratkan tanggal akan dianggap sebagai janji.

Karena itu, inilah kasus yang paling membutuhkan kehati-hatian pada autopilot. Susunan yang masuk akal adalah autopilot untuk slot sosial singkat yang mengulang sesuatu yang sudah dipublikasikan, dan persetujuan untuk semua yang membuat klaim tentang produk. Apa pun tentang harga, kapasitas, atau tanggal harus dibaca oleh manusia secara permanen, dan ada baiknya menuliskannya dalam aturan penulis agar draf semacam itu ditahan dan ditandai, bukan masuk antrean.

Apa yang laporan sampaikan kepada tim kecil

Rencana versus terpublikasi adalah angka yang paling penting, dan bagi tim perangkat lunak angka itu biasanya tidak nyaman di kuartal pertama. Itu juga satu-satunya ukuran jujur apakah penulisan berhenti kalah oleh rilis.

Penerimaan tidak sepenting kelihatannya. Tulisan teknis menemukan pembacanya dalam hitungan bulan, bukan hari, dan menilainya di minggu kedua akan membuat Anda memensiunkan tulisan yang sebenarnya akan berhasil. Keseimbangan tema lebih berguna di awal: itu menunjukkan apakah Anda hanya menulis tentang yang sudah dirilis, yang merupakan mode kegagalan standar dan alasan begitu banyak blog perangkat lunak terbaca seperti changelog dengan paragraf.

Bagian jujurnya: jika produk Anda memang teknis, tulisan yang terdalam tetap membutuhkan seorang insinyur selama satu sore. Yang berubah dengan sebuah rencana adalah sore-sore itu menjadi terjadwal, dan delapan puluh persen penulisan lainnya berhenti bersaing dengannya.