新機能をどう発表するか(沈黙にしないために)

ほとんどの新機能の発表は、誰も二度と読まないチャネルで死んでいく。流れて消えていくツイート、その週に購読者が受け取った他の十二通の下に埋もれたリリース日のメール、チームの半分が数か月前にミュートしたチャネルのSlackメッセージ。機能はリリースされた。それを使ったであろう人のほとんどはそれを知らなかった。これを直すことは、より良い発表を書くこととはあまり関係がなく、むしろ正しい読者のために正しいチャネルを選ぶこと、そして一般的なメッセージに気づいてくれることに頼るのではなく、明示的に求めていた人々に直接届けることに関係している。

新機能は実際どこで発表されるべきか

一つ以上の場所でだ。なぜなら「みんな同じチャネルを読んでいる」は決して真実ではないからだ。チェンジログやフィードのエントリは、自分のペースで確認し、永続的で日付付きの記録を求める読者に応える。アプリ内通知は、すでに製品を使っていて、その存在を知れば今日にでもその機能を使うであろう読者に応える。メールは、現在製品にいないが、正しい更新のために戻ってくるであろう読者に応える。SNSは、既存の利用者を超えたリーチに、ほとんどターゲティングなしで応える。

四つのどれも単独では十分ではない。チェンジログは、サイズにかかわらずすべてのリリースを運ぶべき唯一の文書だ。なぜなら、他のすべてがそこに立ち戻る記録だからだ。他の三つは、その機能が実際にどれだけ大きいかによって選ばれる、上に加えられた増幅にすぎない。

発表は最初に何を言うべきか

メカニズムではなく結果だ。「レポートのエンドポイントにキャッシュ層を追加した」はチームが作ったものを説明している。「レポートは1秒未満で読み込まれるようになった」は読者にとって何が変わったかを説明していて、これがクリックを獲得する文だ。なぜなら、三番目の節ではなく最初の節で「これで自分に何の得があるか」に答えているからだ。メカニズムはチェンジログのエントリか詳細ページに属し、見出しには属さない。

形容詞より具体性を先に。「より速く、より強力なレポート体験」は読者に行動できる何も伝えない。「レポートは1秒未満で読み込まれ、ステータスでフィルタできるようになった」は何が変わり、何を試すべきかを正確に伝える。二番目のバージョンはより信頼できるようにも見える。なぜなら曖昧な主張は、具体的に言うことが何もないときのマーケティング文とまったく同じように聞こえるからだ。

製品アップデートのメールとどう違うのか

重なるが、同一ではない。製品アップデートのメールは、頻度、件名、そしてダイジェストが単発の送信に勝るタイミングを含め、メールのチャネルを具体的に扱っている。新機能の発表は根底にある出来事であり、メールはそれを運びうる上記四つのチャネルの一つで、機能が次のダイジェストに乗るのではなく専用の送信を正当化するのに十分大きいときに選ばれる。小さな機能はチェンジログのエントリと、おそらくアプリ内通知に値する。重要な機能は、時間的に調整された四つのチャネルすべてに値する。

それを求めた具体的な人々にどう届けるか

これは労力対効果が最も良い発表であり、ほとんどすべてのチームがそれを飛ばしてしまう。十人の顧客が名指しで機能を求めたなら、その十人は、外に出るどんな広範な発表とも関係なく、リリースの瞬間に直接的で個人的なメモに値する。顧客とのフィードバックループを閉じるがその仕組みを完全に扱っている。ここでの要約は、元のリクエストがリクエストした本人と結びついたままである場合にのみこれが機能するということで、それは発表の問題というより追跡の問題だ。changeloopでは、ウィジェットのフィードバックがGitHub issueになり、マージされたpull requestがそれをクローズする（fixes #142）と、チェンジログのエントリを承認した時点でそのissueに「Shipped —

エントリ自体はどう書くのか

他のどのリリースノートのエントリとも同じ規律だ。読者が今できることから始め、必要な設定を続け、内部的な正当化を飛ばす。リリースノートの書き方が完全な方法を扱っている。新機能の発表は最も賭け金の高いケースだ。なぜなら、製品のチェンジログを一度も見たことがない誰かによってスクリーンショットされ、転送され、読まれる可能性が最も高いエントリだからだ。

いつ広く発表すべきではないのか

機能がまだアカウントの一部にロールアウト中であるとき、本当にベータであるとき、あるいは価格や制限のせいで、広範な発表の読者の十人中九人がまだそれを使えないときだ。十人中九人の読者が使えない機能の広範な発表は、餌のように読め、それが今回作る熱意よりも次回の発表への信頼を燃やしてしまう。解決策は沈黙ではなく、範囲だ。対象となるアカウントに直接知らせ、可用性が発表に追いつくまで広いチャネルを控える。

FAQ

すべての新機能は独自の発表に値するか? すべてがチェンジログのエントリに値する。誰かが製品を使う方法を変えるほど重要なもの、あるいは名指しで明示的に求められたものだけが、メールやSNSのようなより広いチャネルに値する。

小さな機能に最適なチャネルは何か? チェンジログだけ、加えて、その機能が利用者がすでにいるフローの中で発見可能なら、アプリ内通知だ。メールとSNSは、注目を求めるに値する機能に対して価値がある。

具体的にそれを求めた人々にどう機能を発表するか? 登録された瞬間からリクエストをリクエストした本人と結びつけたままにし、リリース時に、より広い発表とは別に個別に通知する。リクエストした本人が自分で確認できる共有のステータスラベルも、そもそも必要な個別メッセージの数を減らす。

機能の発表にスクリーンショットは必要か? 視覚的なものすべてについて、必要だ。説明されたが見られていない機能は、読者がプレビューを見られる機能よりもはるかに頻繁に飛ばされる。APIやバックエンドの能力については、短いコード例がUIの変更に対するスクリーンショットと同じ仕事をする。

この記事の技術的な記述は第三者による確認を受けていません。誤りがあればお知らせください。修正します。

changeloopの関連ページ： changelogの例, 開発者向けドキュメント