Domain Product Research

Use this skill when you need to understand a product, company, competitor set, market wedge, or moat without turning the research into generic hype.

This is a curated, model-agnostic skill template. It works well with Codex when you can provide source material, local context, and a decision that the research should support.

Problem This Skill Solves

Product research often collapses into feature lists or confident market claims. That is not enough for a real decision.

This skill separates facts, claims, assumptions, interpretation, and invalidation tests so the output can support strategy, roadmap, or GTM decisions.

Inputs

• Product, company, competitor, or market to research
• Decision the research should support
• Source links, notes, internal context, or customer evidence
• Competitor set or alternatives
• Time horizon and risk tolerance
• Known assumptions to test

Step-by-Step Onboarding Guide

1. State the decision first, such as "Should we build this feature?" or "Which wedge should we test?"
2. List the product, market, or competitor set.
3. Provide source material and mark which sources are strongest.
4. Ask Codex to build an evidence matrix before writing conclusions.
5. Require separate sections for facts, assumptions, open questions, and interpretation.
6. Ask for invalidation criteria: what would prove the thesis wrong.
7. Convert the research into a recommendation and monitoring plan.

Example Use Case

Target user: a product manager evaluating whether to promote a new AI skill workflow.

Workflow:

1. Provide the skill description, public page, competitor examples, and user problem.
2. Use this skill to map customer pain, product wedge, alternatives, and moat.
3. Ask Codex to label evidence as public source, internal workflow, demo, or hypothesis.
4. Ask for the highest-risk unsupported claims.
5. Turn the result into a decision memo for roadmap or GTM planning.

Expected artifact: an evidence-led product research memo with customer problem, market wedge, competitor pressure, moat hypothesis, risk, and recommendation.

Workflow

1. Define the research question and the decision it supports.
2. Gather only the evidence lanes needed.
3. Separate facts, claims, assumptions, and open questions.
4. Map customer problem, product wedge, competitor pressure, and moat.
5. State what would make this product, company, or market thesis wrong.
6. End with a recommendation and what to monitor next.

Output Contract

Return:

• research question
• decision context
• evidence matrix
• customer problem
• product wedge
• competitor and alternative map
• moat hypothesis
• risks and invalidation criteria
• recommendation
• monitoring plan

Guardrails

• Do not confuse attention with adoption.
• Do not confuse feature lists with a moat.
• Do not pretend weak evidence is strong just to keep momentum.
• Do not invent customer proof, revenue, rankings, or market share.
• If evidence is thin, state that the recommendation is a hypothesis.