Loading
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",
The skill file stays in the publisher's repository.
Paste the copied command in a terminal. It installs this SKILL.md into that agent.
npx skills add wondelai/skills --skill inspired-product -a cursor -y
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.
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.
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.
Empowered product teams = cross-functional groups given problems to solve (not features to build) who own discovery and delivery end-to-end.
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).
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.
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.
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.
Key insights:
Product applications:
| Context | Application | Example |
|---|---|---|
| New feature | Validate all four risks before committing | Prototype-test onboarding flow with 5 users before building |
| Roadmap prioritization | Prioritize strongest discovery evidence | Ship the feature with 4/5 successful user tests, not the CEO's request |
| Sprint planning | Feed backlog from validated discovery output | Only discovery-tested items enter the sprint |
Ethical boundary: Never cherry-pick discovery evidence to justify a conclusion you already chose; report the tests that failed alongside the ones that passed.
See 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".
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.
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.
Key insights:
Product applications:
| Context | Application | Example |
|---|---|---|
| Team structure | Organize around outcomes, not components | "New user activation" team owns the whole first-week experience |
| Hiring | Hire PMs for competence, not credentials | Evaluate customer knowledge, data fluency, business acumen |
| Performance | Measure results, not velocity | Track activation-rate improvement, not stories per sprint |
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.
See 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.
Core concept: Systematically test ideas against the four risks using opportunity assessment, customer interviews, prototyping, and user testing -- producing evidence quickly and cheaply.
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.
Key insights:
Product applications:
| Context | Application | Example |
|---|---|---|
| Early idea | Opportunity assessment before design work | Who is it for, what problem, how will we measure success? |
| Usability | High-fidelity prototype with 5 target users | Clickable Figma prototype testing task completion |
| Value | Fake door or Wizard of Oz test | Button for unbuilt feature, measure click-through |
| Feasibility | Engineering spike | Two-day investigation of real-time sync risk |
Ethical boundary: Never deceive users beyond what valid results require -- Wizard of Oz prototypes are acceptable; collecting payment for non-existent products is not.
Core concept: Before investing in any opportunity, evaluate business value, customer need severity, market context, and organizational readiness against a structured set of questions.
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.
Key insights:
Product applications:
| Context | Application | Example |
|---|---|---|
| Quarterly planning | Score all candidates on consistent criteria | Customer severity, business impact, feasibility per opportunity |
| Stakeholder requests | Respond with assessment, not commitment | "Let me assess this and share findings before we commit engineering" |
| Resource allocation | Fund highest-assessed opportunities | Severe pain + clear business alignment beats the nice-to-have |
See references/opportunity-assessment.md when sizing a new opportunity before design work -- the full evaluation-question set, market-timing assessment, and prioritization scoring.
See 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.
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.
Why it works: Without vision, teams make disconnected decisions; without strategy, they chase everything and achieve nothing. Vision inspires; strategy focuses.
Key insights:
Product applications:
| Context | Application | Example |
|---|---|---|
| Company alignment | Vision aligns all teams on a shared future | "Every small business can access world-class financial tools" |
| Team autonomy | Strategy scopes each team's focus | "This quarter: cut mid-market churn via top 3 pain points" |
| Decision-making | Principles resolve tradeoffs | "When in doubt, choose simplicity over power" |
Ethical boundary: Never present a vision you know is unachievable to motivate teams or attract investment.
See 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.
Core concept: Delivery is not a launch event but a continuous flow of small, validated increments shipped to real users as frequently as possible.
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.
Key insights:
Product applications:
| Context | Application | Example |
|---|---|---|
| Release planning | Independently shippable increments | Basic search first, then filters, then saved searches |
| Risk management | Feature flags for controlled rollout | Ship to 5%, measure, expand or roll back |
| Learning loops | Instrument every release to feed discovery | Low search usage triggers a discovery investigation |
Ethical boundary: Never ship a change you cannot roll back; gate anything risky behind a flag you can flip off.
See references/case-studies.md when you want a worked example before applying the framework -- these principles played out at startup, growth, and enterprise stages.
| Mistake | Why It Fails | Fix |
|---|---|---|
| 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 |
| Skipping discovery | Months of engineering on features nobody wants | Require validated evidence before ideas enter the delivery backlog |
| Measuring output, not outcomes | Teams optimize shipping speed over customer value | Define success as adoption, retention, revenue impact |
| Handing teams solutions, not problems | Feature factories with no motivation or creativity | Assign objectives and key results; let teams discover solutions |
| Isolating engineers from customers | Best source of innovation never sees the problem | Include engineers in interviews, discovery, prototype testing |
| Roadmaps of promised features with dates | Commitments calcify before discovery can validate | Use outcome-based roadmaps: problems to solve, not features |
| Question | If No | Action |
|---|---|---|
| Can your PM cite the top 3 customer problems from direct observation? | PM lacks customer knowledge | Weekly customer contact: interviews, support shadowing, testing |
| Do you test ideas with real users before building? | Skipping discovery | Prototype-test with 5 target users for every significant idea |
| Are engineers involved in discovery, not just delivery? | Underusing your best innovators | Invite engineers to interviews and prototype sessions |
| Does the team own outcomes (metrics), not output (features)? | Feature factory | Replace feature roadmaps with outcome OKRs |
| Can team members explain the vision and strategy? | No context for autonomous decisions | Create and evangelize a vision doc and quarterly strategy |
| Do stakeholders bring problems, not solutions? | Leadership dictating features | Coach stakeholders on discovery; pre-sell with opportunity assessments |
| Do you ship validated increments at least every two weeks? | Too slow to learn | Smaller increments; invest in CI/CD and feature flags |
For the complete methodology, case studies, and deeper insights:
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.