Product Manager: Typical Commands

Product Manager: Typical Commands

Commands that product manager projects typically have.

Seeding Commands (Extract Product Thinking)

/explore "[topic]"

Purpose: Open-ended PM ideation on a topic or question through reverse prompting.

What it does:

1. Reads current hypothesis from tracking/hypothesis.md (if one exists)
2. Reads relevant product context (vision, user-segments, feature-concepts)
3. Asks the founder to describe the topic or question
4. Uses one-question-at-a-time reverse prompting to go deeper
5. Pushes for specificity and testability throughout
6. Captures insights to appropriate product/ files
7. Updates tracking/session-log.md

PM voice behaviors:

• "Who is the user here? Be specific."
• "What's the job to be done?"
• "How would we test this with $10K and 2 weeks?"
• "That sounds like a feature. What's the problem it solves?"

Key requirement: Never accept vague answers. Always push toward testable, specific thinking.

/process

Purpose: Ingest external input (transcripts, documents, conversations) and extract product insights.

What it does:

1. Accepts pasted text, file reference, or transcript reference
2. Reads material and identifies product-relevant insights
3. Uses reverse prompting to clarify: "What's the product takeaway here?"
4. Connects new insights to prior context (references existing product/ files)
5. Flags contradictions with previous thinking
6. Writes structured insights to appropriate product/ files
7. Updates tracking/insights-log.md

Variants:

• /process transcript — Optimize for conversation transcripts (Granola, meeting notes)
• /process document — Optimize for documents, articles, research
• /process feedback — Optimize for user feedback, support tickets

Key insight: The value isn't summarizing — it's connecting new information to existing product context and surfacing what changed.

/research "[product or domain]"

Purpose: Analyze comparable products or market areas.

What it does:

1. Accepts a product name, URL, or domain area
2. Uses web search/fetch to gather information
3. Analyzes through PM lens: positioning, features, pricing, gaps
4. Produces structured comparison: what to borrow, what to avoid, relationship to our hypothesis
5. Uses reverse prompting: "What resonates for you? What's missing from their approach?"
6. Writes to product/competitive-landscape.md

Key principle: Research is mixed mode — web research (direct) followed by "what does this mean for us?" (reverse).

Cultivation Command (Challenge + Connect)

/synthesize

Purpose: Step back from accumulated context and find patterns.

What it does:

1. Reads ALL context files: context/, product/, tracking/
2. Identifies emerging themes across sessions
3. Surfaces contradictions and tensions
4. Notes what's crystallizing (ready for shaping) vs. what's still fuzzy
5. Uses mixed mode: analytical report + reverse prompting ("Does this match your intuition?")
6. Writes findings to tracking/insights-log.md

When to use: After several /explore or /process sessions, when there's enough material to find patterns.

Key requirement: Should work gracefully when context is sparse — "Not enough sessions yet to see patterns. Here's what I have so far..." rather than generating patterns from noise.

Strategy Command (The Anchor)

/hypothesis

Purpose: View, propose, or refine the product hypothesis — the central strategic artifact.

Three modes:

1. View — Show current hypothesis and test metrics (reads tracking/hypothesis.md)
2. Propose — Founder presents a hypothesis, PM pressure-tests it through reverse prompting
3. Refine — Revisit existing hypothesis in light of new information

PM voice behaviors:

• "Can you test that? What would prove it wrong?"
• "That's three hypotheses. Which one is the bet?"
• "Your hypothesis says X but your feature list says Y. Reconcile."
• "What's the cheapest way to validate this?"

Key principle: The hypothesis is the strategy anchor. Every /spec, /plan, and /explore session should reference it. If the hypothesis is unclear, the PM should push to clarify it before speccing anything.

Output: Updates tracking/hypothesis.md with current hypothesis, confidence level, test plan, and evidence.

Shaping Commands (Generate Artifacts)

/spec "[feature or concept]"

Purpose: Write formal feature specs or PRDs from cultivated thinking.

What it does:

1. Accepts a feature concept (must have been explored in prior sessions)
2. Reads product context and hypothesis
3. Enforces "only write what we know" — refuses to spec undiscovered things
4. Challenges during generation: "You're speccing X but haven't addressed Y"
5. Generates spec document in docs/specs/
6. References hypothesis as the decision lens for scope and priority

Spec structure:

