founder-led-content

創業者主導のコンテンツ

「マーケティング」をする必要はありません。開発者がその課題について信頼を寄せる人になればよいのです。製品ではなくカテゴリーを売り込み、専門性で人々を引きつけましょう。

こんなときに使います： コンテンツに胡散臭さを感じて避けている、ブログが変更履歴になっている、または自社が沈黙して製品を送り出す間に、競合がひそかに頼れる情報発信者になりつつあるとき。

核となる考え方

開発者は技術的な深さ、誠実さ、確かな見解を評価し、洗練されていても中身のないコンテンツには厳しい目を向けます。必要なのは宣伝ではなく、教育です。課題に関する信頼できる専門家となり、この分野が今後どう進むのかについて立場を明確にすれば、製品は当然の選択肢として自然に売れていきます。

プロダクトマーケットフィットに至る前に、これができるのは創業者だけです。後に採用する2人目の人材はDevRelであり、今ではありません。

フレームワーク：権威ある立場の確立（Frankl）

• 製品ページだけでなく、課題そのものを自分の領域にする。講演、投稿、分析記事、独自の主張を発信します。
• カテゴリーを売り込む： 課題を教え、「このようなツール」の必要性を説明し、結果を共有します。こちらから積極的に売り込んではいけません（開発者は警戒します）。
• 業界が今後どう進むのかについて、実際の見解を持ちましょう。信頼される専門家には意見があります。ベンダーにあるのは機能です。

「O'Reillyの書籍」コンテンツ計画（Frankl）： 自分の課題について決定版となる本を想像してみましょう。全10章、それぞれに約10の節があるとします。つまり、心から役に立つコンテンツが約100本できる計算です。その構成に沿って継続的に公開します。自分の専門性を確立するための本を書くのです。

フレームワーク：コンテンツとGitHubを配信経路として活用する（Czakon）

• 課題の領域について教える（DigitalOceanモデル）：読者が購入しなくても役立つチュートリアルや詳しい解説を作ります。宣伝より、好奇心を満たすことを優先します。
• OSS／開発者向けツールでは、READMEが実質的なランディングページです：概要（1行）→ 存在する理由 → 5分以内のクイックスタート → コピーして使える例 → バッジ／ソーシャルプルーフ。開発者はWebサイトではなくREADMEを見て判断します。
• リポジトリのSEO： 実際に検索される語句をリポジトリ名、説明、トピックに入れます。開発者（とGoogle）は課題のキーワードでリポジトリを見つけます。
• 洗練さより誠実さ： 一人称で、率直に、透明性を持って書きます。粗削りでも誠実な投稿は、見栄えがよくても中身のない投稿に勝ります。

次に何を書くかの判断フロー

Do you have a real, contrarian-but-true opinion about your problem space?
├─ YES → write that. POV posts build authority fastest.
└─ NO  → write the tutorial you wish existed when you hit this problem.
         (Useful-to-a-stranger is the bar. If it only helps someone who already bought, rewrite it.)

もっともらしく見える間違い

• 変更履歴をコンテンツにする：「Xをリリースしました」は物語にも、人を引きつける要素にもなりません（Franklいわく、機能はニュースではありません。顧客の成功がニュースです）。
• 「喜んでお知らせします」： リリースについてあなたがどう感じているかなど、誰も気にしません。
• 中身より見栄えを優先する： 開発者はマーケティング臭を嗅ぎつけ、離れていきます。
• READMEをおろそかにする： 製品が優れていてもREADMEが手抜きなら、誰もコンバージョンしません。
• 一貫性がない： 3本投稿して、その後は沈黙。無理なく続けられる投稿ペースは、気合いの入った一時的な連投に勝ります。

次の30分でやること

• 自分の「O'Reillyの書籍」の構成案を描きます。課題に関する10章です。これでコンテンツのロードマップができます。
• この分野が今後どう進むのかについて、本当に信じている**見解（POV）**を1文で書きます。
• READMEを上記の構成要素に照らして確認します（概要 · 理由 · 5分以内のクイックスタート · 例 · 実績）。
• 課題に関する実際のキーワードを、リポジトリの名前、説明、トピックに入れます。

---

実際の開発者向けツールのGTM経験と、Adam Frankl（The Developer-Facing Startup）およびJakub Czakon（markepear.dev）のフレームワークをもとに作成しました。 自分ならではの切り口や、実際に続けられる投稿ペースを見つけるお手伝いが必要な場合は、LinkedInからご連絡ください。