| name | cagan-inspired |
| description | Knowledge base from "INSPIRED: How to Create Tech Products Customers Love" by Marty Cagan. Use when applying Cagan's frameworks for product management, product discovery, empowered product teams, OKRs, prototyping, stakeholder management, or product culture — studying the book, or referencing its concepts. |
INSPIRED
Author: Marty Cagan | Pages: ~370 | Chapters: 67 | Generated: 2026-08-10
How to Use This Skill
- Without arguments — load core frameworks for reference
- With a topic — ask about
discovery, OKR, prototypes, roadmaps, stakeholders, or another indexed topic; I find and read the relevant chapter
- With chapter — ask for
ch05; I load that specific chapter
- Browse — ask "what chapters do you have?" to see the full index
When you ask about a topic not covered in Core Frameworks below, I will read
the relevant chapter file before answering.
Companion skills: cagan-empowered (EMPOWERED) is the leadership/coaching layer on top — staffing, coaching, vision, strategy, team objectives, and topology. cagan-transformed (TRANSFORMED) is the org-transformation playbook to the product operating model. Recommended reading order: INSPIRED → EMPOWERED → TRANSFORMED.
Core Frameworks & Mental Models
The Product Team (the whole book is about teams)
- Missionaries, not mercenaries (John Doerr): teams that own outcomes and solve customer problems vs. teams that build what they're told. Everything — empowerment, durability, co-location, learning — serves this (ch09).
- Product team model: durable, co-located, flat, cross-functional (PM + designer + 2–12 engineers), owning all work for its product scope. If your company lacks this, it's the most important thing to fix — start with a pilot team (ch09).
- Empowerment with context: leadership provides the vision + business objectives; teams own the how. No context = ambiguity vacuum (ch20, ch23).
Product Culture (what the book is really about)
- Two dimensions: consistent innovation (discovery) + execution (delivery). Few companies are strong at both (Amazon is the model); strong execution places are tough places (ch67).
- Innovation loss is not inevitable: the ten attributes — customer-centric culture, compelling vision, focused strategy, strong PMs, stable teams, engineers in discovery, corporate courage, empowerment, product mindset, time to innovate (ch65).
- Velocity killers: tech debt, weak PMs, no delivery managers, infrequent releases, no vision, non-co-located teams, engineers/design not in discovery, priority churn, consensus culture (ch66).
Product Discovery (the most important core competency)
- The four risks: value, usability, feasibility, business viability — tackled in discovery, before writing production code, with evidence not opinion (ch33).
- The ten discovery principles (ch33), especially: customers can't tell you what to build; value first; UX before engineering; functionality/design/tech intertwined; most ideas fail; validate on real users; fastest/cheapest way; validate feasibility and viability during discovery; shared learning.
- 10–20 iterations per week: an iteration = one idea or approach tested at least an order of magnitude cheaper than delivery. MVP should be a prototype, never a product (ch08, ch33).
- Only validate what you need to: no significant risk or team disagreement → proceed to delivery (ch34).
The Techniques (ch35–56)
- Frame: opportunity assessment (4 questions) → customer letter/press release (big efforts) → startup canvas (new businesses; biggest risk is value/solution) (ch35–37).
- Plan: story maps (2-D, context for every story) and the customer discovery program — six reference customers in one target market = product/market fit (B2B); the single best leading indicator of success (ch38–39).
- Ideate: customer interviews (2–3 hrs/week), concierge tests, customer misbehavior (encourage it — eBay's "Everything Else"), directed hack days (ch41–44).
- Prototype: feasibility (throwaway code, engineers), user (simulation, fidelity by purpose — cannot prove value), live-data (5–10% of productization, real evidence), Wizard of Oz hybrids (human behind the UI) (ch45–49).
- Test: usability protocol (silence, parrot, use mode) → value (pay with money/reputation/time/access; PM attends every session — 2–3/week) → demand (fake door, landing page) → quantitative (A/B 99/1, invite-only, CDP; analytics: instrument everything) → feasibility (give engineers time to investigate) → viability (each stakeholder 1:1 on high-fidelity prototypes — never presentations, never after building) (ch50–56).
- The three showings: user test (user drives), product demo (you drive, persuasive), walkthrough (let the stakeholder poke everything) — don't mix them up (ch56).
The Right Product (context, not roadmaps)
- Roadmap = commitment: "at least half your ideas won't work" + "winners take several iterations" — but a document titled roadmap makes every item a commitment. Replace with business objectives + key results + high-integrity commitments (after discovery) (ch22–23).
- Vision (2–10 yrs) vs. strategy (sequence of product/market fits): inspiring vs. focused; vision is a leap of faith — stubborn on vision, flexible on details (Bezos); skate to where the puck is heading (ch24–25).
- Strategy principles: one target market at a time; align with business and go-to-market strategy; obsess over customers, not competitors (ch26).
- Product principles: e.g., eBay's "prioritize the buyer, because that's the most important thing we can do for sellers" (ch27).
- OKRs: qualitative objectives, quantitative KRs measuring business results; 1–3 each; team-level focus only (no functional cascades); scoring 0/0.3/0.7/1.0 consistent org-wide; commitments are binary (ch28–30).
The Roles (ch10–21)
- PM = CEO of the product without authority: brings four deep knowledges (customer, data, business/stakeholders, market/industry); smart, creative, persistent; accountable — "when a product fails, it's the PM's fault"; PO is a subset of PM, never split (ch10).
- Designer measured on product success; design informs functionality; UX = every touchpoint over time (ch11).
- Engineers: the best source of innovation — never dictate how to build; morale is the PM's job; programming literacy required (ch12).
- Stakeholders = veto power: weekly 1:1s, preview in discovery, data over opinions (ch61).
- Leadership: holistic view of product (product/design/tech leaders); VP product competencies (team development, vision, execution, culture); CTO's six responsibilities (org, leadership, delivery, architecture, discovery, evangelism); GPM player-coach (ch16–19).
Chapter Index
| # | Title | Key Frameworks |
|---|
| ch01 | Behind Every Great Product | The central concept |
| ch02 | Technology-Powered Products | Scope of the playbook |
| ch03 | Startups: Getting to Product/Marketing Fit | Product/market fit, discovery = survival |
| ch04 | Growth-Stage Companies | Surviving success, scaling stress |
| ch05 | Enterprise Companies | Value creation vs. capture, death spiral |
| ch06 | Root Causes of Failed Product Efforts | Two inconvenient truths, waterfall trap |
| ch07 | Beyond Lean and Agile | Four product risks, collaborative definition |
| ch08 | Key Concepts | Holistic product, discovery/delivery, MVP correction |
| ch09 | Principles of Strong Product Teams | Missionaries, empowerment, durability, co-location |
| ch10 | The Product Manager | Three work models, four knowledges, accountability |
| ch11 | The Product Designer | Design as discovery partner, holistic UX |
| ch12 | The Engineers | PM–engineer relationship, tech lead |
| ch13 | Product Marketing Managers | PMM represents the market |
| ch14 | The Supporting Roles | Researchers, analysts, test automation |
| ch15 | Profile: Jane Manning (Google) | Objections-to-built, constraint engineering |
| ch16 |
Topic Index
- A/B testing → ch52, ch54
- Analytics / data → ch10, ch14, ch54
- Autonomy vs. leverage → ch20
- Business objectives → ch23, ch28, ch29, ch30
- Business viability → ch7, ch33, ch56
- Co-location → ch9, ch66
- Concierge test → ch42
- Customer discovery program / reference customers → ch39, ch52, ch53
- Customer interviews → ch41, ch50, ch53
- Customer misbehavior / public APIs → ch43
- Demand testing → ch51, ch52
- Design / product designer → ch11, ch50
- Discovery (principles, techniques, iterations) → ch8, ch33, ch34, ch38, ch39, ch58
- Discovery sprints / design sprints → ch58
- Empowered teams → ch9, ch20, ch65
- Engineers → ch12, ch33, ch44, ch55, ch66
- Ethics → ch33
- Evangelism → ch31, ch62
- Feasibility → ch46, ch55
- Good vs. bad teams → ch64
- Hack days → ch44
- High-integrity commitments → ch23, ch28, ch60, ch66
- Holistic view of product → ch16
- Innovation (consistent, loss of) → ch5, ch52, ch65
- MVP / minimum viable product → ch8, ch58
- OKRs → ch23, ch28, ch29, ch30
- Product culture → ch67
- Product/market fit → ch3, ch8, ch39
- Product marketing → ch13
- Product principles → ch27
- Product strategy → ch24, ch26
- Product vision → ch24, ch25
- Prototypes → ch45, ch46, ch47, ch48, ch49
- Roadmaps (problems, alternatives, weaning) → ch22, ch23, ch60
- Roles: PM → ch1, ch10; designer → ch11; engineers → ch12; PMM → ch13; supporting → ch14; → ch17; → ch18; → ch19; → ch17
Supporting Files
Scope & Limits
This skill covers INSPIRED only. For the leadership/coaching layer on top — staffing,
coaching, vision, strategy, team objectives, and topology — see the companion
cagan-empowered skill (EMPOWERED). For transforming an organization to the product
operating model, see the companion cagan-transformed skill (TRANSFORMED). For hands-on
implementation in your codebase, combine with project-specific tools.
