协作头脑风暴
brainstorming
在实现前澄清需求、探索设计选择,并形成清晰的开发方向。
product-experimentation【开发与工程】Run end-to-end product experiments from assumption to decision: translate assumptions into testable hypotheses and experiment briefs, select the right method among qualitative interviews, prototypes, concierge tests, fake doors, feature flags, and A/B tests, and produce readouts that update the roadmap and decision record. Do not use when a qualitati…
独立 GitHub 快照 · 自动分类 · 以原作者文档为准
End-to-end product experimentation: from assumption mapping through method selection, instrumentation, guardrail enforcement, and decision-readout that updates the product roadmap. Owns the complete experiment workflow; routes statistical design and rollout mechanics to specialist skills.
ASSUMPTIONS → [HYPOTHESIS] → [METHOD SELECT] → [INSTRUMENT] → [RUN] → [DECIDE] → [RECORD]
| | | | | |
Experiment Qualitative Tracking Guardrail Decision Readout
brief Prototype plan monitor rules learning
Operational
Quantitative
Load only the reference or template relevant to the task. Do not load every file at once.
| File | Load when |
|---|---|
| references/discovery-brief.md | You need to understand how experimentation concepts map across skills and where this skill's boundaries are |
| references/method-selection.md | Choosing among qualitative, prototype, operational, and quantitative test methods |
| references/guardrails-and-ethics.md | Defining guardrail metrics, ethical boundaries, stopping rules, and decision ownership |
| references/experiment-readout.md | Producing a decision-impact readout that updates the roadmap or decision record |
| templates/experiment-brief.md | Filling out a structured experiment brief from an assumption |
| templates/assumption-map.md | Mapping assumptions to risk, evidence, and testability before designing experiments |
| templates/guardrail-and-decision-rule.md | Recording guardrails, stopping rules, and decision criteria for an experiment |
| templates/readout-learning-entry.md | Documenting experiment outcome and updating the roadmap, decision log, or lifecycle evidence |
Surface the assumptions driving the proposed change. Classify each by risk (what breaks if it is wrong), evidence strength (what evidence already exists), and testability (can it be tested, and how cheaply). Use templates/assumption-map.md.
Convert the riskiest, least-evidenced assumptions into falsifiable hypotheses. Each hypothesis names the independent variable (what changes), the dependent variable (what outcome is measured), the predicted direction, and the smallest effect that matters. Use templates/experiment-brief.md.
Choose the lightest-weight method that can falsify the hypothesis with sufficient confidence. The method ladder, from lightest to heaviest:
| Method | Best for | Cost | Statistical rigor |
|---|---|---|---|
| Qualitative interviews | Uncovering unknown unknowns, mental models, problem validation | Lowest | None (descriptive) |
| Prototype tests | Interaction flow, usability, concept validation | Low | None (observational) |
| Concierge tests | Value delivery, willingness to pay, operational feasibility | Low-Medium | None (manual) |
| Fake doors | Demand signals, willingness to click/commit | Medium | Low (conversion rate only) |
| Feature flags | Operational safety, incremental rollout, kill-switch | Medium | Medium (controlled rollout) |
| A/B tests | Causal attribution of a specific change to a metric | High | High (randomized controlled) |
Do not default to A/B testing. Start at the top of the ladder and only move down when the question cannot be answered at the current level. A qualitative interview or prototype test is often the right answer. Full method selection guidance is in references/method-selection.md.
Before running the experiment, define:
Use templates/guardrail-and-decision-rule.md to record these.
Define the target population, allocation, and minimum detectable effect. Route statistical design (power analysis, sample-size calculation, estimator selection) to ../data-scientist/SKILL.md. An underpowered experiment — one that cannot detect the smallest effect that matters — is a validity failure; do not ship based on a null result from an underpowered test.
Execute the experiment. Monitor guardrails continuously. Route production rollout mechanics (feature flags, canary stages, progressive delivery) to ../release-engineering/SKILL.md.
Make the ship/no-ship decision using multiple criteria, never statistical significance alone:
| Criterion | Weight | Source |
|---|---|---|
| Statistical evidence | Required | data-scientist |
| Practical significance | Required | Is the effect large enough to matter? |
| Guardrail evidence | Blocking | All guardrails must pass |
| Qualitative evidence | Informative | User feedback, support tickets |
| Reversibility | Informative | Can we undo this if wrong? |
| Opportunity cost | Informative | What else could we build instead? |
A statistically significant result with a failing guardrail is a no-ship. A statistically significant result that exceeds authority boundaries (e.g., safety, compliance, ethics) is a no-ship. Record the decision and its rationale.
Document what was learned and what changed as a result. The readout updates the product roadmap, backlog, decision log, or lifecycle evidence. Routing: feeds product-roadmapping-and-portfolio (roadmap updates), product-adoption (adoption evidence), and product-lifecycle-learning (retained learning). Use templates/readout-learning-entry.md and references/experiment-readout.md.
Load this skill when:
This skill is intentionally host-neutral. It requires no profile system, output format, scripts, or external services. Load references and templates directly by path using the host agent's normal file-loading mechanism.