A/B testing strategy

The difference between testing projects and testing culture

Testing project

Run a few tests. See what works. Move on. Testing is a tool you use when needed. Then you stop.

Testing culture

Run tests continuously. Test winners inform next test. Learning accumulates. Year after year, testing compounds.

Every change is tested. Every decision is data-driven. Testing is how you make decisions, not a project you occasionally run.

Companies with testing culture beat competitors without it. Not by much per test. But over years, compounds into massive advantage.

Getting leadership buy-in

The problem

Most testing programs fail because leadership does not understand testing or does not commit to it.

What leadership hears

When you propose testing program, leadership hears: this will take time and cost money.

What leadership needs to hear

Show money. Run one test. Prove it works. Calculate revenue impact. This test improved conversion by two percent. This brings fifty thousand dollars additional annual revenue. Testing tool costs twelve thousand. Net benefit thirty-eight thousand.

Now leadership sees testing as investment, not cost.

Building the testing roadmap

Do not run random tests

Plan testing roadmap. Roadmap identifies high-impact areas. Forms. Headlines. Offers. Checkout. Each area gets testing priority.

Sequence by impact

Roadmap sequences tests. Test high-impact items first. Medium impact second. Low impact later.

Team commitment

Roadmap commits teams to testing. Designers know they are testing button designs. Product knows they are testing offer. Everyone knows what is coming.

Create quarterly roadmap. Update monthly based on results. Quarterly planning keeps team focused.

Assigning ownership and accountability

The problem

Testing fails when no one owns it. Marketing says product is responsible. Product says engineering is responsible. Testing never happens.

The solution

Assign testing owner. Could be growth manager. Could be product manager. One person accountable for testing program.

Testing owner sets roadmap. Runs tests. Documents results. Shares learning. Coordinates across teams. Without owner, testing stalls.

Training teams on statistical thinking

The problem

Most people are not trained in statistics. They look at numbers and make intuitive calls.

Treatment is nine percent. Control is eight point eight percent. Looks like treatment won. Non-statistician thinks treatment is better.

Statistician checks confidence level. Eighty-two percent. Below ninety-five percent threshold. Not significant. Difference might be luck.

The solution

Training teams on basic statistics prevents wrong decisions. Training topics: what is statistical significance. Why ninety-five percent matters. How to read confidence intervals. What does sample size mean.

Good testing program educates team on statistics.

Creating shared learning and documentation

Why documentation matters

Every test teaches something. Learning disappears if not documented.

How to document

Create test repository. Every test gets page. Hypothesis. Results. Learning.

After fifty tests, you have fifty pages of learning. New team member reads fifty pages and understands what works for your audience.

Good documentation: hypothesis, results, insight, what to test next.

Bad documentation: test one won, test two lost. No insight.

Making testing part of process

Optional testing fails

If testing is optional, testing stops when busy. Teams deprioritize it for urgent projects.

Mandatory testing sustains

Make testing mandatory. Every change goes through testing process. Change without test is not approved.

This requires process change. But it ensures testing happens consistently.

Example process

One: Propose change with hypothesis. Two: Get approval to test. Three: Run test for two weeks. Four: Results approved by testing owner. Five: If significant, implement. Six: Document learning. Seven: Design next test.

Celebrating and communicating wins

The problem

Testing program dies if wins are silent.

The solution

Celebrate wins. Share results. Show impact. Monthly email: "Our testing program improved conversion by seven percent this quarter. Here are five tests that moved the needle. Thank you to teams that executed."

Celebrating creates momentum. Creates culture. Creates belief that testing works.

Handling the politics of testing

The conflict

Someone proposes change. Test shows change is not good idea. Person proposing change is frustrated. Testing creates conflict when results disagree with assumptions.

The solution

Frame testing as learning tool. Not as way to prove people wrong. Frame as "let us test and learn together."

When test shows person was wrong, frame as "we learned something." Frame as win not loss. People get defensive if testing is seen as threatening. People support testing if it is seen as learning.

Managing test velocity

Aggressive approach

Run ten tests per month. Finish every test in one week. Fast learning. Higher chance of false positives. Higher error rate.

Conservative approach

Run three tests per month. Finish every test in two to three weeks. Slower learning. Lower error rate. Safer.

Balanced approach

Most companies should be balanced. Five to six tests per month. Two-week duration. Reasonable error rate. Reasonable learning speed. Do not sacrifice quality for speed. One high-quality test beats ten low-quality tests.

Understanding diminishing returns

The pattern

First twenty tests move the needle. Each test improves something. Roadmap is full of high-impact opportunities.

Tests twenty through forty move the needle less. Still learning but improvements are smaller. Fewer obvious opportunities.

Tests forty and beyond: opportunities are small. Improvements are tiny. This is normal.

The solution

Do not interpret diminishing returns as testing failure. Interpret as maturity. At diminishing returns phase, shift focus. Instead of broad testing, run tests in new areas. New products. New segments. New markets.

Long-term testing program sustainability

The risk

Testing program runs strong for six months. Then slows down. People get busy. Testing is deprioritized. Program fades.

How to sustain

Sustainable program requires continuous commitment. Requires resources. Requires ownership. Budget for testing tools. Budget for testing person. Build testing into annual goals.

If testing is annual priority, testing happens. If testing is nice-to-have, testing stops.

Frequently asked questions

How do I convince skeptical team members that testing works?

If we are busy with projects, should we postpone testing?

How often should we revisit old test results?

Should we test for our average visitor or for a specific segment?

How do we maintain momentum if tests keep losing?

If testing shows our whole approach is wrong, what do we do?