know-if-its-working について
開発者向けツールのスタートアップを対象に、GTM の成長状況を評価し、優先して改善する点を選ぶマーケティングスキルです。開発者の継続率を重視し、DREAM 指標、アトリビューションの考え方、判断手順を示します。
主な機能
- 01月ごとの開発者コホート継続率の追跡
- 02DREAM 指標による各段階の測定
- 03週末で初回価値までの時間を検証
- 04傾向を手掛かりにしたアトリビューション
- 05継続率とチャネル実績に基づく優先順位付け
活用シーン
- 01新規ユーザーが戻ってくるかの確認
- 02評価・活性化段階の離脱箇所の特定
- 03獲得施策を増やす時期の判断
- 04開発者の登録時に流入元を収集
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ aidevgtm/ gtm-cofounder --skill know-if-its-workingインストール後、Claude Code で/know-if-its-workingを入力して読み込まれたか確認します。
詳細
機能しているかを知る
初期に重要な指標は、開発者の純継続率だけです。これがなければ、ファネルを運用しているのではなく、底の抜けたザルを使っているようなものです。
こんなときに使います: GitHub のスター数やページビューを追っているのに「GTM は機能しているのか?」と答えられない場合や、獲得に力を注ぐ一方で、新規ユーザーがひっそりと離脱している場合です。
核心となる考え方
ユーザーが戻ってこなければ、獲得に価値はありません。まず継続率を証明してから、獲得への投資を検討します。初期の創業者の多くは、ファネルの下部から漏れているのに、上部の最適化に取り組みます。順序を正しましょう。
フレームワーク:開発者の純継続率(Frankl)
1 か月目に初めて製品を使った開発者のうち、2 か月目、3 か月目にも使ったのは何人ですか?
- 100% を超える状態を維持します(既存コホートが社内紹介や利用拡大を通じて成長することを意味します)。
- 継続率が十分に高まるまでは、獲得に注力しないでください。底の抜けたバケツに水を注ぐことになります。
- このコホートに関する一つの問いから、見栄えだけのあらゆるグラフを合わせた以上のことが分かります。
フレームワーク:DREAM 指標(Frankl)
ページビューやスター数ではなく、各段階で信頼できる指標を一つ測定します。
| 段階 | 重要な指標 |
|---|---|
| 認知 | 月間のユニークな人間の訪問者数 |
| 調査 | ニュースレター登録者数+コミュニティ参加者数+フォロワー数 |
| 評価 | 無料プランの登録数/ダウンロード数/無料ユーザーのアクティブ数 |
| 活性化 | 月間アクティブユーザー数 · 利用頻度 · セッションの深さ |
| 参加 | コミュニティで積極的に投稿し、回答するメンバー数 |
**これらすべてに先立つ関門、週末テスト:**新しい開発者がサポートへの問い合わせなしで、ドキュメントと Stack Overflow を使い、週末のうちに最初の価値を得られますか?価値実現までの時間の目標は、**理想は 1 時間未満、最長でも 1 日です。**ここで評価や活性化に失敗するなら、どのチャネルに取り組んでも効果はありません。
成長ベンチマーク(ARR 以外、Frankl)
- **プレシード:**月間ユーザー成長率約 30%
- **シリーズ A 後:**月間成長率(MoM)約 10%
- **ARR 100 万ドル達成:**12 か月以内なら良好、9 か月なら優秀
フレームワーク:アトリビューションの考え方(Czakon)
開発者向けマーケティングは**アトリビューションが難しく、それが普通です。**ある開発者が HN の投稿を見て、チュートリアルを読み、2 か月間ひそかに様子を見てから、直接登録することもあります。
- ラストタッチを過信しないでください。「direct/organic」と表示され、本当に効果のあった取り組みが隠れてしまいます。
- 自由記述の**「どこで知りましたか?」**という項目を追加します。自己申告によるアトリビューションのほうが、壊れたモデルより信頼できます。
- 根拠のない精密さではなく、傾向と方向性を示すシグナルでチャネルを評価します。
判断フロー:最初に何を改善するか
Is month-2 cohort retention healthy (users come back)?
├─ NO → STOP optimizing acquisition. Fix Evaluation/Activation (the weekend test, time-to-value).
└─ YES → is a channel reliably producing retained users?
├─ YES → pour more in (and only now consider paid to amplify).
└─ NO → go back to first-50-users; find the channel before scaling spend.
もっともらしく見える間違い
- **見栄えだけの指標:**スター数、ページビュー、インプレッション数。進歩しているように感じますが、何も予測しません。
- **底の抜けたバケツへのユーザー獲得:**二度と戻ってこないユーザーを獲得すること。
- **正確なアトリビューションを求める:**方向性を示すシグナルに基づいて行動する代わりに、完璧なモデルを追い求めること。
- **週末テストを無視する:**最初の価値を得たところで途絶える、美しいファネルを作ること。
次の 30 分でやること
- 数字を一つ計算します。8 週間前に初めて使った開発者のうち、直近 2 週間にも使った人は何%ですか?
- DREAM の各段階で信頼できる指標を一つ選び、ダッシュボードから見栄えだけのグラフを削除します。
- 自分で初めて使うつもりで、オンボーディングにかかる時間を計ります。1 時間を超えますか?それが GTM における最大の課題です。
- 今週中に、登録時に「どこで知りましたか?」という項目を追加します。
実際の開発者向けツールの GTM 経験と、Adam Frankl(The Developer-Facing Startup)および Jakub Czakon(markepear.dev)のフレームワークをもとに作成しています。 数字が読めないストーリーを語っているなら、一緒に見てくれる人を探しましょう。LinkedIn からご連絡ください。