product-skills

---
name: product-skills
description: Use when routing a product-team request to the right specialized workflow, or running weekly continuous-discovery loops with opportunity-tree and cadence checks.
category: Product
version: 1.0.0
tools: []
---

# Product Team Orchestrator & Discovery Loop

Route product inquiries to the right specialized workflow, and run product discovery as a bounded, recurring loop with checkable gates rather than a one-off project phase.

## Routing

| Symptom | Route to |
|---|---|
| Prioritize features / RICE / PRD scope | Product Manager Toolkit |
| OKRs, strategy cascade | Product Strategy |
| Personas, usability, research synthesis | UX Research & Design |
| Design tokens, WCAG contrast | UI Design System |
| Competitor matrix, teardown | Competitive Teardown |
| Retention, cohorts, funnels, KPIs | Product Analytics |
| A/B test, sample size, hypothesis | Experiment Design |
| Discovery, assumptions, opportunity trees | Product Discovery |
| Roadmap comms, release notes, changelog | Roadmap Communication |
| Spec → runnable repo | Spec-to-Repo |
| Landing page (Next.js/Tailwind) | Landing Page Generator |
| SaaS boilerplate | SaaS Scaffolder |
| User stories, sprint capacity | Agile Product Owner |
| Apple HIG audit | Apple HIG Expert |
| PRD from an existing codebase | Code → PRD |
| Summarize papers/articles | Research Summarizer |

Classify the goal against this table. If it clearly matches one row, follow that workflow. If it's ambiguous between two or three rows, ask one clarifying question naming the candidates with a recommended answer — never guess silently, and never silently chain multiple workflows without confirming first. If there's no signal at all, ask the user to restate the goal with the deliverable named.

## The Discovery Loop

Modern discovery is a weekly habit, not a project phase (Torres, *Continuous Discovery Habits*). Run it as a bounded loop with two checkable gates:

1. **Observe** — maintain a log of interviews and assumption tests, and score its cadence: health 0–100, a verdict of HEALTHY / AT-RISK / DORMANT, named gaps, and a recommended next action. Refuse to score a cadence from fewer than 2 interviews — there's no cadence yet to measure.
2. **Choose** — the recommended next action from step 1 IS the choice: book the next touchpoint, re-anchor the interview guide on the outcome, or test the top untested assumption (hand off to Product Discovery for prioritization).
3. **Act** — run the interview or assumption test using the routed workflow's methods.
4. **Verify** — before an Opportunity Solution Tree may drive a roadmap, check it against five structural rules: one measurable outcome at the root (O1); opportunities are stated as needs, not features (O2); any targeted opportunity compares at least 2 candidate solutions (O3); every solution has an assumption test attached (O4); no orphan solutions with no opportunity above them (O5 — the feature-factory tell). A tree that fails any rule needs rework before it's cited.
5. **Record and repeat** — update the log, keep the weekly streak alive. On HEALTHY plus a validated assumption, graduate to Experiment Design (build the A/B gate) or the Product Manager Toolkit (write the PRD). On DORMANT for 4+ weeks, escalate to the product lead by name rather than letting discovery quietly die.

For build-scale goals ("turn this validated spec into a repo and verify it"), compile a plan against the domain's three strongest close-out gates: a runnable-project validation check, Code → PRD's golden-output comparison, and Research Summarizer's citation-count check.

## Hard Rules

1. **Evidence before conviction** — no roadmap item cites the opportunity tree unless it passes all five structural rules; no insight is asserted from a single participant (that's an anecdote, not an insight).
2. **Outcome-first** — every loop hangs from one measurable outcome; rule O1 is the intake gate for anything entering discovery.
3. **Experiments are gated by math** — compute required sample size from baseline rate and minimum detectable effect before running a test; never launch on gut feel, and report the MDE alongside the verdict.
4. **Prioritization shows its framework** — RICE for steady-state prioritization, WSJF/cost-of-delay when time sensitivity dominates, opportunity scoring for underserved needs. Name which framework was used and why.
5. **AI features ship with evals** — a golden set plus a rubric is the quality contract for any probabilistic feature; a PRD for an AI feature without one is incomplete.
6. **Never modify a gate you're judged by** — an exhausted budget escalates to a named human; it is never silently reported as success.

## Forcing Questions (One Per Turn, With a Recommendation)

Before running a sub-workflow or starting a loop, lock the lane-defining decision:

- **Discovery**: "What is the single outcome this discovery serves, stated with a number?" Recommended: write it as the tree's root first — opportunities without an outcome are a feature factory (Torres; opportunity solution trees).
- **Prioritize**: "Does time sensitivity change this ranking — would delaying any item a quarter erode its value?" Recommended: if yes, run WSJF/cost-of-delay alongside RICE and flag any item whose rank flips on a one-step estimate change (Reinertsen, *Principles of Product Development Flow*).
- **Experiment**: "What baseline rate and minimum detectable effect justify this test's runtime?" Recommended: compute the required sample size first; if it can't be reached in 4 weeks, test a bigger lever.
- **Analytics**: "Is your North Star a leading indicator of value exchange, or a revenue/vanity metric?" Recommended: a leading value metric with an input tree (Amplitude, *The North Star Playbook*).
- **Strategy**: "Are these OKRs outcomes or shipping lists?" Recommended: outcomes — output-shaped OKRs are the most common operating-model failure (Cagan, *Transformed*).
- **Build lanes** (spec-to-repo / SaaS scaffolder): "Which validated assumption says this should be built at all?" Recommended: link the assumption test that survived — building is the most expensive way to test an idea (Torres; Bland, *Testing Business Ideas*).

## Scope

This is the product domain's router plus its discovery gates — not sprint/flow delivery work (that's a project-management concern), not a generic task-loop engine, and not campaign marketing (a from-scratch marketing page is a different workflow than the product-facing landing-page generator listed above).

## Anti-Patterns

Don't run every lane "to be thorough" — route to one, digest, and chain only on confirmation. Don't cite an opportunity tree that fails the structural check, or promote a single-participant anecdote to an insight. Don't ship an AI feature whose PRD has no eval. Don't let a discovery streak die silently — DORMANT escalates by name. Don't treat RICE as the only lens when deadlines dominate the decision.