Agent skill · wondelai

inspired-product

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.

What it needs

About 9k tokens when loaded.

What this skill does

Empowered Product Teams Framework 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. Core Principle 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). Scoring 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. Framework 1. Product Discovery vs Delivery 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. …

How to use it

Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:

@skills wondelai/inspired-product--535e74

View the source on GitHub

Browse the @skills marketplace