Product Lens — Think First, Build Second

このチャネルは、実装可能な仕様書を作成するのではなく、製品診断を担当します。

ユーザーが永続的な PRD から SRS または機能契約ドキュメントが必要な場合は、product-capability に引き継いでください。

使用時機

• 機能構築前 —— 「なぜ」を検証する
• 週次の製品レビュー —— 正しいものを構築しているか？
• 複数の機能間で判断に迷った時
• リリース前 —— ユーザージャーニーの合理性チェック
• 曖昧なアイデアを製品概要書に変換し、エンジニアリング計画開始前

動作方法

モード 1：製品診断

YC オフィスアワーを自動化したようなもの。鋭い質問を投げかけます：

1. これは誰のためのものか？（「開発者」ではなく、具体的な人物）
2. 痛点は何か？（定量化：頻度、重大性、現在の対処法は？）
3. なぜ今なのか？（何が変化してこれを可能/必要にしたのか？）
4. 10 つ星版は何か？（資金/時間が無制限なら）
5. MVP は何か？（仮説を検証する最小限の案）
6. アンチゴールは何か？（明確に構築しないことは？）
7. 有効性の判断基準は？（メトリクス、感覚ではなく）

出力：回答、リスク、「実行可能/不可能」推奨事項を含む PRODUCT-BRIEF.md。

結果が「はい、この機能を構築する」なら、次のチャネルは product-capability であり、創業者によるさらなるプレゼンではありません。

モード 2：創業者レビュー

創業者の視点から現在のプロジェクトを評価します：

1. README、CLAUDE.md、package.json、最近のコミットを読む
2. 推測：このプロジェクトは何になろうとしているのか？
3. スコアリング：プロダクト・マーケット・フィット信号（0-10点）
   - 利用成長軌跡
   - リテンション指標（繰り返し貢献者、再訪問ユーザー）
   - 収益信号（価格ページ、請求コード、Stripe 統合）
   - 競争護城河（何が複製困難か？）
4. 特定：このプロジェクトを 10 倍成長させる重要要因
5. 標識：構築中だが無関係なコンテンツ

モード 3：ユーザージャーニー監査

実際のユーザー体験をマッピングします：

1. 新規ユーザーとして製品をクローン/インストール
2. すべての摩擦点を記録（混乱を招くステップ、エラー、ドキュメント欠落）
3. 各ステップの時間を測定
4. 競合他社のオンボーディングフローと比較
5. スコアリング：価値実現までの時間（ユーザーが最初の成功を得るまでどのくらい）
6. 推奨事項：オンボーディングフローの 3 つの主要修正案

モード 4：機能優先順位付け

10 個のアイデアがあるが 2 つ選ぶ必要がある場合：

1. すべての候補機能をリストアップ
2. 各機能をスコアリング：影響度（1-5）× 信頼度（1-5）÷ 作業量（1-5）
3. ICE スコアでソート
4. 制約条件を適用：時間枠、チームサイズ、依存関係
5. 出力：理由付きの優先順位付けロードマップ

出力

すべてのモードは長文ではなく、実行可能なドキュメントを出力します。各推奨事項には具体的な次のステップが付属しています。

統合

以下と組み合わせて使用：

• /browser-qa ユーザージャーニー監査結果の検証
• /design-system audit ビジュアル最適化評価
• /canary-watch リリース後の監視
• product-capability 製品概要書を実装可能な機能計画に変換する場合