Empowered Product Teams Framework
Unverified●26/40Claude Code◐PartialHas SKILL.md but declares no allowed-tools — Claude Code will ask for permission each time
Cursor◐PartialPlain prose you can paste in — but no Cursor rules file
Codex◐PartialPlain prose you can paste in — but no AGENTS.md
Gemini CLI◐PartialPlain prose you can paste in
Copilot◐PartialPlain prose you can paste in — but no Copilot instructions file
npx agentalley add inspired-productWho is stuck, and on what
My team is always busy shipping, but customers aren't any happier and our numbers aren't moving. I can't tell if we're actually solving real problems or just cranking out features nobody asked for.
What it gives you
A plain-language scorecard rating how your team works from 0 to 7, naming each weak spot and giving concrete steps to fix it.
When NOT to use it
It won't run your team or talk to your customers for you — it only assesses how you work and tells you what to change.
The whole source
Frontmatter — 4 properties
| name | inspired-product |
|---|---|
| description | Build empowered product teams using discovery and delivery dual-track. Use when the user mentions "product discovery", "empowered teams", "feature factory", "opportunity assessment", "product vision", "product strategy", "what should we build", or "our roadmap is just a feature list". Also trigger when restructuring teams away from output-driven models, or deciding what to build next based on outcomes. Covers discovery techniques, team structure, opportunity assessment, vision/strategy, and continuous delivery. For customer interviews, see mom-test. For ongoing discovery systems, see continuous-discovery. |
| license | MIT |
| metadata | author: wondelai version: "1.4.0 |
| 1 | --- |
| 2 | name: inspired-product |
| 3 | description: 'Build empowered product teams using discovery and delivery dual-track. Use when the user mentions "product discovery", "empowered teams", "feature factory", "opportunity assessment", "product vision", "product strategy", "what should we build", or "our roadmap is just a feature list". Also trigger when restructuring teams away from output-driven models, or deciding what to build next based on outcomes. Covers discovery techniques, team structure, opportunity assessment, vision/strategy, and continuous delivery. For customer interviews, see mom-test. For ongoing discovery systems, see continuous-discovery.'B1 — Line is 627 characters — unreadable by eye |
| 4 | license: MIT |
| 5 | metadata: |
| 6 | author: wondelai |
| 7 | version: "1.4.0" |
| 8 | ---A5 — No allowed-tools declared — no way to tell what this skill may touch |
| 9 | |
| 10 | # Empowered Product Teams Framework |
| 11 | |
| 12 | Framework for building products customers love through empowered teams that own continuous discovery and delivery. The best product companies don't ship features -- they solve problems, and they give teams the autonomy and accountability to figure out how. |
| 13 | |
| 14 | ## Core Principle |
| 15 | |
| 16 | **Empowered product teams** = cross-functional groups given problems to solve (not features to build) who own discovery and delivery end-to-end. |
| 17 | |
| 18 | Most product failures come not from bad engineering or design but from building things nobody wants. Feature teams receive roadmaps and execute; empowered teams receive objectives and discover solutions. The difference between a feature factory and an innovation engine is whether teams are missionaries (driven by vision and empathy) or mercenaries (driven by a handed-down backlog). |
| 19 | |
| 20 | ## Scoring |
| 21 | |
| 22 | **Goal: 7/7.** Score product team structures, discovery practices, or delivery processes by the Quick Diagnostic below -- **1 point per satisfied row**, scored 0-7. Bands: **6-7** = empowered teams own outcomes and discovery runs continuously with engineers; **4-5** = discovery happens but inconsistently, or teams own output with partial outcome accountability; **<=3** = a feature factory: teams receive a roadmap of dated features and skip discovery. Always state the current score and the specific failed diagnostic rows to fix to reach 7/7.B1 — Line is 546 characters — unreadable by eye |
| 23 | |
| 24 | ## Framework |
| 25 | |
| 26 | ### 1. Product Discovery vs Delivery |
| 27 | |
| 28 | **Core concept:** Product work runs on two parallel tracks: discovery determines what to build by addressing risks before engineering investment; delivery builds production-quality software. Most organizations skip discovery entirely, jumping from idea to backlog to sprint. |
| 29 | |
| 30 | **Why it works:** Discovery is cheap and fast; delivery is expensive and slow. Validating ideas before committing engineering avoids the most common failure mode: building something nobody wants. |
| 31 | |
| 32 | **Key insights:** |
| 33 | - Discovery answers four risks: value (will customers use it?), usability (can they figure it out?), feasibility (can we build it?), viability (does it work for the business?) |
| 34 | - Discovery output is validated ideas backed by evidence, not PRDs or specifications |
| 35 | - Run 10-20 discovery iterations per feature that reaches delivery -- most ideas won't work, so fail fast and cheap |
| 36 | - Discovery is not a phase; it runs continuously alongside delivery, with engineers participating |
| 37 | |
| 38 | **Product applications:** |
| 39 | |
| 40 | | Context | Application | Example | |
| 41 | |---------|-------------|---------| |
| 42 | | New feature | Validate all four risks before committing | Prototype-test onboarding flow with 5 users before building | |
| 43 | | Roadmap prioritization | Prioritize strongest discovery evidence | Ship the feature with 4/5 successful user tests, not the CEO's request | |
| 44 | | Sprint planning | Feed backlog from validated discovery output | Only discovery-tested items enter the sprint | |
| 45 | |
| 46 | **Ethical boundary:** Never cherry-pick discovery evidence to justify a conclusion you already chose; report the tests that failed alongside the ones that passed. |
| 47 | |
| 48 | See [references/discovery-techniques.md](references/discovery-techniques.md) when planning a discovery cycle -- the four-risks framework, a 5-stage interview script, prototyping techniques, and concrete evidence thresholds for "validated". |
| 49 | |
| 50 | ### 2. Empowered Product Teams |
| 51 | |
| 52 | **Core concept:** A small, durable, cross-functional group (product manager, product designer, engineers) given a problem to solve, owning discovery and delivery, accountable for outcomes rather than output. |
| 53 | |
| 54 | **Why it works:** The people closest to the customer and the technology find better solutions than a remote roadmap author -- and a team that discovered the solution itself defends and refines it under pressure, where a team handed a spec ships it and moves on. |
| 55 | |
| 56 | **Key insights:** |
| 57 | - The PM is not a project manager or backlog administrator -- they own value and viability and need deep knowledge of customers, data, business, and industry |
| 58 | - The product designer owns the user experience holistically, not just visual design |
| 59 | - Engineers are the best source of innovation because they know what is technically possible |
| 60 | - Keep teams durable (stable membership) and highly collaborative |
| 61 | - Accountability means outcomes (adoption, retention, revenue), not output (stories shipped) |
| 62 | |
| 63 | **Product applications:** |
| 64 | |
| 65 | | Context | Application | Example | |
| 66 | |---------|-------------|---------| |
| 67 | | Team structure | Organize around outcomes, not components | "New user activation" team owns the whole first-week experience | |
| 68 | | Hiring | Hire PMs for competence, not credentials | Evaluate customer knowledge, data fluency, business acumen | |
| 69 | | Performance | Measure results, not velocity | Track activation-rate improvement, not stories per sprint | |
| 70 | |
| 71 | **Ethical boundary:** Never claim to empower teams while overriding their discovery findings with executive mandates -- if leadership dictates the solution, the team is not empowered. |
| 72 | |
| 73 | See [references/empowered-teams.md](references/empowered-teams.md) when staffing or diagnosing a team -- role-by-role competence breakdowns with red flags, missionary vs mercenary dynamics, coaching, and a feature-factory-to-empowered transformation table. |
| 74 | |
| 75 | ### 3. Product Discovery Techniques |
| 76 | |
| 77 | **Core concept:** Systematically test ideas against the four risks using opportunity assessment, customer interviews, prototyping, and user testing -- producing evidence quickly and cheaply. |
| 78 | |
| 79 | **Why it works:** Ideas are assumptions; without rapid testing, teams build for months on untested assumptions and discover failure only after launch. Discovery techniques compress learning cycles from months to days. |
| 80 | |
| 81 | **Key insights:** |
| 82 | - Prototypes are the primary tool: high-fidelity for usability, live-data for feasibility, Wizard of Oz for value |
| 83 | - Test with real target users, not colleagues; qualitative testing (5 users) reveals problems, quantitative validates at scale |
| 84 | - Interview for behavior (what they did), not opinion (what they say they want) |
| 85 | - Data reveals patterns but not causes -- pair it with qualitative discovery |
| 86 | - Feasibility spikes let engineers explore technical risk without full implementation |
| 87 | |
| 88 | **Product applications:** |
| 89 | |
| 90 | | Context | Application | Example | |
| 91 | |---------|-------------|---------| |
| 92 | | Early idea | Opportunity assessment before design work | Who is it for, what problem, how will we measure success? | |
| 93 | | Usability | High-fidelity prototype with 5 target users | Clickable Figma prototype testing task completion | |
| 94 | | Value | Fake door or Wizard of Oz test | Button for unbuilt feature, measure click-through | |
| 95 | | Feasibility | Engineering spike | Two-day investigation of real-time sync risk | |
| 96 | |
| 97 | **Ethical boundary:** Never deceive users beyond what valid results require -- Wizard of Oz prototypes are acceptable; collecting payment for non-existent products is not. |
| 98 | |
| 99 | ### 4. Opportunity Assessment |
| 100 | |
| 101 | **Core concept:** Before investing in any opportunity, evaluate business value, customer need severity, market context, and organizational readiness against a structured set of questions. |
| 102 | |
| 103 | **Why it works:** Organizations have far more ideas than capacity; without rigorous assessment, teams default to the loudest stakeholder or competitor parity. A shared framework kills bad ideas early and focuses resources on high-impact work. |
| 104 | |
| 105 | **Key insights:** |
| 106 | - Key questions: What business objective does this serve? Who is the target customer? What problem? How will we know we succeeded? What alternatives exist? |
| 107 | - Severity of the customer problem matters more than elegance of the solution |
| 108 | - Market timing is critical -- too early is as dangerous as too late |
| 109 | - Check organizational readiness: skills, technology, go-to-market capability |
| 110 | - Share assessments broadly to build alignment before committing resources |
| 111 | |
| 112 | **Product applications:** |
| 113 | |
| 114 | | Context | Application | Example | |
| 115 | |---------|-------------|---------| |
| 116 | | Quarterly planning | Score all candidates on consistent criteria | Customer severity, business impact, feasibility per opportunity | |
| 117 | | Stakeholder requests | Respond with assessment, not commitment | "Let me assess this and share findings before we commit engineering" | |
| 118 | | Resource allocation | Fund highest-assessed opportunities | Severe pain + clear business alignment beats the nice-to-have | |
| 119 | |
| 120 | See [references/opportunity-assessment.md](references/opportunity-assessment.md) when sizing a new opportunity before design work -- the full evaluation-question set, market-timing assessment, and prioritization scoring. |
| 121 | |
| 122 | See [references/stakeholder-management.md](references/stakeholder-management.md) when an executive or sales stakeholder hands you a solution or a HiPPO is steering the roadmap -- stakeholder mapping, turning a mandate into a problem to assess, evangelism, and building executive trust. |
| 123 | |
| 124 | ### 5. Product Vision and Strategy |
| 125 | |
| 126 | **Core concept:** Vision describes the future you're building toward (2-5 years out); strategy sequences the target markets, problems, and solutions that will realize it. Together they give empowered teams the context to make good autonomous decisions. |
| 127 | |
| 128 | **Why it works:** Without vision, teams make disconnected decisions; without strategy, they chase everything and achieve nothing. Vision inspires; strategy focuses. |
| 129 | |
| 130 | **Key insights:** |
| 131 | - Vision is inspiring and customer-centric -- the world you want to create, not a feature list |
| 132 | - Strategy sequences the hard choices: which customers first, which problems first, which solutions first |
| 133 | - Product principles are guardrails for decisions the strategy doesn't cover |
| 134 | - OKRs translate strategy into measurable team objectives; outcome-based roadmaps communicate intent without prescribing solutions |
| 135 | - Revisit vision annually, strategy quarterly; principles change rarely |
| 136 | |
| 137 | **Product applications:** |
| 138 | |
| 139 | | Context | Application | Example | |
| 140 | |---------|-------------|---------| |
| 141 | | Company alignment | Vision aligns all teams on a shared future | "Every small business can access world-class financial tools" | |
| 142 | | Team autonomy | Strategy scopes each team's focus | "This quarter: cut mid-market churn via top 3 pain points" | |
| 143 | | Decision-making | Principles resolve tradeoffs | "When in doubt, choose simplicity over power" | |
| 144 | |
| 145 | **Ethical boundary:** Never present a vision you know is unachievable to motivate teams or attract investment. |
| 146 | |
| 147 | See [references/product-vision.md](references/product-vision.md) when drafting or revisiting vision and strategy -- how to write each, product principles, translating strategy into OKRs, and building outcome-based roadmaps. |
| 148 | |
| 149 | ### 6. Continuous Value Delivery |
| 150 | |
| 151 | **Core concept:** Delivery is not a launch event but a continuous flow of small, validated increments shipped to real users as frequently as possible. |
| 152 | |
| 153 | **Why it works:** Large infrequent releases accumulate risk, delay learning, and create coordination nightmares. The feedback loop between delivery and discovery compounds into a learning engine: ship, measure, learn, adjust. |
| 154 | |
| 155 | **Key insights:** |
| 156 | - Ship small and often; every release is a learning opportunity |
| 157 | - Instrumentation is not optional -- if you cannot measure it, you cannot learn from it |
| 158 | - Feature flags decouple deployment from release, enabling controlled rollouts and quick rollbacks |
| 159 | - MVP is the smallest release that tests a hypothesis, not a half-built product |
| 160 | - Manage technical debt like financial debt: conscious tradeoffs |
| 161 | |
| 162 | **Product applications:** |
| 163 | |
| 164 | | Context | Application | Example | |
| 165 | |---------|-------------|---------| |
| 166 | | Release planning | Independently shippable increments | Basic search first, then filters, then saved searches | |
| 167 | | Risk management | Feature flags for controlled rollout | Ship to 5%, measure, expand or roll back | |
| 168 | | Learning loops | Instrument every release to feed discovery | Low search usage triggers a discovery investigation | |
| 169 | |
| 170 | **Ethical boundary:** Never ship a change you cannot roll back; gate anything risky behind a flag you can flip off. |
| 171 | |
| 172 | See [references/case-studies.md](references/case-studies.md) when you want a worked example before applying the framework -- these principles played out at startup, growth, and enterprise stages. |
| 173 | |
| 174 | ## Common Mistakes |
| 175 | |
| 176 | | Mistake | Why It Fails | Fix | |
| 177 | |---------|-------------|-----| |
| 178 | | Treating PMs as project managers | Order-takers with no ownership of value or viability | Hire for customer knowledge, data fluency, business acumen; hold accountable for outcomes | |
| 179 | | Skipping discovery | Months of engineering on features nobody wants | Require validated evidence before ideas enter the delivery backlog | |
| 180 | | Measuring output, not outcomes | Teams optimize shipping speed over customer value | Define success as adoption, retention, revenue impact | |
| 181 | | Handing teams solutions, not problems | Feature factories with no motivation or creativity | Assign objectives and key results; let teams discover solutions | |
| 182 | | Isolating engineers from customers | Best source of innovation never sees the problem | Include engineers in interviews, discovery, prototype testing | |
| 183 | | Roadmaps of promised features with dates | Commitments calcify before discovery can validate | Use outcome-based roadmaps: problems to solve, not features | |
| 184 | |
| 185 | ## Quick Diagnostic |
| 186 | |
| 187 | | Question | If No | Action | |
| 188 | |----------|-------|--------| |
| 189 | | Can your PM cite the top 3 customer problems from direct observation? | PM lacks customer knowledge | Weekly customer contact: interviews, support shadowing, testing | |
| 190 | | Do you test ideas with real users before building? | Skipping discovery | Prototype-test with 5 target users for every significant idea | |
| 191 | | Are engineers involved in discovery, not just delivery? | Underusing your best innovators | Invite engineers to interviews and prototype sessions | |
| 192 | | Does the team own outcomes (metrics), not output (features)? | Feature factory | Replace feature roadmaps with outcome OKRs | |
| 193 | | Can team members explain the vision and strategy? | No context for autonomous decisions | Create and evangelize a vision doc and quarterly strategy | |
| 194 | | Do stakeholders bring problems, not solutions? | Leadership dictating features | Coach stakeholders on discovery; pre-sell with opportunity assessments | |
| 195 | | Do you ship validated increments at least every two weeks? | Too slow to learn | Smaller increments; invest in CI/CD and feature flags | |
| 196 | |
| 197 | ## Further Reading |
| 198 | |
| 199 | For the complete methodology, case studies, and deeper insights: |
| 200 | |
| 201 | - [*"Inspired: How to Create Tech Products Customers Love"*](https://www.amazon.com/INSPIRED-Create-Tech-Products-Customers/dp/1119387507?tag=wondelai00-20) by Marty Cagan |
| 202 | - [*"Empowered: Ordinary People, Extraordinary Products"*](https://www.amazon.com/EMPOWERED-Ordinary-People-Extraordinary-Products/dp/111969129X?tag=wondelai00-20) by Marty Cagan and Chris Jones |
| 203 | |
| 204 | ## About the Author |
| 205 | |
| 206 | **Marty Cagan** is the founder of Silicon Valley Product Group (SVPG) and a former VP of Product at eBay, with senior product roles at HP, Netscape, and AOL. His book *Inspired* (2008; 2nd ed. 2017) became the definitive guide to modern product management, and *Empowered* (2020) extends the framework to product leadership. Through SVPG he coaches product teams from startups to Fortune 500 enterprises. |
| 207 |
Reviews
Installed this one?Write the first review and take the Trailblazer badge.
Alternatives
Structure Your Invention For A Patent FilingDescribe your invention in plain words and get back a formal write-up that lays out the problem it solves, how it works, and which parts are worth protecting.●····●37/40Claims Drafting: The Core Patent SkillDescribe your invention in plain words and get back a numbered set of formal patent claims — the legal wording that defines exactly what you own.●····●36/40Patent Novelty and Non-Obviousness CheckDescribe your invention in everyday words and get back a clear read on whether it's new and original enough to patent, plus where it might hit trouble.●····●35/40Patent Pipeline: From Invention to FilingDescribe your invention in plain words and get back a complete first-draft patent application — claims, full description, and abstract — ready to hand to a patent attorney.●····●35/40