inspired-product

---
name: inspired-product
description: Use when building empowered product teams, structuring discovery and delivery, writing product vision/strategy, or moving a team off a feature-factory roadmap.
category: Product & Growth
version: 1.0.0
tools: []
---

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

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

**Ethical boundary:** Never cherry-pick discovery evidence to justify a conclusion you already chose; report the tests that failed alongside the ones that passed.

### 2. Empowered Product Teams

**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 -- a team that discovered the solution itself defends and refines it under pressure.

**Key insights:**
- 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
- The product designer owns the user experience holistically, not just visual design
- Engineers are the best source of innovation because they know what is technically possible
- Keep teams durable (stable membership) and highly collaborative

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

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

### 3. Product Discovery Techniques

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

**Key insights:**
- Prototypes are the primary tool: high-fidelity for usability, live-data for feasibility, Wizard of Oz for value
- Test with real target users, not colleagues; qualitative testing (5 users) reveals problems, quantitative validates at scale
- Interview for behavior (what they did), not opinion (what they say they want)
- Data reveals patterns but not causes -- pair it with qualitative discovery

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

**Ethical boundary:** Never deceive users beyond what valid results require -- Wizard of Oz prototypes are acceptable; collecting payment for non-existent products is not.

### 4. Opportunity Assessment

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

**Key insights:**
- Key questions: What business objective does this serve? Who is the target customer? What problem? How will we know we succeeded?
- Severity of the customer problem matters more than elegance of the solution
- Market timing is critical -- too early is as dangerous as too late

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

### 5. Product Vision and Strategy

**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:**
- Vision is inspiring and customer-centric -- the world you want to create, not a feature list
- Strategy sequences the hard choices: which customers first, which problems first, which solutions first
- OKRs translate strategy into measurable team objectives; outcome-based roadmaps communicate intent without prescribing solutions

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

**Ethical boundary:** Never present a vision you know is unachievable to motivate teams or attract investment.

### 6. Continuous Value Delivery

**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 and delay learning. The feedback loop between delivery and discovery compounds into a learning engine: ship, measure, learn, adjust.

**Key insights:**
- Ship small and often; every release is a learning opportunity
- Instrumentation is not optional -- if you cannot measure it, you cannot learn from it
- Feature flags decouple deployment from release, enabling controlled rollouts and quick rollbacks
- MVP is the smallest release that tests a hypothesis, not a half-built product

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

**Ethical boundary:** Never ship a change you cannot roll back; gate anything risky behind a flag you can flip off.

## Common Mistakes

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

## Quick Diagnostic

| 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 prescribed solutions? | Roadmap dictated by mandate, not discovery | Push back: turn the mandate into a problem to assess |