pm-positioning

ポジショニング文書（Pragmatic フレームワーク：計画 → ポジショニング）

ルール： ポジショニングでは、機能ではなく、解決する問題に焦点を当てます。 問題が異なるペルソナごとに、個別のポジショニング文書を作成します。 問題はペルソナの一人称の語り口で記述します。これは、関係者の賛同を得て、デザイン／エンジニアリングチームに概要を伝え、マーケティングチームに引き継いで対外向けのメッセージを作成するための社内文書（「社内向けプレスリリース」）です。基本要素については、../pm-copilot/references/framework.md を参照してください。

準備

市場に関する知識を持ち、客観性を保てる3～6人のチームが理想的です。製品を1つ、ペルソナ／セグメントを1つ選んで始めます。ペルソナや市場の問題がまだ定義されていない場合は、まず pm-personas と pm-market-problems を実行するか、その内容をこの作業の中でまとめます。

入力情報についてユーザーに質問する（一括で質問）

1. 製品と、この文書の対象となる1つのペルソナ＋市場セグメント。
2. 問題 — このペルソナが関心を持つ理由は何ですか？現在、何に困っていますか？（共感を持って、その人自身の言葉を使います。）
3. ペルソナの視点から見た理想的なソリューション — 明確で具体的な内容。
4. 問題が実在することを示す証拠（インタビュー、受注／失注分析、サポートチケット、アンケート）。
5. 製品の機能 — 機能をケイパビリティに対応付けるのに必要な情報。

3つのステップで作成する（Pragmatic メソッドに従う）

ステップ1 — 文書の最初の4セクションの草稿を作成します：

• 問題 — 「現在、業界には問題があります……」（ペルソナの一人称）。
• ソリューション — 「この問題に対する理想的なソリューションは……」（明確で具体的に）。
• ポジショニングステートメント — 「看板」となる25語以内の文章。次の形式を使います。

  **[ペルソナ]にとって、[製品]は、[動詞]することで[主なメリット]をもたらし、[動詞]によって[問題]**を解決します。

• 製品の説明 — 概要を50語以内で記述します。

ステップ2 — 問題指向ケイパビリティ（POC）ワークシート。 このペルソナに対して製品が解決する問題をすべて（ペルソナの一人称で）列挙します → 類似する問題をまとめ、3～5個の問題グループに整理します → 各グループの問題指向ケイパビリティに名前を付けます → 各ケイパビリティに製品の機能を対応付けます。表：市場の問題 | 問題指向ケイパビリティ | 製品機能。

ステップ3 — 3～5個の問題指向ケイパビリティを列挙して、文書を完成させます。

成果物のテンプレート

ポジショニング文書

# Positioning Document — <Product Name>

**Product Name:** <name>
**Persona & Market Segment:** <persona> / <segment>
**Company:** <company>  ·  **Feature / Product:** <name>
**Author:** <author>  ·  **Date created:** <date>  ·  **Version:** 1.0
*Internal document — describes the product by the problems it solves.*

## Problem
There is a problem in the industry today: <persona's first-person description of the pain, with evidence>.

## Solution
The ideal solution to this problem is <clear, specific solution from the persona's point of view>.

## Positioning Statement
> For <persona>, <product> <verb> <problem> by <verb> <primary benefit>.


## Product Description
<≤50-word overview of the product.>

## Problem-Oriented Capabilities
1. <Capability> — <benefit>
2. <Capability> — <benefit>
3. <Capability> — <benefit>
4. <Capability> — <benefit>
5. <Capability> — <benefit>

## Evidence & open questions
- <evidence sources / interview counts>
- > TODO: <anything unproven, flagged as an assumption>

問題指向ケイパビリティのワークシート

# Problem-Oriented Capabilities — <Product> / <Persona>

| Market Problems (persona's first person) | Problem-Oriented Capability | Product Features |
| :--- | :--- | :--- |
| "I can't …" | <Capability> | <feature>, <feature> |
| "It takes too long to …" | <Capability> | <feature> |

作成例（Pragmatic の例を引用）

プロダクトマネージャーのRobinにとって、Product Minderは、あらゆる場所にあるアイデアや要件を1つのシステムに統合することで、それらを管理する煩わしさを軽減します。 ケイパビリティ：要件の即時取得、アイデアストア、自動フィードバック、トレースリンク、ステータスビュー。

成果物を提出する

../pm-copilot/references/artifact-output.md に従って、入力内容を確認し、Markdownと.docxのどちらにするかを質問します。.md ファイルを作成し、希望があれば、実行環境に備わっているネイティブの文書作成機能で .docx に変換します。ポジショニング文書とPOCワークシートの両方を提出します。 次の段階として、これらの問題を優先順位付けされた pm-requirements に変換することを提案します。