Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →wondelai/inspired-product
Build empowered product teams using discovery and delivery dual-track.
Passed 23 of 23 test cases with the skill, and 18 of 23 without it.
and 2 more in the full report
5 fixed18 passed either way0 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 5 test cases the skill fixed. Same model, same prompt, with and without the skill.
During a quarterly executive review, a product manager presents data from 2 successful user tests while omitting 8 user tests where participants abandoned the flow in frustration. What ethical standard does this selective reporting violate?
| Checked | Without skill | With skill |
|---|---|---|
| States that product managers must never cherry-pick discovery evidence and must report failed tests alongside passed ones | Missed | Passed |
The instructions your model reads when the skill loads.
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".
test cases passed, vs 18 / 23 without
Published skills whose descriptions closely match this one, with their headline benchmark lift.
More skills from the same source and nearby in the registry, with their headline benchmark lift.