inspired-product

The saved excerpt is a snapshot from when this skill was listed. The external source remains the complete and most current version.

---
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"
---

# 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.

**Key insights:**
- 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?)
- Discovery output is validated ideas backed by evidence, not PRDs or specifications
- Run 10-20 discovery iterations per feature that reaches delivery -- most ideas won't work, so fail fast and cheap
- Discovery is not a phase; it runs continuously alongside delivery, with engineers participating

**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](references/discovery-techniques.md) when planning a discovery cycle -- the four-risks framework, a 5-stage interview script, prototyping techniques, and concrete evidence