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