| name | product-lens |
| description | 構築前に「なぜ作るのか」を検証し、プロダクト診断を実行し、リクエストが実装契約になる前にプロダクト方針を圧力テストするためのスキルです。 |
| origin | ECC |
Product Lens — 作る前に考える
このレーンが担当するのはプロダクトの診断であり、実装可能レベルの仕様作成ではありません。
ユーザーが PRD から SRS、あるいはケイパビリティ契約といった永続的なアーティファクトを必要とする場合は、product-capability に引き継いでください。
使用タイミング
- 機能開発の前に「なぜ作るのか」を検証する場合
- 週次プロダクトレビューで正しいものを作っているか確認する場合
- 機能の選択に迷っている場合
- ローンチ前にユーザージャーニーをサニティチェックする場合
- 曖昧なアイデアを、エンジニアリングの計画に入る前のプロダクトブリーフに変換する場合
仕組み
モード 1: Product Diagnostic
YC のオフィスアワーを自動化したようなものです。厳しい質問を投げかけます:
1. 誰のためのものか？（「開発者」ではなく、具体的な人物）
2. 何が痛いのか？（定量化: 頻度、深刻さ、現在の対処法は？）
3. なぜ今なのか？（何が変わって可能/必要になったのか？）
4. 10つ星バージョンは？（お金も時間も無制限なら）
5. MVP は？（仮説を証明する最小のもの）
6. アンチゴールは？（明示的に作らないものは何か？）
7. うまくいっている指標は？（感覚ではなく、メトリクス）
出力: 回答、リスク、Go/No-Go 推奨を含む PRODUCT-BRIEF.md。
結果が「Yes、作るべき」となった場合、次のレーンは product-capability であり、これ以上ファウンダー劇を続けるべきではありません。
モード 2: Founder Review
現在のプロジェクトを創業者の視点でレビューします:
1. README、CLAUDE.md、package.json、最近のコミットを読む
2. 推測: これは何になろうとしているのか？
3. スコアリング: プロダクトマーケットフィットのシグナル（0-10）
- 利用成長の軌跡
- リテンション指標（リピートコントリビューター、リピートユーザー）
- 収益シグナル（価格ページ、課金コード、Stripe 連携）
- 競合に対する堀（真似しにくいものは何か？）
4. 特定: これを10倍にする一つのこと
5. フラグ: 作っても意味のないもの
モード 3: User Journey Audit
実際のユーザー体験をマッピングします:
1. 新規ユーザーとしてプロダクトをクローン/インストール
2. すべての摩擦ポイントを記録（分かりにくい手順、エラー、ドキュメント不足）
3. 各ステップの時間を計測
4. 競合のオンボーディングと比較
5. スコアリング: Time-to-Value（ユーザーが最初の成功体験を得るまでの時間）
6. 推奨: オンボーディング改善トップ3
モード 4: Feature Prioritization
10個のアイデアから2つを選ぶ必要がある場合:
1. 候補機能をすべてリストアップ
2. 各機能をスコアリング: Impact (1-5) x Confidence (1-5) / Effort (1-5)
3. ICE スコアでランキング
4. 制約を適用: 資金余力、チーム規模、依存関係
5. 出力: 根拠付きの優先順位付きロードマップ
出力
すべてのモードはエッセイではなく、アクショナブルなドキュメントを出力します。すべての推奨には具体的な次のステップが含まれます。
統合
以下と組み合わせて使用できます:
/browser-qa でユーザージャーニー監査の結果を検証/design-system audit でビジュアルの仕上がりを評価/canary-watch でローンチ後のモニタリング- プロダクトブリーフを実装可能なケイパビリティ計画に発展させる際の
product-capability
