Go-To-Marketエンジニアが実際にやっていること

誰も求人を出さなかった役割

SDRだった。1日200通のメール。スプレッドシートで手動でバイイングコミッティーを構築。テンプレートをコピペ。ドメインを間違った方法でウォーミングし、送信者レピュテーションが何かを理解する前にレピュテーションを壊した。

仕事がすべてを教えてくれた。ツールじゃない、ドメイン知識をだ。何が人を返信させるかを学んだ。アウトリーチする前にリードについて実際に必要なデータが何かを学んだ。ほとんどのアウトバウンドが失敗するのはメッセージが悪いからじゃなく、ターゲティングが雑だからだと学んだ。

そして自動化を始めた。最初はスプレッドシートの数式。次に基本的なスクリプト。そしてエンリッチメントウォーターフォール、クオリフィケーションロジック、自動ルーティングを備えた完全なパイプライン。SDRの仕事はなくならなかった。自分が寝ている間に動くシステムに圧縮された。

それがGo-To-Marketエンジニアだ。実務から得た部族知識をインフラに変換した人間。セールスについて本で読んだ開発者じゃない。コーディングを学んだマーケターじゃない。クリックすることに疲れたオペレーターだ。

評価レイヤー

どんなエンゲージメントでも最初にやるのはスタックの評価だ。ブランド名や価格ページじゃなく、自動化の天井で。

すべてのツールをMCP + CLIリトマステストにかける。3つのレベル: APIはあるか? CLIはあるか? MCPサーバーを提供しているか? GUI専用に留まるツールには天井がある。クリックする人を増やすことはできるが、プロセスをスケールすることはできない。

次にコスト透明性を見る。ほとんどのチームは、リードあたり、キャンペーンあたり、パイプラインドルあたりの支出を把握していない。10,000クレジットを買って、アトリビューションなしに消えていくのを見ている。すべてのエンゲージメントの最初の週にクレジットトラッキングを導入する。キャンペーンごとの支出をアウトカムと並べて記録するシンプルな層だ。キャンペーンAは2000クレジット消費して8件のミーティング。キャンペーンBは3000クレジット消費して2件。見えれば判断は明白だ。

3つ目はストレージアーキテクチャだ。ほとんどのGTMチームはエンリッチメントを複利する資産ではなくキャンペーンごとの経費として扱う。前四半期に500リードをエンリッチした。200人が今四半期と重複している。2回支払ったことになる。データレイクアプローチは、エンリッチメントをキャンペーンごとにリセットされるコストではなく、時間とともに複利する投資に変える。

エージェンシーギャップ

ほぼすべてのエンゲージメントで同じパターンが見える。会社はエージェンシーを雇った。エージェンシーはキャンペーンを実行する。キャンペーンはアクティビティを生む。アクティビティはパイプラインではない。

構造的な問題はインセンティブの整合性だ。エージェンシーはキャンペーンの出荷数に対して請求し、パイプラインの生成量には請求しない。彼らの指標に最適化しているのであって、あなたの指標じゃない。悪意じゃない。ビジネスモデルのミスマッチだ。

十分なスタックを監査してパターンが見えた後にエージェンシー評価チェックリストを作った。リアルなインフラを構築するエージェンシーと汎用プレイブックを実行するエージェンシーを区別する8つの質問。ツールのログインは誰が所有しているか? データはエクスポートできるか? ワークフローはドキュメント化されているか?

最大の危険信号はワークスペースの所有権だ。エージェンシーが自分たちのアカウントで自分たちのログインを使ってキャンペーンを実行しているなら、あなたは何も所有していない。2年分のアウトバウンドデータ、キャンペーンパフォーマンス、エンリッチメント結果、すべてが他人のインフラに存在している。離れたら、ゼロからのスタートだ。

これはエージェンシーへの批判じゃない。優秀なところもある。チェックリストが存在するのは、ほとんどの創業者がどんな質問をすべきか知らないからだ。

独立モデル

エージェンシーではなく独立コンサルタントとして働く理由は構造的なものだ。

エージェンシーは依存性を通じてクライアントを維持する。クライアントが自力で運用できないからリテイナーが続く。私は初日からクライアントのアカウント上に構築する。すべてのログイン、すべてのワークフロー、すべてのデータがクライアントのものだ。ドキュメントはシステム構築と同時に書かれる。事後じゃない。エンゲージメントが終わるとき、クライアントは完全な所有権を持つ稼働中のシステムを手にしている。

明確な終了点がある。スタックを監査し、ツールを推奨し、インフラを構築し、所有権を移譲し、去る。メンテナンスのための継続リテイナーなし。継続課金を正当化するための四半期レビューなし。独立して稼働するものを構築したか、しなかったかだ。

ツール評価フレームワークも同じ原則を適用する。パートナーシップやコミッションに基づいてツールを推奨しない。クライアントのボリューム、予算、技術力に合うものを推奨する。それがClayのときもある。スプレッドシートとApolloのときもある。新しいものを何も買う必要がないときもある。

その独立性が価値だ。同じ部族知識。誰かのリテイナーじゃなく、あなたの成果に整合している。