SaaS
2週間ごとにリリースし、年2回しか書かない
ソフトウェアチームに書くことがないわけではありません。書く人がいないのです。リリースが遅れると必ず後回しにされるのが執筆であり、毎回後回しにされる結果、ブログの最新記事が11か月前の「紹介」のままになります。
失敗は構造的なものであり、文章の問題ではない
どのチームももっと書くべきだと分かっています。エンジニアは書けますし、創業者も書けますし、楽しんでいる人も普通にいます。問題は、執筆にはそれ自身の締め切りがなく、締め切りのないものは締め切りのあるものに毎回負けるということです。2週間ごとに、永遠に。
プランは欠けた締め切りを補います。テーマと書き手が紐づいた日付付きスロットは、落ち着いた週に交わした約束であり、落ち着かない週に適用されます。誰も覚えていなくても下書きは現れます。承認には数分しかかかりませんが、ゼロから書くには永遠に来ない午後が必要です。
それが議論のすべてです。モデルがあなたのチームより上手に書くからではありません——書きません。火曜日に編集した下書きは存在し、書くつもりだった記事は存在しない、ということです。
ロードマップはすでに書いたプランです
6か月の大半はすでに決まっています。次の2四半期に何をリリースするか、製品のどの部分が誤解されているか、どの連携を何度も要望されるか、どの質問が毎週サポートに届くか。
その一つ一つがテーマです。ロードマップがリズムを提供します——リリースは1件の変更ログではなく一連のスロットになります——そしてサポートが常設の半分を提供します。月に20回聞かれる質問は、一度書けば永遠にリンクできる記事だからです。
余白を残してください。リリースは遅れます。空きスロットのないプランは、遅れたリリースを、まだ存在しないものについての3本の記事に変えてしまいます。4分の1のスロットを空けておくのは手抜きではなく、実際のスケジュールと接しても生き残る部分です。
- 1ブログ何がリリースされ、なぜ存在するのか。まず問題、次に機能。
- 2Facebook / Instagram変更ログを決して開かない人のための、1文バージョン。
- 3ブログ実際に誰かがどう使ったか。具体的に、ぎこちない部分もそのまま残して。
- ·遅れた場合スロットはリリースに合わせて動きます。存在しないものを告知することはありません。
- 4ブログ今回のリリースがついに答えるサポート上の質問を、一度だけ書きます。
ロードマップがリズムを決めるサポートがテーマを決める
変更履歴はコンテンツではありません。領収書です。
ライターは2人、ときどき3人
製品を説明する人と、会社について語る人
この2つは本当に異なる声であり、それを1つにまとめると、ソフトウェアブログ特有の味気なさが生まれます。技術的な説明でもなく、人間的な記録でもない記事になるのです。
テクニカルライター
物事が何をするのかを、形容詞を使わず正確に説明します。製品が何のためにあり、何のためでないのかを理解し、それを口にすることを許されたライターです。サポートチケットからリンクされる記事を書くのはこの人です。
会社の声
意思決定、トレードオフ、そして何に向かって作っているのかについて書きます。測りにくい形で役に立ち、採用や営業の場面、そして小さなベンダーが大きな企業に選ばれる理由において、その価値は明白です。
答える人
ポリシーに基づいてコメントを処理します。答えられるものには答え、答えられないものには印を付け、ロードマップについて決して推測しません。サポート対応に見えるものはすべて、直ちに人間に引き渡されます。
承認ゲートがここで本当に機能しています
パン屋にとって、未承認の投稿は小さな恥ずかしさで済みます。ソフトウェア会社にとっては、サポート負荷、営業上の反論、あるいは誰も同意していない約束になり得ます。制限を少し間違って記述した下書きは、顧客にそのまま引用して返され、日付をほのめかす下書きは約束として扱われます。
だからこそ、オートパイロットに最も慎重を期すべきのはこのケースです。合理的な運用は、すでに公開済みの内容を再掲する短いソーシャル投稿にはオートパイロットを使い、製品について主張するものすべてには承認を経ることです。価格、容量、日付に関するものは恒久的に人間が読むべきであり、それをライターのルールに書き込んでおけば、その種の下書きはキューに入るのではなく保留され、印が付きます。
レポートが小さなチームに伝えること
計画に対する公開数こそが重要な数字であり、ソフトウェアチームにとっては通常、最初の四半期で心地よくないものです。同時に、執筆が再びリリースに負けなくなったかを測る唯一の正直な指標でもあります。
反応は見た目ほど重要ではありません。技術的な記事は数日ではなく数か月をかけて読者を見つけるものであり、2週目で判断すると、本来うまくいくはずだった記事を引っ込めてしまうことになります。序盤にはテーマのバランスのほうが有用です。公開したものについてしか書いていないかどうかが分かるからです。これは典型的な失敗パターンであり、多くのソフトウェアブログが段落付きの変更履歴のように読める理由です。
正直な話: 製品が本当に技術的なものであれば、最も深い記事には依然としてエンジニアの半日が必要です。計画が変えるのは、その半日が予定に組み込まれ、残り8割の執筆がそれと競合しなくなるという点です。