わかるよ、その気持ち。これは、プロダクト開発に携わる人なら誰もが経験する「日常的な苦痛」だね。まるで、永遠に追いつけないバスを追いかけているようなものだ。もうすぐ手が届きそうになったと思ったら、また少し先に進んでしまう。
まず言っておくけど、これは君のせいじゃないし、君のプロダクトが特に不運なわけでもない。この業界ではよくあることで、「スコープクリープ」という専門用語まであるんだ。
例を挙げれば、すぐにわかるだろう。
最初は、雨風をしのげる小さな小屋を建てようと思っていたとする。作業を始めたら、「ああ、窓をつけたら明るくなるな」と思う。次に、「壁は白く塗ろうか？」と考える。「床も張らないとね？」「床を張るなら、床暖房もつけようか？」「床暖房をつけるなら、屋根瓦も良いものにしないと？」……結局、1ヶ月で小屋を建てるつもりだったのに、半年が過ぎ、未完成の「豪華な別荘」の基礎を前に途方に暮れている、という状況だ。
君のプロダクトのリリース計画も、この「小屋が別荘になる」過程と同じなんだ。
この問題を引き起こす原因は、だいたい以下のいくつかだ。
-
完璧を追求し、「もっと良くしたい」と常に思うこと：これが最大の落とし穴だ。「この機能はまだ使いにくい」「あのUIはもっと最適化できる」「もしユーザーに気に入られなかったらどうしよう？」と常に考えてしまう。その結果、修正や新機能の追加を繰り返し、一度に最高のプロダクトを出そうとする。しかし現実には、最初のバージョンで完璧なプロダクトなど存在しない。今や素晴らしいWeChatやTaobaoも、初期バージョンは非常にシンプルだった。重要なのは、まず「世に出した」ということだ。
-
「最小実行可能製品」（MVP）の概念が欠けていること：これは非常に重要な考え方だ。つまり、最初のバージョンのプロダクトでは、あらゆる人のあらゆるニーズを満たそうと考えるべきではない。最も核となる機能で、最も核となるユーザーの「最も痛い課題」を解決するだけで良い。例えば、コミュニティアプリを作りたいとして、最初からライブ配信、ECサイト、ショート動画、DMなどを盛り込もうとしないこと。まずは「同じ興味を持つ人が投稿でき、コメントできる」という核となる機能だけをしっかり作り、リリースすれば良い。最初のユーザーを獲得し、彼らの本当のフィードバックを聞いてから、次に何をすべきかを決めよう。
-
作業量の見積もりが楽観的すぎること：ある機能について、「ボタンを一つ追加して、バックエンドにデータを保存するだけだから、1週間で終わるだろう」と考えてしまうことがある。実際にやってみると、様々な例外ケースを考慮したり、テストを行ったり、異なるスマートフォンに対応させたり、データベースを設計したりと、多くの作業が必要だと気づく。実際にかかる時間は、見積もりの3倍以上になることさえある。
どうすればいいのか？
落ち込む必要はない。これは不治の病ではなく、処方箋がある。
-
心を鬼にして、機能を削る：現在計画している機能をリストアップし、削り始めよう。自分に問いかけてみてほしい。「もし最初のバージョンにこの機能がなくても、私のプロダクトは死ぬだろうか？」もし答えが「死なない、ただ少しクールじゃないだけだ」というなら、迷わずその機能を削除するか、第2版、第3版の計画に回そう。覚えておいてほしい。君の目標は「リリースすること」であり、「完璧にリリースすること」ではない。
-
明確なV1.0を定義する：私の1.0バージョンには、A、B、Cの3つの機能が含まれ、UIはここまで、使用に支障のないバグがなければ完成とする、と明確に書き出そう。そして、「X月X日、何があってもリリースする」といったデッドラインを設定する。このデッドラインが君のゴールラインとなり、取捨選択を迫るだろう。
-
不完全を受け入れ、迅速にイテレーションする：リリースを「終わり」ではなく「始まり」と捉えよう。プロダクトがリリースされて初めて、市場の本当の評価が得られる。ユーザーからのフィードバックは、君が一人で100個の機能を考えるよりもはるかに貴重だ。早くリリースし、早く悪い評価（そう、悪い評価は非常に重要だ！）を受け取ることで、どこを改善すべきかがわかる。そして、次のバージョンを迅速にリリースして最適化しよう。これが「小さく始めて、速くイテレーションする」ということだ。
だから、君のプロダクト計画が「永遠に」遅れているわけではなく、よくあるサイクルに陥っているだけなんだ。君がすべきことは、車をより豪華にすることではなく、まず4つのタイヤとエンジンを取り付けて、走れるようにすることだ。まずは走り出し、走りながら直していけばいい。