Skill detail
market-research
Direct market research but narrowly focused on vertical pain hypotheses.
Inspect before use
Automated review checks relevance, not safety or endorsement. Read the source instructions before using this skill.
SKILL.md
The saved excerpt is a snapshot from review. The external source remains the complete and most current version.
---
name: market-research
description: >
Research a target vertical's pain points using deep research APIs and distill
findings into a numbered hypothesis set. Pure industry education tool —
decoupled from email generation. Use when the user wants to understand a
market before outreach, form hypotheses about a vertical, or build an
industry knowledge base. Triggers on: "deep research", "hypothesis set",
"research pain points", "research vertical", "sourcing research", "pain
mapping", "industry problems", "market research", "educate me on".
---
# Market Problems Deep Research
Research a target vertical's pain points using deep research APIs. Distill findings into a numbered hypothesis set. Output is pure industry education — no email generation, no company matching.
## Environment
Provider selection and credentials are handled in Step 0 of the workflow.
## Workflow
### Step 0: Confirm provider and learn API
1. Ask the user which deep research provider they want to use. If they're unsure, Perplexity is a common choice — see workflow below for query design patterns.
2. Fetch or read the provider's API documentation and identify:
- Chat/completions or search endpoint
- Available models (pick the one with web search / citations)
- Authentication method and credentials
- Rate limits
3. Ask for their API credentials and confirm access before proceeding
### Step 1: Define the research scope
Read the company context file if it exists (`claude-code-gtm/context/{company}_context.md`) for ICP and existing hypotheses.
Ask the user for:
| Input | Required | Example |
|-------|----------|---------|
| Target vertical | yes | "Mid-market logistics companies" |
| Specific sub-verticals | yes | "3PL, freight brokerage, cold chain" |
| What we solve for them | yes | "Find potential partners and customers in fragmented markets" |
| Existing hypotheses to test | no | From context file or user input |
### Step 2: Run hypothesis-driven research
Do NOT run generic research. Run 3-4 focused queries, each targeting a different angle of the same problem. The queries should be specific enough to return actionable data points, not overviews.
**Query design principles:**
- Each query should target ONE specific aspect of the pain
- Ask for concrete data points, numbers, timelines, tool names
- Ask for workflow descriptions, not abstractions
- Ask for failure modes and workarounds
- Keep queries vertical-agnostic in structure — the vertical comes from Step 1
Run each query through the chosen provider's API (from Step 0).
**Standard 3-query framework:**
Query 1 — **Workflow pain**: "What is the specific day-to-day workflow for [role] at [company type] when they [task we solve]? What tools do they use? Where do those tools fail? How long does each step take? Give concrete examples and data points."
Query 2 — **Tool/database gaps**: "How well do [existing tools] cover [target segment]? What percentage of the market do they miss? Why do [target companies] fall through the cracks? What data is wrong or stale? Give specific numbers."
Query 3 — **Scaling problems**: "What happens when [company type] tries to scale [process] beyond the initial [easy phase]? What breaks? What are the real-world failure stories? How do they work around it? What does it cost?"
**Optional Query 4 — Industry leaders and public statements**: "Who are the recognized thought leaders in [vertical]? What have they said publicly about [pain area] in the last 12 months? Include quotes, conference talks, blog posts, LinkedIn posts. Focus on practitioners, not analysts."
### Step 3: Distill into numbered hypothesis set
Read all research responses and extract distinct, non-overlapping pain points. Each hypothesis should be:
- **Specific**: tied to a concrete workflow step, tool failure, or scaling problem
- **Quantified**: includes at least one data point (hours, percentages, dollar amounts)
- **Verifiable**: the recipient can confirm it from their oRead the full source on GitHub (opens external page)