「プロダクトは語る」と思っていた個人開発者が陥る 3 つの誤算
ローンチした。X で告知した。Product Hunt にも出した。一週間でアクセスは伸びず、二週間で止まった。一ヶ月後、アナリティクスを開く頻度が減った。三ヶ月後、別のアイデアに取りかかった。
個人開発のサイクルは、しばしばこの形で終わります。プロダクトに重大な欠陥があったわけではない。技術的にも動いていた。設計も悪くなかった。それでも、伝わらなかった。
伝わらなかった理由を、つい「宣伝不足」と片付けたくなります。しかしその手前に、もっと根深い前提のずれがあります。「プロダクトを完成させれば、価値は自然に語られはじめる」── この幻想です。
この記事では、その幻想が個人開発者の頭の中で 3 つの誤算として現れる様子を、順に書いていきます。
誤算 1：「設計の正しさ」と「読み手の関心」を取り違える
個人開発者は、プロダクトを作り込む過程で、解いている問題を 設計の解像度 で理解していきます。なぜこのデータ構造なのか、なぜこの UX なのか、なぜここで非同期にしているのか。これは作り手として正しい思考です。
ただ、その解像度のままトップページを書くと、こうなります。
「タスクとプロジェクトを横断する関係を、グラフ構造で柔軟にモデル化する次世代の管理ツール」
書いた本人にとっては、正確な一文です。設計上の選択がすべて凝縮されている。
問題は、初対面の人の頭の中には、その背景がひとつも入っていないことです。「タスクとプロジェクトの横断」が解いている不満が見えない。「グラフ構造」がどんな体験を生むのか想像がつかない。「次世代」が何の代を更新したのか分からない。
設計の正しさは、作り手の中で完結します。読み手の関心は、その人の今日の不満からしか起こりません。この 2 つは別物です。設計の言葉で書かれたトップページは、設計を理解できる人 ── つまり、作り手とほぼ同じ思考をする人 ── にしか刺さりません。
個人開発者がここで取り違えるのは、「正しく書くこと」と「伝わるように書くこと」が違うという事実です。正確さでは伝わりません。読み手の今日の状態から逆算しないと、文は届きません。
誤算 2：機能が増えれば、刺さる場所も増えると思う
ローンチ直後は、機能はシンプルです。トップページのコピーも、自然と「これができます」の一行で書ける。
数ヶ月運用すると、機能は増えます。ユーザー要望に応えた小さな機能、A/B のために追加した分岐、別ドメインへの拡張。プロダクトは育ち、メニューが横に伸びていきます。
このタイミングで、多くの個人開発者がトップページのコピーをこう改修します。
「タスク管理・プロジェクト連携・ファイル共有・チームチャット・自動化フロー ── すべてが、ひとつの画面で」
機能が増えた以上、訴求も増やすべき、という直感です。各機能にそれぞれ「刺さる人」がいるはずだ、と。
ですが現実には、機能を並べれば並べるほど、どの人にも中途半端に刺さる文章が出来上がります。タスク管理だけを欲しい人にとっては「他にもいろいろあるけど、自分にはオーバースペックかもしれない」と読まれる。チームチャットを探している人にとっては「タスク管理が主軸っぽいから、専用ツールの方がよさそう」と読まれる。
機能のリストは、書き手にとっての網羅性であって、読み手にとっての関心ではありません。読み手は機能リストを見て自分用かどうかを判断するのではなく、「自分のいまの不満が、ここで解けるか」を一瞬で判断します。判断材料は、機能の数ではなく、一行目の解像度です。
成熟したプロダクトほど、トップページの一行は 削る方向 に進める必要があります。機能が増えたのに見出しが膨らんだとき、それはほぼ確実に、伝達力を下げています。
誤算 3：「いいプロダクトなら自然に広まる」と思う
3 つ目は、もっとも根が深い誤算です。
「マーケティングなど不要だ。本当にいいものは、ユーザーが勝手に語ってくれる」── 個人開発者の界隈で、繰り返し見かける言葉です。気持ちは分かります。プロダクトを作っている時間が長いほど、その言葉に救われたくなる。
ただ、この「いい」は、ほぼ常に 作り手から見た「いい」 です。
ユーザーから見た「いい」は、ぜんぜん違う場所にあります。ユーザーは、プロダクトの設計の美しさを評価しません。コードの綺麗さも、抽象化の妥当性も、データ構造の正しさも、見ません。ユーザーが評価するのは、「自分の今日の不満が、これで消えたか」 その一点です。
そして、ユーザーが「これで消えた」と気づくためには、まずプロダクトに辿り着き、最初の 3 秒で「これは自分の問題を解いてくれそうだ」と判断し、登録のハードルを越え、最初の操作で価値を体感する、までを通過する必要があります。
この最初の関門 ── プロダクトに辿り着いた人の頭の中に「これは自分用だ」を 3 秒で立ち上げる仕事 ── は、プロダクト本体ではできません。プロダクト本体ができるのは、入った人を満足させることまでです。入る前の人を呼び込み、「これは自分用かも」と思わせるのは、プロダクトの外側にある言葉 ── つまりコピーの仕事です。
「いいプロダクトなら自然に広まる」が正しいのは、ユーザーが触り始めた後の話です。触り始める前の人にとって、プロダクトはまだ存在していません。広まる前に、入り口で立ち止まる。多くの個人開発が頓挫する場所は、ここです。
本当の壁：プロダクトは沈黙する
3 つの誤算には、共通の根があります。
プロダクトは、それ単体では沈黙している ── この事実を見落としていることです。
機能は語りません。設計の正しさも、コードの美しさも、UX の洗練も、それ自体は何も発しません。プロダクトを取り囲む言葉が、それらを「価値」として翻訳して初めて、外側の人に届きます。
これはコピーライティングの本に書かれていることと同じ話なのですが、個人開発者がハマりやすいのは、作り手こそが、その翻訳を一番やりにくい立場にいる点です。プロダクトの中身が見えすぎている人ほど、「説明しなくても分かる」と感じてしまう。設計の意図が頭の中で完璧に動いている人ほど、初対面の人の頭の真っ白さを想像できなくなります。
つまり、個人開発者が WHY ── なぜコピーが必要なのか ── を腑に落とさないと、いくらプロダクトを作り込んでも、入り口で人が立ち止まる構造は変わりません。
この WHY が腑に落ちると、3 つの誤算は自然に解けます。設計の言葉ではなく読み手の今日の不満から書く（誤算 1）。機能の網羅ではなく一行目の解像度を上げる（誤算 2）。プロダクトの外側にコピーがあって初めて、いいプロダクトは広まり始める（誤算 3）。
姉妹記事として、コピーライティングを学んでも売れない人の 3 つの誤解、Claude や ChatGPT にコピーを書かせても伝わらない 3 つの理由、そして 「無料で十分」と消えていくユーザーをめぐる、3 つの誤算 を書いています。1 本目は「学びながらつまずく」3 つ、2 本目は「AI 時代特有の構造的な落とし穴」、3 本目は「フリーミアムで価格と無料の境界につまずく」3 つを扱っています。本記事の「作る側でつまずく」3 つと合わせて読むと、個人開発者がコピーで立ち止まる WHY が、4 軸で立体的に見えてきます。
そして、初対面の人がトップページを読み飛ばす構造そのものを掘ったのが 個人開発者のサービスが「素通り」される、たったひとつの構造的な理由 です。
まとめ：作る前に、書ける自分になる
ローンチの一週間前に LP を書くのではなく、作り始める前に、自分のプロダクトを読み手の言葉で説明できる自分になっておく ── これが、個人開発で一番効くタイミングです。
書けないまま作り始めると、3 ヶ月かけて誰にも伝わらない LP を書く未来が来ます。書ける状態になってから作り始めると、ローンチ初日のトップページに、迷わず一行を置けます。
順番が逆になりがちなのは、コピーが「最後に整える作業」のように見えるからです。違います。コピーは、プロダクトの輪郭を、作り手の頭の中に最初に立ち上げる作業でもあります。
プロダクトは沈黙します。語るのは、いつも書き手です。
WHY を順に腑に落とし、そのあと AI を相棒にして HOW を回せるところまでを 1 冊にまとめたのが、下記の本です。個人開発者・インディー Web 作者・動画作者向けに、LP・短文・メールの戦場別の書き方と、Claude を実際に使ったプロンプト連鎖の実演を含めて統合しています。