mcpField
P
positioning-and-story

positioning-and-story

github.com/aidevgtmマーケティング・グロース329176 回インストール2 日前に更新
リポジトリ

positioning-and-story について

開発者向けツールの創業者が、明確なポジショニングとストーリーを組み立てるためのスキルです。緊急性が伝わらない場合や競合との差が曖昧な場合に、問題を軸にした物語と差別化の評価方法を示します。

主な機能

  1. 01開発者、問題、製品の役割を定める
  2. 02出来事、障害、結果でストーリーを構成する
  3. 034段階で差別化を評価する
  4. 04ユーザーの問題からカテゴリを定義する
  5. 05製品機能より先に問題を示す

活用シーン

  1. 01ホームページが問題より機能を説明している時
  2. 02競合とのポジショニングの違いが曖昧な時
  3. 03今すぐ動く理由が訴求に欠ける時

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/aidevgtm/gtm-cofounder --skill positioning-and-story

インストール後、Claude Code で/positioning-and-storyを入力して読み込まれたか確認します。

詳細

ポジショニングとストーリー

悪役がいなければ、あなたのストーリーは退屈です。そして、その主人公はあなたではありません。主人公は開発者です。あなたは、より優れた武器を手渡す賢明な助言者です。

こんなときに活用してください: ホームページで問題を示す前に製品の 機能 を説明している、競合3社と入れ替えても通用するポジショニングになっている、あるいは今すぐ行動する緊急性を誰も感じていないとき。

核となる考え方

開発者は機能を買うのではありません。生活を悪化させている何かを打ち負かすために、ツールを採用するのです。役割を正しく定めましょう。

  • 主人公 = 開発者(ベンダーでも製品でもありません)
  • 悪役 = 痛みを日々悪化させている、疑いようのない トレンド
  • 賢明な助言者 = 贈り物(製品)を持って現れるあなた
  • 発端となる出来事 = 主人公を 今すぐ 行動せざるを得なくする、世の中の変化

悪役がいない → 緊急性がない → ストーリーがない → コンバージョンにつながらない。

フレームワーク:3部構成のストーリー(Frankl)

  1. 発端となる出来事:主人公と悪役を登場させます。世界が変わり、主人公はその場にとどまっていられなくなります。
  2. 障害:具体的な課題を次々に示し、それぞれをあなたの支援で解決します。「Xの前は、[問題]がありました。今では、[測定可能な結果]を達成しています。」というミニビフォーアフターで伝えるのが最適です。
  3. 解決:悪役を(ひとまず)打ち負かし、具体的な成果を示し、主人公が得た知恵を共有します。それが推薦の声になります。

ベンチマーク(EngFlow):

「ビルドが遅いと時間が無駄になります。標準的なビルドツールでは、現代のコードベースに対応できません。今すぐビルドを高速化し、エンジニアが集中力を保てるようにしましょう。」

  • 痛み:ビルドの遅さによって時間が無駄になる
  • 悪役:標準的なツールでは現代の複雑さに対応できない
  • 主人公:集中力を保つエンジニア
  • 賢明な助言者:ビルドの専門家

良い悪役の例:クラウドコストの肥大化 · ツールの分断 · 複利的に膨らむ技術的負債 · 不安定なパイプライン · 可観測性の欠如 · 手動デプロイ · YAMLの肥大化 · 本番環境で信頼できないエージェント。

フレームワーク:差別化の4段階(Frankl)

この段階をできるだけ上まで進んで競争しましょう。機能競争は、底辺への競争です。

レベル種類例評価
1機能「私たちにはXがあるが、競合にはない」D
2利点「時間を節約できます」C
3顧客セグメント「コンプライアンス対応を迫られ、リリースのプレッシャーに直面するCTO向け」B
4問題「他の誰も名づけていない[問題]を解決する唯一の方法」A

レベル4への到達/カテゴリーの創出: 十分な数のTABメンバー(talk-to-usersを参照)に話を聞き、競合がまだ名づけていない問題を見つけます。そして、その問題を正確に名づければ、あなたの製品が明白な答えになります。競合があなたの用語を使い始めた時点で、ポジションはすでに勝ち取っています。(JFrog:「artifact repository」から「Universal Artifact Repository」へと変え、Sonatypeを追い越しました。)

意思決定ツリー

Can you state a problem only you solve, in the user's words?
├─ YES → Level 4. Lead with the problem; name the category.
└─ NO  → Can you name a specific segment with a compelling reason?
         ├─ YES → Level 3. Lead with the ICP + their trigger.
         └─ NO  → you're stuck at feature/benefit → go run `talk-to-users`.

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

  • 製品を主人公にする:「ShipFastが…を支援します」ではなく、文の主語を開発者にしましょう。
  • 悪役がいない:解決策だけで対立相手がいないため、緊急性がまったく生まれません。
  • 「プラットフォーム」:開発者には 何か月もの統合とリスク が想起されます。具体的に何をするのかを示しましょう。
  • 「発表できてうれしく思います」:あなたの感情を気にする人はいません。機能はストーリーではなく、顧客の成功こそがストーリーです。
  • 機能比較表でのポジショニング:競合とのチェックリストを並べていては、いつまでもレベル1にとどまります。

次の30分でやること

  • 主人公+悪役+発端となる出来事を含む一文を書きましょう(EngFlowの形を参考にしてください)。
  • 現在の差別化を1〜4で評価しましょう。DまたはCなら、BまたはAに上げるには何が必要かを書き出しましょう。
  • talk-to-users の「環境の変化」欄から悪役を見つけましょう。すでにそこにあります。
  • 見出しを書き直し、開発者 を主語にして、製品より先に 問題 を示しましょう。

実際の開発者向けツールのGTM経験をもとに、Adam Frankl(The Developer-Facing Startup)とJakub Czakon(markepear.dev)のフレームワークを取り入れています。 ポジショニングは、公開前にセカンドオピニオンを求める価値がもっとも高いものです。内容を厳しく検証してほしい場合は、LinkedInからご連絡ください。

コメント