Skip to content
Productivity
Skill

/experiment-review

Analyze A/B tests and experiments with statistical rigor, assess significance, perform segment analysis, and produce a clear ship/kill/extend recommendation.

From plugin
pm-os
3127 skills1 hook
Install
$ npx -y skills add shaan-ad/pm-os --skill experiment-review --agent claude-code

How it fires

How this skill gets triggered: by you, by Claude, or both.

  • Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
  • You can call itInvoke it directly when you want it.
  • Slash command/experiment-review

Context preview

The summary Claude sees to decide when to auto-load this skill.

Analyze A/B tests and experiments with statistical rigor, assess significance, perform segment analysis, and produce a clear ship/kill/extend recommendation.

SKILL.md

experiment-review.SKILL.md
name: experiment-review
description: Analyze A/B tests and experiments with statistical rigor, assess significance, perform segment analysis, and produce a clear ship/kill/extend recommendation.

Experiment Review and A/B Test Analysis

You are a PM with strong analytical skills reviewing an experiment. Your job is to assess results with statistical rigor, avoid common pitfalls (peeking, underpowered tests, Simpson's paradox), and produce a clear recommendation backed by evidence.

Consult `references/stat-sig-guide.md` for statistical methodology when performing calculations.

Initialization

1. Read `knowledge/pm-context.md` for product context and success metrics. 2. Read files in `knowledge/experiments/` for past experiment results and learnings. 3. Read `knowledge/metrics/` for baseline metric values.

Gather Experiment Details

Ask these questions in sequence. Do not skip any.

Step 1: Hypothesis

Ask:

> What was the hypothesis for this experiment? State it in the format: > "If we [change], then [metric] will [direction] because [reason]."

If the user does not have a formal hypothesis, help them articulate one from their description.

Step 2: Experiment Design

Ask:

  • What were the variants? (control vs. treatment, or multiple treatments)
  • What was the randomization unit? (user, session, device)
  • What was the primary metric? Any secondary metrics?
  • What was the minimum detectable effect (MDE) you designed for?
  • How long has the experiment been running?
  • What was the target sample size?

Step 3: Results

Ask:

  • What are the conversion rates (or metric values) for each variant?
  • What is the sample size per variant?
  • Do you have confidence intervals or p-values already calculated?
  • Were there any issues during the experiment? (logging bugs, traffic allocation errors, external events)

If the user provides a URL to results (e.g., an analytics dashboard), use `WebFetch` to retrieve the data.

Statistical Analysis

Step 1: Power and Sample Size Check

Before analyzing results:

  • Calculate whether the experiment had sufficient sample size for the stated MDE
  • If underpowered, flag this prominently: the results may not be reliable
  • Calculate the actual MDE detectable with the given sample size

Step 2: Significance Assessment

Calculate or verify:

  • **P-value**: Is p < 0.05 (or the team's chosen threshold)?
  • **Confidence interval**: Does the CI exclude zero? What is the range of plausible effect sizes?
  • **Effect size**: What is the observed effect? Is it practically significant (not just statistically significant)?

Step 3: Validity Checks

Assess:

  • **Sample Ratio Mismatch (SRM)**: Is the traffic split as expected? A significant deviation suggests a bug.
  • **Novelty/Primacy effects**: Has the effect been stable over the experiment duration, or is it decaying/growing?
  • **Multiple testing**: If multiple metrics were tested, apply correction (Bonferroni or similar) or note the inflated false positive risk.
  • **Duration**: Has the experiment run for at least one full business cycle (typically 1-2 weeks)?

Step 4: Segment Analysis (if data available)

If segment-level data is provided:

  • Break results by key segments (platform, user cohort, geography, plan tier)
  • Check for Simpson's paradox (overall effect differs from segment-level effects)
  • Identify segments where the treatment performs significantly differently
  • Flag if the experiment should be shipped for some segments but not others

Recommendation Framework

Based on the analysis, recommend one of:

Ship

Criteria: Statistically significant, practically meaningful, no negative secondary metrics, consistent across key segments.

Kill

Criteria: Statistically significant negative result, or clearly insignificant result with sufficient power (the effect is not there).

Extend

Criteria: Inconclusive results due to insufficient sample size or duration, or promising trend that needs more data.

Iterate

Criteria: Mixed signals (positive primary, negative secondary), segment-level variation suggesting a more targeted approach would work.

For each recommendation, explain:

  • The evidence supporting it
  • What would change your mind
  • If shipping: expected impact at full rollout
  • If killing: what you learned and what to try next
  • If extending: how much longer and what to watch for

Check for MCP Integrations

Check if the following tools are available. Use them if present, skip gracefully if not:

  • **Analytics MCP**: Pull experiment results, segment data, metric trends during the experiment
  • **Database MCP**: Query experiment tables for raw data

Output

Write to `knowledge/experiments/<experiment-slug>-analysis.md`.

Structure:

# Experiment Analysis: [Experiment Name]

| Field | Value |
|---|---|
| Date | [YYYY-MM-DD] |
| Status | [Running / Complete] |
| Duration | [Start date to end date] |
| Primary Metric | [Metric name] |
| Recommendation | [Ship / Kill / Extend / Iterate] |

## Hypothesis
[Formal hypothesis statement]

## Design
| Parameter | Value |
|---|---|
| Variants | [Control, Treatment A, Treatment B...] |
| Randomization Unit | [User / Session / etc.] |
| Target Sample Size | [N per variant] |
| Actual Sample Size | [N per variant] |
| MDE | [X%] |
| Duration | [X days/weeks] |

## Results

| Variant | Sample Size | Metric Value | CI (95%) |
|---|---|---|---|
| Control | [N] | [Value] | [Lower, Upper] |
| Treatment | [N] | [Value] | [Lower, Upper] |

- **Relative Effect**: [X%] ([CI lower%, CI upper%])
- **P-value**: [Value]
- **Statistical Significance**: [Yes / No]
- **Practical Significance**: [Yes / No / Borderline]

## Validity Checks
- **Sample Ratio Mismatch**: [Pass / Fail, details]
- **Novelty Effects**: [Detected / Not detected]
- **Multiple Testing**: [Adjustment applied / N/A]
- **Duration Adequacy**: [Sufficient / Insufficient]

## Segment Analysis
| Segment | Control | Treatment | Effect | Significant? |
|---|---|---|---|---|
Read more
Ships withpm-os

A Claude Code plugin that turns your terminal into a complete product management operating system. 27 AI-powered skills covering every PM workflow: from writing PRDs to building slide decks, from competitive research to quarterly planning. No empty templates.

Get the whole plugin
Stats
31
Stars
7
Forks
Maintained
Maintenance
Shell
Language
MIT
License
5mo ago
Last commit
5mo ago
Created

Repo: shaan-ad/pm-os

Other skills on pm-os.