inspired-pm

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?).