Product Lens — 構築前の思考
このレーンは、実装可能な仕様書作成ではなく、プロダクト診断を担当します。
ユーザーが永続的なPRD-to-SRSや機能契約アーティファクトを必要とする場合は、product-capability に引き継いでください。
使用するタイミング
- 任意の機能を開始する前 — 「なぜ」を検証する
- 週次プロダクトレビュー — 正しいものを作っているか？
- 機能の選択に迷っているとき
- ローンチ前 — ユーザージャーニーの健全性チェック
- 漠然としたアイデアを、エンジニアリング計画開始前にプロダクトブリーフに変換するとき
動作方法
モード1: プロダクト診断
まるでYCのオフィスアワーを自動化したかのようです。厳しい質問を投げかけます:
1. これは誰のためのものか？ (具体的な人物、「開発者」ではなく)
2. 痛点は何か？ (定量化: 頻度、深刻度、現在の対処方法は？)
3. なぜ今なのか？ (これを可能/必要にした変化は何か？)
4. 10つ星バージョンは？ (お金や時間が無限なら)
5. MVPは？ (仮説を証明する最小のもの)
6. アンチゴールは？ (明確に構築しないものは何か？)
7. どうやって成功を判断するか？ (指標、雰囲気ではない)
出力: 回答、リスク、Go/No-Goの推奨事項を含む 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— プロダクトブリーフを実装可能な機能計画に変換する必要がある場合