Product Review

Product Review

Use this skill when a product idea has moved beyond early discovery and needs measurable review. It covers two connected moments:

• Before launch: define analytics instrumentation, event tracking, success metrics, guardrails, privacy handling, and data QA.
• After launch: review metrics, feedback, experiments, and market signals to decide whether to continue, pivot, stop, or restructure.

Do not use this skill for early product demand analysis, user research synthesis, competitor analysis, PRD writing, acceptance criteria, UI handoff, or engineering breakdown. Use this skill only when there is a concrete feature, MVP, release, experiment, funnel, or shipped product behavior to measure or review.

Route The Work

Choose the lightest useful path:

Required Inputs

Start by listing what the user provided and what is missing:

• Product, feature, MVP, release, or experiment name.
• Product goal and behavior to understand.
• Available metrics, data sources, analytics platform, or event logs.
• User feedback, customer quotes, sales/support notes, experiment results, or market signals.
• Constraints: privacy, consent, retention, platform, engineering ownership, launch date.

Ask only for missing inputs that materially change the review. If the user wants a first draft, proceed with explicit assumptions.

Instrumentation Instructions

1. Start from decisions, not data volume: name the product questions this data must answer.
2. Define success and guardrail metrics: include activation, conversion, retention, quality, latency, privacy, or revenue metrics when relevant.
3. Create event inventory: specify event name, trigger, description, properties, required flags, examples, and owner notes.
4. Use precise triggers: distinguish click, submit attempt, successful completion, failure, timeout, abandonment, and retry.
5. Define user properties carefully: include only persistent segmentation attributes that are needed for analysis.
6. Address privacy: flag PII, consent requirements, hashing/exclusion, retention, and regional constraints.
7. Add QA checks: list how engineering/QA will verify events, properties, edge cases, and dashboards before launch.

Use references/instrumentation.md as the default output structure. If the user asks for machine-readable output, use the JSON shape in references/analytics-json-schema.md.

Release Review Instructions

1. Summarize current state: what shipped, when, investment to date, and what result was expected.
2. Present evidence without cherry-picking: include metrics, qualitative feedback, experiment results, market signals, and data limitations.
3. Review hypotheses: mark each as validated, invalidated, partially validated, or untested.
4. Define options: include continue/persevere plus at least two concrete alternatives when the decision is strategic.
5. Compare options: evaluate market opportunity, user value, business impact, team capability, resource needs, risk, and confidence.
6. Make or frame the decision: state the recommended direction, rationale, trade-offs, dissent, and confidence.
7. Plan next checkpoints: include immediate actions, owners if known, success criteria, and the next decision date.

Use references/release-decision.md as the default output structure.

Default Output

Use these sections unless the user asks for a specific format:

1. Inputs And Assumptions
2. Review Question
3. Evidence Or Measurement Plan
4. Risks And Privacy Notes
5. Decision Or Launch QA Checklist
6. Open Questions
7. Handoff To Next Stage

For instrumentation, section 5 should be a QA checklist. For release retros and MVP decisions, section 5 should be the decision, next actions, and checkpoint schedule.

Boundaries

• Do not invent metrics, event logs, user quotes, sample sizes, conversion rates, market facts, or competitor claims.
• Separate facts, assumptions, inferences, recommendations, and open questions.
• If a decision depends on live market data, current pricing, regulation, competitor behavior, or production analytics, verify sources or ask the user to provide exported data.
• Do not include raw PII in analytics event examples. Use redacted, hashed, synthetic, or categorical examples.
• Do not implement tracking code unless the user explicitly asks for code changes.
• Do not over-instrument. Every event should answer a decision-relevant question.

Optional Validation Script

If the user provides an analytics spec as JSON, run:

node scripts/validate-analytics-spec.js path/to/spec.json

The script checks basic structure, duplicate event names, snake_case event names, missing triggers, property fields, and PII handling notes. Treat script output as a checklist, not as proof that the analytics strategy is correct.

Quality Checklist

Before finalizing, verify:

• The review is tied to a concrete feature, MVP, release, experiment, or product behavior.
• Analytics questions map to product decisions.
• Event names and triggers are unambiguous.
• Properties have type, required flag, description, and example where useful.
• PII and consent handling are explicit.
• Evidence is balanced, not cherry-picked.
• Decision options are concrete and comparable.
• Next checkpoint and success criteria are clear.