Define the outcome
Choose a specific progression, such as eligible visitors completing a valid consultation request. Specify the population, counting rule, and observation window. Keep quality and experience guardrails beside the primary rate.Run an interpretable improvement
- Diagnose the friction. Combine analytics with recordings or interviews collected under appropriate rules, support questions, and form-error data. A drop-off identifies where to investigate, not automatically why it happened.
- Explain why the change might help. State the obstacle, proposed change, and expected behavior. For example: explaining response time may reduce uncertainty before submission.
- Choose the evaluation method. Use a randomized experiment when traffic, tooling, and timing support it. With low volume, usability testing and staged observation can guide a change, but do not establish the same causal certainty.
- Agree how you will read the result before testing. Set the randomization unit, primary metric, minimum effect worth detecting, sample/duration plan, and stopping rule with suitable statistical support. Account for multiple comparisons and delayed quality outcomes.
- Check implementation and data quality. Test variants, event deduplication, exposure logging, and allocation. Investigate sample ratio mismatch before interpreting effects; it can indicate an invalid experiment.
- Make a bounded decision. Review uncertainty and guardrails, not only the direction of the headline number. Record whether to ship, revert, investigate, or run a better-designed test.
Worked example
A hypothetical demo form removes a required phone field. Submissions increase from 40 to 50 in two observed periods, but traffic composition also changes. The team cannot attribute the increase to the field change from this comparison alone. It checks usability and downstream contactability, then designs a randomized test if volume permits. The primary outcome is a valid request per eligible visitor; accepted meetings and complaints are guardrails. This prevents a superficial conversion improvement from hiding a worse buying experience.Experiment brief
Keep the learning
Archive the implemented version, analysis, and limitations. A result from one audience and period may not generalize to another. Re-test when the underlying experience changes materially, rather than treating a winning button or layout as permanent law.Try it with your own work
Choose one point where readers struggle. Gather an example of the problem, write a possible explanation, and propose one change. Decide how you will check both completion and the quality of the result.Sources and scope
- Microsoft Research: diagnosing sample ratio mismatch supports the experiment-integrity check; this workflow and example are original.
What to read next
Experimentation · Demo request · Dashboards Chapter guide · All playbooksCopyright © 2026 Ivan Xu. All rights reserved. See the copyright and reuse terms. Canonical source: github.com/weilun88313/B2B-Playbook