ワークフロー 1
製品領域ごとにプロジェクトを1つ作成する
フィードバック、仕様、意思決定を、製品領域や機能ごとにまとめておきましょう。これにより、無関係なロードマップの文脈が検索結果に紛れ込むのを防げます。
試してほしいプロンプト
プロジェクトのファイルを確認し、製品の文脈ブリーフを作成してください。ユーザー、課題、現在のソリューション、制約条件、未解決の質問、リスク、意思決定の経緯を含めてください。
プロダクトチーム向けプロジェクト
プロダクトマネージャー向け AI プロジェクト
ユーザーフィードバック、仕様、ロードマップのメモ、製品ドキュメントをひとつの AI ワークスペースにまとめます。
シンプルな考え方
AI に推測させるのではなく、プロジェクトそのものを渡しましょう。
プロダクトの仕事は断片的な情報の集まりです。ユーザーインタビュー、サポートチケット、アナリティクスのメモ、仕様書、スクリーンショット、ロードマップをめぐる議論、エンジニアリング上の制約。一般的な AI は、それをありきたりな製品アドバイスに変えてしまいます。
MultipleChat のプロジェクトでは、製品領域や機能ごとに専用のワークスペースを持てます。根拠と制約条件をアップロードし、情報源に基づいた文脈をもとに、AI でフィードバックの統合、PRD の作成、選択肢の比較、意思決定の準備を行えます。
アップロードするもの
まずは回答に必要なファイルから始めましょう。
AI プロジェクトがうまくいかない原因の多くは、アップロードする資料が少なすぎることです。人間の専門家に元の資料が必要なら、プロジェクトにも必要です。
ユーザーインタビュー、サポートチケット、顧客のフィードバック
PRD、仕様書、ロードマップのメモ、意思決定ログ
アナリティクスのサマリー、実験結果、スプレッドシート
スクリーンショット、ワイヤーフレーム、デザインのメモ、リリース計画
エンジニアリング上の制約、API ドキュメント、アーキテクチャのメモ
プロジェクトの指示
あなたの職種ならではの考え方をプロジェクトに伝えましょう。
同じファイルでも、指示によって回答は大きく変わります。最初に一度だけ期待する内容を設定しておけば、どのモデルも情報源、不確かな点、形式の扱い方を理解できます。
ユーザーに関する根拠、製品としての判断、実装上の前提を分けて示してください。
ユーザーに関する主張や要件には、ファイル名を引用してください。
わかりやすさ、トレードオフ、意思決定に使える状態であることを優先してください。
ロードマップの変更を提案する前に、不足しているデータを指摘してください。
エンジニアやステークホルダーに適した、簡潔なプロダクトの言葉で書いてください。
活用ガイド
まず試したい5つのワークフロー。
これは理論上の機能説明ではありません。プロダクトマネージャーがプロジェクトを作成したら最初に試すべき、実践的なワークフローです。
ワークフロー 2
ユーザーフィードバックを統合する
インタビュー、チケット、アンケートのメモ、スクリーンショットをアップロードします。パターン、深刻度、代表的な発言を見つけるよう AI に依頼しましょう。
試してほしいプロンプト
プロジェクトのフィードバックを分析してください。ユーザーの主な悩み、根拠となるファイル、頻度を示すシグナル、深刻度、影響を受けるペルソナ、製品の機会を特定してください。
ワークフロー 3
根拠から PRD を作成する
空のテンプレートから始めるのではなく、プロジェクトを要件定義書の情報源として使います。
試してほしいプロンプト
プロジェクトのファイルを使って PRD を作成してください。課題、目標、対象外とすること、ユーザーストーリー、要件、エッジケース、成功指標、リスク、未解決の質問を含めてください。
ワークフロー 4
ロードマップの選択肢を比較する
同じプロジェクトの文脈から複数のモデルに選択肢を比較させ、その後 AI Collaboration で批評させます。
試してほしいプロンプト
この機能について、3つのロードマップの選択肢（最小限でリリース、本格的に投資、延期）を比較してください。プロジェクトの根拠を使い、トレードオフ、リスク、判断基準を含めてください。
ワークフロー 5
ステークホルダー向けの報告を準備する
散らばった製品の根拠を、経営陣、エンジニアリング、GTM チーム向けのわかりやすい報告にまとめます。
試してほしいプロンプト
プロジェクトのファイルから、ステークホルダー向けの報告を作成してください。現在の状況、根拠、必要な意思決定、リスク、次のステップ、担当者への質問を含めてください。
避けたい失敗
多くの人はプロジェクトを漠然と使いすぎています。
解決策はシンプルです。プロジェクトの目的を絞り、実際の資料をアップロードし、情報源に基づいた出力を求めることです。
1.ユーザーに関する根拠や制約条件をアップロードせずに PRD を作成しないでください。
2.無関係な製品領域を1つのプロジェクトに混ぜないでください。
3.指標や顧客の発言を AI にでっち上げさせないでください。
4.ロードマップについて助言を求めるときは、エンジニアリング上の制約を省かないでください。
5.不確かな点をステークホルダーに隠さないでください。
よくある質問
プロダクトマネージャーからよく寄せられる質問。
プロダクトマネージャーは機能ごとにプロジェクトを作成すべきですか？
多くの場合はそうです。機能や製品領域ごとに1つのプロジェクトにすると、顧客のフィードバック、仕様、意思決定を絞り込んで管理できます。
プロジェクトは PRD の作成に役立ちますか？
はい。ユーザーに関する根拠、制約条件、決定事項をアップロードし、プロジェクトのファイルに基づいた PRD を求めましょう。
スクリーンショットやフィードバックをアップロードできますか？
はい。スクリーンショット、メモ、スプレッドシート、文書をアップロードし、プロジェクト内検索のためにインデックス化できます。
AI Collaboration はプロダクトチームにどう役立ちますか？
同じプロジェクトの文脈から、異なるモデルが製品に関する決定の下書き、批評、徹底的な検証を行えます。
正しい方法で始めましょう
難しい質問をする前に、まずプロジェクトを作成しましょう。
資料をアップロードし、ルールを設定すれば、MultipleChat が ChatGPT、Claude、Gemini、Grok、AI Collaboration のために関連する文脈を取り出します。