• Problem statement
• User stories
• Requirements (must-have, should-have, won't-have)
• Success metrics
• Dependencies and constraints
• Open questions

Key principle: Specs are for ideas that have been explored and cultivated enough to articulate clearly. If the PM has to make up too many details, the idea isn't ready.

/plan "[spec or feature set]"

Purpose: Break specs into epics, stories, and tickets for implementation.

What it does:

1. Accepts a spec or set of specs
2. Breaks features into epics → stories → tickets
3. Establishes dependencies and execution order
4. Creates Linear tickets (S and M sizing, each completable in a single session)
5. Creates local tracking files (tickets.yaml, build-progress.md)
6. Sets up blockedBy relationships in Linear

Key principle: Tickets should be self-contained and executable by a fresh dev agent. Include enough context, specific acceptance criteria, and clear input/output files.

Operations Commands (Session Management)

/status

Purpose: Quick orientation at session start.

What it does:

1. Reads tracking/hypothesis.md — current hypothesis state
2. Reads tracking/session-log.md — what happened in recent sessions
3. Reads tracking/insights-log.md — accumulated insights
4. Shows state of open questions from context/questions.md
5. Recommends what to work on next

Key principle: Fast and focused. The founder should know where they are in 30 seconds.

/gaps

Purpose: Assess what's been captured vs. what's needed.

What it does:

1. Reads all context files and product files
2. Assesses completeness across dimensions: hypothesis clarity, user understanding, competitive awareness, feature definition, spec readiness
3. Produces prioritized gap list with recommended next steps
4. Suggests specific commands to run

Assessment dimensions (adapt per project):

• Hypothesis maturity (none → proposed → tested → validated)
• User segment clarity (vague → described → validated)
• Competitive understanding (unknown → researched → positioned)
• Feature concepts (brainstormed → explored → spec-ready)
• Specs produced (none → in progress → ready for dev)

/checkpoint

Purpose: End-of-session capture — externalize important thinking before context is lost.

What it does:

1. Reviews what was discussed/decided this session
2. Captures decisions made, open questions surfaced, next steps identified
3. Writes dated entry to tracking/session-log.md
4. Updates any tracking files that changed during the session
5. Updates tracking/next-actions.md with prioritized queue

Key principle: Err on the side of capturing too much. Session context disappears; files persist.

Command Principles

Hypothesis Is the Lens

Every command should be aware of the current hypothesis. /explore references it. /spec uses it for scope decisions. /gaps measures against it.

Reverse Prompting for Discovery

Seeding commands (explore, process) are predominantly reverse prompting — Claude asks, founder answers. The PM extracts and structures what the founder knows but hasn't articulated.

Direct Prompting for Generation

Shaping commands (spec, plan) are predominantly direct prompting — the PM generates artifacts from accumulated context. The founder reviews and refines.

"Only Write What We Know"

Don't generate from thin air. If context is insufficient, say so and recommend more seeding. A bad spec is worse than no spec.

Testability

Everything should be testable. Hypotheses need test plans. Features need success metrics. User segments need validation methods.

One Question at a Time

Commands that use reverse prompting ask one question, wait for the answer, then follow up. Don't overwhelm.

Living Documents

Tracking files (hypothesis, insights, session-log) should reflect current state. Update to stay true, not just append.

Command Dependencies

                    ┌──────────────────────────────────────────┐
                    │           Discovery Flow                  │
                    │                                           │
                    │  /explore ──► /process ──► /research      │
                    │     │            │             │          │
                    │     ▼            ▼             ▼          │
                    │  product/    product/     competitive-    │
                    │  files       files        landscape.md    │
                    └──────────────────────────────────────────┘
                                      │
                                      ▼
                    ┌──────────────────────────────────────────┐
                    │          Strategy Flow                     │
                    │                                           │
                    │  /synthesize ──► /hypothesis               │
                    │     │               │                     │
                    │     ▼               ▼                     │
                    │  insights-       hypothesis.md            │
                    │  log.md          (the anchor)             │
                    └──────────────────────────────────────────┘
                                      │
                                      ▼
                    ┌──────────────────────────────────────────┐
                    │           Shaping Flow                     │
                    │                                           │
                    │  /spec ──► /plan ──► Linear tickets       │
                    │     │         │                           │
                    │     ▼         ▼                           │
                    │  docs/     tickets.yaml                   │
                    │  specs/    → dev project                  │
                    └──────────────────────────────────────────┘

Cross-cutting: /status (session start), /gaps (assessment), /checkpoint (session end)