| name | inspired-pm |
| effort | high |
| description | Use when applying Marty Cagan's empowered product team model — continuous discovery, outcome ownership, four-risk validation before delivery. Triggers on: "Marty Cagan", empowered team", "continuous discovery", "discovery vs delivery", "outcome not |
| license | MIT |
| metadata | {"author":"wondelai","version":"1.0.0"} |
| scenarios | ["Our team is a feature factory — how do we shift to outcome thinking?","팀에 continuous discovery 습관을 만들려면 어떻게 시작해야 할까?","Assess our product team's discovery practice and score it.","출시 전에 네 가지 제품 리스크를 검토해줘.","How do I run weekly customer interviews as a product trio?","엔지니어도 고객 인터뷰에 참여해야 하는 이유를 설명해줘."] |
| compatibility | {"recommended":[],"optional":["think-tool","mcp-reasoner"],"remote_mcp_note":"think-tool이 있으면 네 가지 제품 리스크 평가와 아웃컴 지표 설계에 도움이 됩니다. Claude 설정 → MCP Servers에서 remote SSE 엔드포인트를 추가하세요."} |
Standing Mandates
- ALWAYS separate discovery work from delivery work — do not let delivery crowd out discovery.
- ALWAYS validate all four risks (value, usability, feasibility, viability) before committing to build.
- NEVER treat a feature request as a solution — reframe every request as a problem to solve.
- NEVER ship without knowing which outcome metric the team expects to move.
Inspired Product Management Framework
A framework for discovering and building products that customers love, based on Marty Cagan's definitive guide to modern product management. The core insight: most product failures are not execution failures — they are discovery failures. Teams build the wrong thing, and build it well.
Core Principle
Discovery is not a phase — it is a continuous discipline. The old model (PMs gather requirements → engineers build → customers respond) fails because by the time you learn you built the wrong thing, you've wasted months and millions. The modern model runs discovery and delivery in parallel: while one set of ideas is being built, the next set is being discovered, validated, and shaped.
The foundation: Every product idea carries four risks. Value risk: will customers buy it? Usability risk: can they figure out how to use it? Feasibility risk: can we build it? Business viability risk: does it work for our business? The job of product discovery is to reduce these risks before committing to delivery. Not to eliminate them — to reduce them enough that the bet is worth taking.
Scoring
Goal: 10/10. When evaluating a product team's discovery practice, rate 0-10 based on the principles below. A 10/10 means the team continuously discovers, validates, and delivers in parallel, with strong customer proximity and outcome ownership. Always provide the current score and specific improvements needed.
- 9-10: Team runs weekly discovery, has direct customer access, owns outcomes not features, and validates all four risks before delivery
- 7-8: Discovery happens but is episodic; customer access is mediated; output metrics dominate over outcome metrics
- 5-6: Some user research exists but isn't continuous; PMs act as "feature owners" not outcome owners
- 3-4: Discovery is a kickoff phase, not a habit; requirements come from stakeholders, not customers
- 1-2: No discovery practice; team builds what it's told; no connection to customer behavior or outcomes
The Inspired Framework
1. The Four Product Risks
Core concept: Every product initiative carries four risks that must be addressed in discovery: Value (will customers want this?), Usability (can they use it successfully?), Feasibility (can we build and maintain it?), and Business Viability (does it work for the business — legal, financial, marketing, sales?).
