76 lines
2.5 KiB
Markdown
76 lines
2.5 KiB
Markdown
|
---
|
||
|
|
name: market-research
|
||
|
|
description: Research market context, competitor behavior, and category expectations to improve PM problem framing, scope decisions, and requirement quality.
|
||
|
|
---
|
||
|
|
|
||
|
|
Use this skill when the user wants market research, competitor analysis, category benchmarking, or when product requirements would benefit from knowing what users already expect in the market.
|
||
|
|
|
||
|
|
This is a pure PM research skill. It exists to improve product definition, not to design implementation.
|
||
|
|
|
||
|
|
## Goals
|
||
|
|
|
||
|
|
Use research to answer:
|
||
|
|
- What problem patterns already exist in the market?
|
||
|
|
- What are users trained to expect from comparable products?
|
||
|
|
- What are table-stakes behaviors versus differentiators?
|
||
|
|
- What risks, trust expectations, or NFR expectations are common in this category?
|
||
|
|
|
||
|
|
## What To Research
|
||
|
|
|
||
|
|
- Competitor messaging and positioning
|
||
|
|
- User-facing workflows and product behavior
|
||
|
|
- Packaging, pricing, and plan boundaries when relevant
|
||
|
|
- Compliance, security, audit, or reliability expectations when relevant
|
||
|
|
- Common success patterns, common gaps, and obvious differentiation opportunities
|
||
|
|
|
||
|
|
## What Not To Do
|
||
|
|
|
||
|
|
- Do not design architecture or modules
|
||
|
|
- Do not infer backend implementation details unless publicly documented and directly relevant to product expectations
|
||
|
|
- Do not reverse-engineer private systems
|
||
|
|
- Do not turn research into engineering tasks
|
||
|
|
- Do not copy competitors blindly; explain the implication for this product and this user context
|
||
|
|
|
||
|
|
## Process
|
||
|
|
|
||
|
|
1. Clarify the research question, target market, target user, and feature area.
|
||
|
|
2. Research public sources to gather evidence.
|
||
|
|
3. Group findings into patterns instead of producing a raw link dump.
|
||
|
|
4. Extract implications for problem framing, scope, acceptance criteria, and NFRs.
|
||
|
|
5. Write a concise research brief.
|
||
|
|
|
||
|
|
## Output
|
||
|
|
|
||
|
|
Save research briefs to `docs/research/{date}-{topic}.md`.
|
||
|
|
|
||
|
|
This file is an input artifact for downstream PM stages:
|
||
|
|
- `brainstorming` may use it to shape scope options and product direction
|
||
|
|
- `write-a-prd` may use it to justify requirements, success metrics, NFRs, and risks
|
||
|
|
|
||
|
|
Use this format:
|
||
|
|
|
||
|
|
## Research Question
|
||
|
|
|
||
|
|
## Target User / Buyer
|
||
|
|
|
||
|
|
## Market Context
|
||
|
|
|
||
|
|
## Competitor Patterns
|
||
|
|
|
||
|
|
## Table Stakes
|
||
|
|
|
||
|
|
## Differentiation Opportunities
|
||
|
|
|
||
|
|
## Risks And Expectations
|
||
|
|
|
||
|
|
## Implications For Requirements
|
||
|
|
|
||
|
|
## Sources
|
||
|
|
|
||
|
|
## Guidance
|
||
|
|
|
||
|
|
- Prefer direct evidence over broad speculation
|
||
|
|
- Prefer 3-5 strong comparable products over 20 shallow mentions
|
||
|
|
- Call out confidence level when evidence is weak
|
||
|
|
- Tie findings back to user-visible behavior, scope, and NFR expectations
|