Install any skill in seconds. Free to start, no credit card required.
Get Started Free →refoundai/product-experiments
Help users design, execute, and analyze product experiments to validate hypotheses and measure true incremental impact while avoiding common statistical pitfalls.
Passed 20 of 22 test cases with the skill, and 15 of 22 without it.
and 5 more in the full report
6 fixed14 passed either way1 still failing1 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 6 test cases the skill fixed. Same model, same prompt, with and without the skill.
Our growth PM is disheartened because 80% of our experiments on our mature core product fail or yield neutral results. Management believes this signals poor team performance. How should executive leadership calibrate baseline experiment failure rates for highly optimized products?
| Checked | Without skill | With skill |
|---|---|---|
| States that baseline failure rates of 80 percent to 92 percent are standard in optimized domains. | Missed | Passed |
| Recommends evaluating testing volume and learning speed rather than expecting high win rates on mature features. | Passed | Passed |
The instructions your model reads when the skill loads.
Drive measurable growth and mitigate risk through rigorous A/B testing and data-driven learning.
Help the user with product experimentation excellence using insights from 9 guests and posts across Lenny's Podcast and Newsletter.
Archie Abrams: "So we constantly will relook at an experiment a year later, see that the way the GMV curve for the distribution was different than we might've originally thought. And that'll actually change what we do from that previous experiment. And so there's a lot of longterm monitoring of experiments over these very long time horizons to both inform what those input metrics are and more importantly hold ourselves accountable to, did we actually move what we cared about, which is that longterm GMV, in the right way?"
Implement holdout groups for one or more years to distinguish between immediate growth and short-term pull-forward effects. This ensures you are measuring the genuine downstream business impact of changes.
Lauryn Isford: "So, with all that said, generally my advice is to experiment when you need to and to primarily see it as a risk mitigation tactic when you're making dramatic changes and to let the product development process do more work. So, spend more time with customers, be more rigorous in understanding precisely what problem you're solving, get mocks in front of people and see how they react, and hopefully have more conviction than you otherwise would when you ship something that it's okay if every customer sees it tomorrow and that the experiment doesn't actually matter as much."
Prioritize A/B testing for high-stakes, dramatic product changes rather than using it solely for precise metric attribution. Invest in qualitative research first to build conviction before launching high-risk tests.
Ronny Kohavi: "It's very easy to increase revenue by doing theatrics. Displaying more ads is a trivial way to raise revenue, but it hurts the user experience. And we've done the experiments to show that. In this case, this was just a home run that improved revenue, didn't significantly hurt the guardrail metrics."
Develop a robust Overall Evaluation Criterion (OEC) that includes guardrail metrics. This prevents short-term wins from inadvertently degrading the long-term user experience or retention.
Ronny Kohavi: "At Bing, which is a much more optimized domain after we've been optimizing it for a while, the failure rate was around 85%. So it's harder to improve something that you've been optimizing for a while. And then at Airbnb, this 92% number is the highest failure rate that I've observed."
Expect that 80 percent to 92 percent of experiments in optimized domains will fail. Calibrating team expectations around these industry standards prevents discouragement and maintains high testing volume.
From "When NOT to run an experiment – Issue 54": "If you can run experiments quickly and easily (e.g. a few hours), this decision is generally easy: run the experiment. If running experiments is a pain in the butt, and the changes are relatively benign, you can probably skip the experiment."
Shipping directly is often superior to experimenting when the time required for statistical significance outweighs the data value. Avoid formal tests for standard industry practices where downside risk is minimal.
test cases passed, vs 15 / 22 without
Published skills whose descriptions closely match this one, with their headline benchmark lift.
More skills from the same source and nearby in the registry, with their headline benchmark lift.