# How the /discover Command Structures the Full Product Discovery Cycle

> Learn how the /discover command structures the full product discovery cycle. Explore the seven-stage AI orchestrated workflow from context gathering to experiment design.

- Repository: [Pawel Huryn/pm-skills](https://github.com/phuryn/pm-skills)
- Tags: how-to-guide
- Published: 2026-06-12

---

**The `/discover` command orchestrates a seven-stage product discovery workflow by chaining specialized AI skills into an interactive, time-boxed process that moves from context gathering to validated experiment design.**

The `phuryn/pm-skills` repository implements a modular, markdown-driven approach to product management automation. At its core, the `/discover` command serves as the primary entry point for executing a complete **product discovery cycle**, transforming raw user prompts into structured discovery plans through a sequence of composable skills.

## The Seven Stages of the Product Discovery Cycle

The command defined in [`pm-product-discovery/commands/discover.md`](https://github.com/phuryn/pm-skills/blob/main/pm-product-discovery/commands/discover.md) executes a rigorous end-to-end process. Each stage represents a checkpoint where users can redirect, skip, or dive deeper while maintaining momentum within a 15–30 minute time box.

### Context Gathering: Existing vs. New Products

The workflow begins by determining discovery scope. The system distinguishes between **continuous discovery** for existing products and **initial discovery** for new products. Users provide the discovery question, known data sources, and the specific decisions the discovery will inform. This context gates subsequent skill selection, ensuring relevant methodology for mature features versus zero-to-one initiatives.

### Idea Brainstorming: Cross-Functional Generation

Next, the command invokes either **`brainstorm-ideas-existing`** or **`brainstorm-ideas-new`** depending on the initial context. These skills generate ten divergent ideas spanning product management, design, and engineering perspectives. The user then selects 3–5 ideas to carry forward, filtering the solution space before deeper investment.

### Assumption Identification: Risk Categorization

For each selected idea, the system surfaces critical assumptions using **`identify-assumptions-existing`** or **`identify-assumptions-new`**. These skills map assumptions across five risk categories: **Value**, **Usability**, **Feasibility**, **Viability**, and **Go-to-Market** (the latter applying only to new products). This framework ensures comprehensive risk assessment before committing resources.

### Assumption Prioritization: Impact × Risk Matrix

The **`prioritize-assumptions`** skill visualizes every identified assumption on an **Impact × Risk** matrix. It highlights "leap-of-faith" assumptions—those with high potential impact but high uncertainty—and ranks them by testing priority. This quantitative prioritization prevents teams from testing trivial assumptions while ignoring deal-breakers.

### Experiment Design: Validation Methods

For each top-priority assumption, **`brainstorm-experiments-existing`** or **`brainstorm-experiments-new`** designs 1–2 concrete validation experiments. The skill proposes specific methodologies including A/B tests, fake door tests, interactive prototypes, pretotypes, and landing pages. Each experiment specification includes success criteria, estimated effort, and timeline requirements.

### Discovery Plan Assembly: Documentation

All outputs compile into a comprehensive markdown discovery plan. This document records the initial context, generated ideas, selected concepts, critical assumptions, the experiment matrix, and a short-term execution timeline. The system saves this plan to the user's workspace, creating a persistent record of the discovery process.

### Next-Step Suggestions: Actionable Outputs

The final stage offers optional follow-up actions based on the discovery outcomes. Users can choose to generate a PRD, draft customer interview scripts, set up success metrics, or create effort estimates and user stories. This bridges the gap between discovery and delivery.

## Interactive Checkpoints and Time Boxing

Unlike rigid linear processes, the `/discover` command implements **interactive checkpoints** at each stage. Users can pause to gather more data, pivot to alternative ideas, or accelerate through familiar territory. The architecture intentionally constrains the total cycle to approximately 15–30 minutes, enforcing rapid iteration over exhaustive documentation.

## Modular Skill Architecture

The command's design decouples workflow orchestration from execution logic. Each stage invokes a discrete skill defined in separate markdown files under `pm-product-discovery/skills/`. Swapping a skill—for example, substituting a custom brainstorming module—requires only updating the skill reference in [`discover.md`](https://github.com/phuryn/pm-skills/blob/main/discover.md), not rewriting the entire command. This modularity enables teams to customize the **product discovery cycle** without breaking the orchestration layer.

## Usage Examples

Invoke the command with a descriptive prompt to trigger the full workflow:

```markdown

# New product discovery

/discover AI writing assistant for non-native speakers

```

```markdown

# Existing product feature discovery

/discover Smart notification system for our project management tool

```

A typical interactive flow proceeds as follows:

```

/discover Smart notification system for our project management tool
→ Brainstorm ideas (10 suggestions)
→ User selects 4 ideas
→ Identify assumptions for each idea
→ Prioritize assumptions (high-impact / high-uncertainty)
→ Design experiments (e.g., A/B test notification banner, fake-door landing page)
→ Generate discovery plan markdown
→ Offer next steps (create PRD, draft interview script, etc.)

```

## Summary

- The `/discover` command implements a seven-stage **product discovery cycle** through skill composition.
- Key files include [`pm-product-discovery/commands/discover.md`](https://github.com/phuryn/pm-skills/blob/main/pm-product-discovery/commands/discover.md) and four specialized skills under `pm-product-discovery/skills/`.
- The workflow covers context gathering, idea brainstorming, assumption identification, assumption prioritization, experiment design, plan assembly, and next-step generation.
- Risk categories span Value, Usability, Feasibility, Viability, and Go-to-Market.
- Interactive checkpoints allow redirection while maintaining a 15–30 minute time box.
- Modular architecture enables customization by swapping individual skills without affecting the overall command structure.

## Frequently Asked Questions

### What is the difference between new and existing product discovery?

The command branches at multiple stages based on product maturity. For **existing products**, it uses `brainstorm-ideas-existing`, `identify-assumptions-existing`, and `brainstorm-experiments-existing`, focusing on continuous improvement and feature expansion. For **new products**, it switches to the `-new` variants of these skills, adds the **Go-to-Market** risk category to assumption analysis, and emphasizes validation of core value hypotheses over incremental optimization.

### How long does the /discover command take to complete?

The workflow is intentionally **time-boxed to 15–30 minutes**. Each stage acts as a checkpoint where users can expedite or elaborate, but the default pacing ensures rapid progression from problem statement to experiment design. This constraint prevents analysis paralysis while still producing actionable discovery plans.

### Can I customize the skills used in the discovery cycle?

Yes. The architecture is fully modular. To customize a stage, modify the skill reference in [`pm-product-discovery/commands/discover.md`](https://github.com/phuryn/pm-skills/blob/main/pm-product-discovery/commands/discover.md) or create new skills under `pm-product-discovery/skills/`. The command orchestrator treats skills as interchangeable units, allowing teams to substitute proprietary brainstorming methods or industry-specific experiment frameworks without altering the core workflow logic.

### What types of experiments does the command suggest?

The **`brainstorm-experiments`** skills propose validation methods including **A/B tests**, **fake door tests** (buttons that don't exist yet), **interactive prototypes**, **pretotypes** (minimal manual tests), and **landing pages** for demand testing. Each suggestion includes specific success criteria, effort estimates, and timelines, enabling immediate execution planning.