個人開発者のためのロードマップ公開戦略

個人アプリにとって、ロードマップはほぼマーケティング資産です。パワーユーザーは欲しいニッチ機能が来るのか知りたい。見込み顧客はアプリがちゃんとメンテされているか知りたい。既存ユーザーは自分のフィードバックが届いたか確認したい。公開ロードマップは 1 箇所でこの 3 つに答え、ちゃんと構造化されていれば運用コストはほぼゼロです。

3 ステータスでは細かさが足りず、6 ステータスではどれがどれだか分からなくなります。ちょうど良いのは次の 4 つです:

公開ロードマップの項目に日付を書くのは、文字通り来週リリースする場合だけ。ソフトウェアは遅れます。1 回の公開遅延は、最初の約束で築いた信用以上にすぐ削ります。

代わりにコミュニケーションをバッチ化します。月 1 回、planned から in_progress へ 2〜5 件、in_progress から done へ 1〜3 件動かす。可視化された動きが、見積もりを晒さずに信頼を生みます。

全てを公開ロードマップに載せる必要はありません。大型の競合対抗ローンチ、まだスコープ詰め中の有料機能、漏洩がローンチを損なうものは内部に留めます。公開ロードマップは、コミュニティ要望と自明な増分改善のためのものです。

実用的な判定基準: フィードバックボードで 3 票以上あれば公開して安全。需要シグナルなしに自分で作っているものは、サプライズで出したほうが良いタイプの可能性が高い。

planned のまま 6 ヶ月放置になる項目もあります。それ自体は問題ありません。問題なのは「無いふり」をすることです。すぐ出せないと分かったら:

Verbr の各プロジェクトには 4 ステータスワークフロー、ステータス表示付きの公開フィードバックページ、ステータス変更時のメール通知が組み込まれています。各項目の投票数が、コミットすべき項目を判断する明確なシグナルになります。