Blog
Runtime Configuration

A/B Testing Tools: The CTO's Guide to Safe and Measurable Change | Harness Blog

Discover top A/B testing tools for CTOs. Unify feature management and experimentation for safe, measurable innovation. Try Harness for better releases.

  • Unified experimentation platforms that combine feature flags, progressive delivery, and real-time analytics make it safer, faster, and easier for CTOs to measure innovation.
  • AI-powered guardrails and automated issue detection lower operational risk.Teams find and fix problems early, while still maintaining enterprise-level governance.
  • Deep integration with CI/CD pipelines and observability tools means developers experiment every day — and every release is tied to data and real business outcomes.

Picture this: It's 2 a.m. Your phone is buzzing. A new feature just went out to your entire user base, and conversion rates are tanking. Your on-call engineer is digging through logs, your Slack channels are on fire, and you’re left wondering, Why didn't we just test this first?

Every CTO has a version of this story. And most of them have quietly vowed never to repeat it.

Harvard Business School studied 35,000 startups and found that companies using A/B testing had 10% more page views and were 5% more likely to raise VC funding. That's the difference between a product that proves itself and one that guesses its way forward. But here's the problem: too many engineering teams are still stitching together fragmented tools that create operational risk instead of reducing it.

The right experimentation platform changes that. It combines feature flags, progressive delivery, and real-time analytics in a single developer-first system. This gives your team governance, guardrails, and measurable ROI to ship with confidence. That's exactly what modern platforms like Harness Feature Management & Experimentation (FME) accomplish.

What CTOs Actually Need From A/B Testing Tools

Here's something that doesn't get said enough: the best A/B testing tools aren't separate systems — they're extensions of the development workflow your team already uses.

Think about what happens when you bolt on a standalone experimentation tool. This tasks the team with an extra dashboard to check or additional data source to reconcile, that doesn't quite sync with your monitoring stack. Friction ensues, and friction kills adoption.

What you actually need is a platform with:

  • GitOps-compatible flag management so experimental changes move through the same review and audit flow as code
  • Observability integrations that correlate exposure data with your monitoring stack — no manual cross-referencing required
  • Code review processes that stay intact when an experiment goes live, rather than get bypassed
  • Role-based access controls, approval workflows, and immutable audit trails for regulated industries like fintech, healthcare, or anything that touches PII — table stakes, not nice-to-haves

The bottom line: CTOs need platforms that prove their value through measurable outcomes, reduced deployment failures, faster release cycles, and clear KPI improvements tied to specific experiments. That's the metrics-driven visibility that technology investments expect.

  1. Progressive Delivery: Stop Shipping to Everyone at Once

Imagine rolling out a new checkout flow to your entire user base on a Tuesday afternoon, only to realize three hours later that it breaks on Safari. That's a Tuesday you don't want to have.

Progressive delivery is how you avoid it. The idea is simple: start small, watch closely, and scale strategically. You begin with a canary release and ramp gradually as performance metrics confirm everything is working. Research backs this up: canaries surface faults at just 5% exposure, which drops change failure rates from 14.7% to 6.2%. That's not just a marginal gain. It’s a strong boost to your reputation that positions you over and above the competition.

The real unlock is automated guardrails. Instead of relying on an engineer to catch a latency spike at midnight, you configure release monitoring to halt or roll back deployments automatically when thresholds are breached.

  1. Feature Flag Management: Ship the Code, Control the Experience

One of the most powerful mindset shifts in modern software delivery is this: deploying code and releasing features are two completely different things. Feature flags are what make that separation real.

When you ship features off by default, you eliminate the risk of unproven code reaching users before it's ready. You can push continuously while controlling exactly what each user sees, in real time, without a new deployment. For CTOs managing large engineering orgs, that's a significant operational win. Teams ship faster and experience 45% fewer deployment-related incidents when flag lifecycles are properly managed.

Harness Feature Management gives enterprise teams the foundation to make this work at scale. A few practices that separate mature feature flag management from the cobbled-together kind:

  • Ship features off by default: Deploy new functionality behind flags set to "off" and activate when ready. Then release progressively while maintaining careful control of blast radius and a close watch on guardrails.
  • Maximize the benefits of trunk-based development: Feature flags dovetail perfectly with all the benefits of trunk-based development, where teams incrementally commit new features within inactive paths gated by feature flags. These incremental commits save your developers from the “merge hell” of guessing their way through manual conflict resolution shortly before each release.
  • Set flag ownership and expiration dates: Assign each flag to a specific owner and establish automatic sunset policies to keep your codebase clean. Amazon mandates flag removal tasks at creation time — it's a practice worth borrowing.
  • Target specific environments and user segments: Test safely with internal teams, beta users, or specific geographies before a broader rollout.
  • Monitor flag hygiene with dashboards: Track flag age, usage patterns, and removal rates to prevent technical debt from building up across your engineering org.
  • Treat flag changes like code changes: Route configuration updates through version control, approval processes, and audit logs.
  • Cache flags locally for business continuity: Ensure features stay available, even if the flag management service goes down.
  1. Real-Time Impact Analysis: Know in Minutes, Not Days

Old-school A/B testing had a cadence to it. You'd launch a test, wait a week for statistical significance, pull a report, schedule a readout, and take 2 weeks to make a decision that should have been obvious in 48 hours.

Real-time impact analysis changes that rhythm entirely. When a gradual release starts, modern platforms like Harness FME auto-capture performance and error metrics, letting teams validate impact within minutes instead of days. That kind of speed fundamentally changes how your team operates — you're iterating faster because you're learning faster.

But speed without accuracy is its own problem. There's nothing more frustrating than pausing a successful experiment because a guardrail fired on noisy data. Set your decision thresholds upfront — for example, pause if conversion delta drops below 0.5% with a p-value above 0.1 — and lean on automated guardrails to protect against false positives that kill valuable experiments before they can prove themselves.

  1. AI-Driven Experimentation: Less Setup, Smarter Guardrails

Setting up a well-designed experiment used to take days. Someone had to manually configure segments, calculate sample sizes, check for bias, estimate time-to-significance, and then monitor the whole thing while also doing their actual job. It's no wonder teams cut corners.

AI takes care of the tedious, error-prone manual work in minutes, and empowers your engineers to engage their creativity, anticipate learning, and reap the rewards.

Some of the benefits of AI-driven experimentation:

  • Intelligent test setup and targeting. AI analyzes historical data to suggest high-value segments, anticipate seasonality patterns in flag traffic and experiments,  and alert you to biased tests before launch — so you're not three weeks in before realizing your sample size was never going to get you to significance.
  • Real-time anomaly detection. Research shows that ML-based systems achieve both increased speed and superior accuracy in real-time anomaly detection. Detection speed is boosted by 35% while accuracy improves by 40% — a clear win-win.
  • AI-powered decision recommendations. Platforms like Harness Release Agent analyze results in real time and give clear guidance — roll out, roll back, or refine — speeding up iteration cycles by 3x.
  • Predictive impact forecasting. AI estimates long-term effects using patterns from similar past experiments, which is especially valuable for metrics like customer lifetime value that take months to materialize on their own.
  1. Developer Workflow Integration: Experiments Belong in the Pipeline

Here's a question worth asking honestly: if running an experiment requires a developer to step outside their normal workflow, how often do you think they're actually going to do it?

The answer, in most orgs, is "not as often as they should." And that's not a people problem — it's a tooling problem.

Successful experimentation means embedding tests within your existing development processes, not running them alongside them. Modern platforms trigger flag changes through GitOps workflows, CLI commands, or pipeline steps, keeping experimental changes in the same review and audit flow as code deployments. When something goes sideways during an incident, your on-call engineer shouldn't have to cross-reference three different dashboards to figure out which feature caused the spike.

The best platforms sync exposure data directly with your observability stack so feature context surfaces right where the team is already looking. Harness integrates with Datadog, New Relic, and Sentry to correlate feature exposure with performance metrics — and SDKs handle low-latency evaluation and graceful degradation so experiments don't become a reliability liability.

  1. Automated Issue Detection: Stop a Bad Rollout Before It Costs You

Ask any CTO who's lived through a bad deploy how much a few minutes of slow detection costs. The answer usually involves a very uncomfortable number and a very uncomfortable conversation with the CEO. Bad rollouts cost thousands in revenue per minute and damage customer trust in ways that are genuinely hard to recover from.

Automated issue detection is your safety net. Modern platforms correlate performance degradation directly with specific feature toggles, which means you know which feature caused the problem — not just that something is wrong. A few capabilities that matter here:

  • Auto-correlate metrics with feature exposure. Track real-time error rates, latency percentiles, and conversion metrics to pinpoint which flag caused a regression, even when multiple features rolled out at the same time.
  • Define SLO-based rollback policies. Set automated triggers like "revert if p95 latency increases more than 10% for 84 seconds" — no guesswork, no late-night judgment calls.
  • Surface exact feature and cohort context. Give on-call engineers the problematic flag, affected user segment, and rollout percentage up front. No debugging across multiple systems required.
  • Trigger instant flag deactivation. Kill a problematic feature in under 5 seconds — dramatically faster than any hotfix deployment.
  • Minimize false positive alerts. Use workload-aware baseline modeling and fixed horizon testing to distinguish genuine regressions from normal traffic variation. Your engineers don't need more alert fatigue.
  1. Enterprise-Grade Security: Governance That Doesn't Slow You Down

There's a version of governance that genuinely protects your organization. And then there's the kind that just adds friction until engineers find workarounds. The goal is the first kind.

Regulated teams need RBAC and SAML federation to centralize identity management, and Policy as Code enforcement through tools like Open Policy Agent — defining exactly who can create experiments, which environments require approvals, and what configurations trigger automatic reviews.

Beyond access controls, compliance requires immutable audit logs that capture every exposure decision, configuration change, and rollback across environments. Data encryption in transit and at rest, along with geography-aware PII controls, are non-negotiable for maintaining full visibility into who changed what, when, and why.

  1. Targeted Rollouts: The Right Users at the Right Time

There's a big difference between rolling a feature out to 10% of users randomly and rolling it out to 10% of your highest-value accounts. One gives you a noisy signal. The other gives you feedback that actually helps you make a confident decision.

Targeted rollouts let you validate changes with the right cohorts, directly improving your risk profile and time-to-value.

  • Target high-value segments first. Use account tier, geography, or device type to expose features to priority cohorts who can give you actionable feedback before a broader release.
  • Implement allow/deny lists for predictable exposure. Explicit inclusion and exclusion rules based on user attributes or risk scores keep sensitive cohorts protected from experimental changes.
  • Use percentage rollouts within segments. Start at 1–5% within your target segment and increase gradually based on performance metrics and user feedback.
  • Isolate high-risk changes to internal teams first. Deploy disruptive features to internal users or beta customers before your broader base. Catch issues when the blast radius is small.
  • Leverage entitlement-based targeting. Route features based on subscription tiers or account permissions so premium features reach paying customers first.
  • Monitor segment-level performance in real time. Track conversion rates and technical performance per segment to make data-driven decisions about expanding or rolling back exposure.
  1. Psychological Safety: Making It Safe to Ship

This one doesn't show up in enough engineering conversations, but it should. The fear of shipping is real — and it's one of the most underrated blockers to innovation in engineering orgs.

When your team knows that a bad deployment means an after-hours all-hands incident and two days of rollback work, they slow down. They second-guess. They push for longer QA cycles and bigger batch releases, which ironically makes each release riskier, not safer.

Feature flags break that cycle. When you can deploy small changes behind flags and roll back instantly — in seconds, not hours — the stakes drop dramatically. Research shows that psychological safety increases learning behaviors by 62%. That's your team trying things, learning faster, and compounding their improvements over time instead of shipping in fear.

One Speedway Motors director put it plainly: the psychological safety their experimentation platform provides gets mentioned in annual performance reviews. That's not a technical win — it's a cultural one. Harness FME enables exactly this by decoupling deploy from release, codifying rollback plans, and setting pre-commit metrics that remove the ambiguity that kills confidence during incidents.

  1. Data-Driven Releases: Connecting Tests to What the Board Cares About

"Our test showed a lift in engagement" is not a sentence that moves a board meeting. "This experiment drove a 3.2% improvement in 90-day retention, which maps to $X in annual recurring revenue" — that one gets attention.

Effective data-driven release strategy means connecting every experiment to metrics that actually matter at the executive level.

  • Connect experiments to revenue metrics. Focus on retention, cost-to-serve, and other KPIs that directly impact valuation and stakeholder value. Vanity metrics don't close funding rounds.
  • Define decision rules before testing begins. Set significance level, statistical power (typically 80%), and minimum detectable effect upfront. Without this, you're p-hacking, whether you mean to or not.
  • Build executive dashboards. Surface cycle time, failure rates, and KPI lift per experiment, so leadership has real-time visibility into both experiment performance and business outcomes.
  • Implement sequential testing for faster decisions. Use statistical approaches that enable valid interim analysis, so you can act on clear signals without waiting for predetermined sample sizes.
  • Establish metric ownership across teams. Assign clear definitions, update frequencies, and accountability for each KPI to prevent measurement drift and maintain compliance alignment.
  • Automate feature-to-KPI attribution. Connect feature flags directly to analytics platforms to capture performance data automatically and eliminate manual reporting delays.

Ship Confidently. Measure Everything. Repeat.

The 2 a.m. phone call doesn't have to be part of your story. With the right experimentation platform — one that combines controlled rollouts, real-time impact detection, and instant rollback — your team ships faster and your leadership sleeps better.

Research shows 82% of successful feature management teams monitor at the feature level, making every release measurable and data-driven. Progressive delivery with AI-driven guardrails doesn't just reduce technical risk. It reduces the hesitation around shipping that limits innovation in the first place.

See how Harness combines feature flags, experimentation, and release monitoring to accelerate your delivery pipeline while reducing risk.

← Previous:
Next: →

FAQs

Related Resources

Split’s Simple How-To Guide for A/B Testing

Runtime Configuration

Split’s Simple How-To Guide for A/B Testing

September 23, 2020

Harness Team

+ more
Time to Read

Product experimentation is the most effective way to determine what works best for end-users. You can measure engagement with a feature and hypothesize ways to improve that engagement, which will ultimately impact one or more critical business metrics. If you’re setting up an experiment, it’s mission-critical to implement A/B testing correctly to ensure your results are accurate. We know that experimentation powers innovation and can drive profound business impact. So, are you A/B testing correctly?

What is A/B Testing?

A/B testing, otherwise known as split testing, is the process of testing two different versions of a web page or product feature against the original, existing version. As products evolve, new improvements and new features are needed to keep up with growing user demands. A/B tests allow companies and product teams to figure out precisely what will drive up their metrics, and ultimately their success.

How do you implement A/B testing?

The first thing you need to do when starting an A/B test is to gather relevant data on your current features. What do you already know about their influence on your key business metrics? For example, you may have observed that users who share a report with other users are twice as likely to upgrade their plan over the next 90 days. You might also know that fewer than 20% of your users run a report in the first month of usage. Once you have this baseline data, you should be able to create a hypothesis about how you could improve outcomes by changing how customers interact with one of those features. For example, is there some way you can lead more users to run reports?

The existing functionality of your feature is called your control. The change you believe will improve user experience is called your treatment.

It’s essential to establish your baseline before you start your experiment because you need to know what to measure and to confirm your ability to measure it during your experiment. You also need to make sure that the two variants (the control and treatment) run simultaneously and are randomly distributed across your targeted population, to cancel out external influences on the outcome.

A/B Testing with Feature Flags

Now the question is — how do you segment your user base into two parts and release the feature (the experiment) to only a subset of those users? The answer — feature flags. Feature flags allow you to control how your users interact with your product. With Split, you can segment your users in the UI, and then choose the experience they get in the front end. The developers will then link that feature flag to their code. Once the feature is on for the specified population, you will see data coming into your metrics dashboard. Here, you will be able to measure the impact of your changes. The more traffic you have, the quickly you will start to see statistically significant results. After you have your results, you can implement the new version for all users if there’s a significant positive change.

It’s important to integrate the team’s analytics platform with the feature flag management system to correlate the users’ behavior with which version of the feature they used as described above. Once the test has been completed, you can go into the metrics dashboard and look at the difference in metrics between your control and treatment and decide if the treatment performs better or worse than the control. If it is performing better, then you can confidently roll out the feature to the rest of your features, knowing that it is improving your metrics. However, if the treatment is not performing better than the control, then you can confidently return the control to the rest of your userbase.

Can Your Test More Than One Thing at a Time with A/B Testing?

Let’s say, for example, that you hoping to improve the conversion rate on your website and want to test how a CTA change will impact that rate. You have three variables you want to test, the current CTA, and two new options. instead of two. This is called an A/B/n test. An A/B/n test allows more than one variant for an experiment. In this case, you would have one control, the existing CTA, and two treatments, the two alternates you are testing. Nothing different needs to be done for the experiment setup, but keep in mind that the more variants you have, the longer you might have to run an experiment to get a sufficient amount of traffic to each variant for statistically significant results.

There is also the option of testing different variants together. This is called multivariate testing. Let’s say that in addition to the CTA, you also wanted to test how the headline of the homepage impacts your conversion rate. You would have your different variants: control CTA + control headline, control CTA + experimental headline, experimental CTA + control headline, experimental CTA + experimental headline. When you are not under a time constraint and you want to test different combinations of things, you can run a multivariate test. If, however, you do not have enough time to bring in enough amount of traffic to each variate for statistical significance, stick with A/B testing.

Run A/B Tests to Drive Business Impact

Running a successful A/B test can not only give your users the best experience, but it can also increase your revenue. When you import your company’s KPIs to your feature flag management system, you can easily correlate the data coming in from your experiments to the different KPIs and make business decisions that will better your company and increase your revenue. Feature flags make the process of A/B testing easier by giving you an intuitive UI to segment your user base and monitor the progress of the experiment as time goes on.

Learn More About A/B Testing and Feature Flags

When done correctly, A/B tests can greatly impact your business, increase your revenue, and provide a better user experience. To find out more about A/B testing and feature flags, check out the following posts.

As always, if you’re looking for more great content like this, we’d love to have you follow us on Twitter @splitsoftware, and subscribe to our YouTube channel.

Get Split Certified

Split Arcade includes product explainer videos, clickable product tutorials, manipulatable code examples, and interactive challenges.

Switch It On With Split

The Split Feature Data Platform™ gives you the confidence to move fast without breaking things. Set up feature flags and safely deploy to production, controlling who sees which features and when. Connect every flag to contextual data, so you can know if your features are making things better or worse and act without hesitation. Effortlessly conduct feature experiments like A/B tests without slowing down. Whether you’re looking to increase your releases, to decrease your MTTR, or to ignite your dev team without burning them out–Split is both a feature management platform and partnership to revolutionize the way the work gets done. Switch on a free account today, schedule a demo, or contact us for further questions.

Read more: A/B Testing For Feature Flags, What It Is And What It Shouldn’t Be

Understanding A/B testing versus multivariate testing

Runtime Configuration

Understanding A/B testing versus multivariate testing

June 2, 2020

Harness Team

+ more
Time to Read

A/B testing, otherwise known as split testing, is the process of testing two different versions of a web page, feature, user flow, or other resource in order to optimize for a metric or set of metrics (often conversion rate). Multivariate tests or MVT test, are run with a higher number of variables and generally provide deeper insight on how to optimize your page. In multivariate testing, your feature implementation becomes a combination of elements or customer experiences which can be decomposed and tested simultaneously.

Advantages of A/B Testing

Most examples of A/B testing involve the front end — testing different landing pages for purposes of conversion rate optimization — but all that’s really required for A/B testing is testing different ideas for a feature. It can just as easily be testing different features in software or mobile applications as testing different variables, including different headlines, different page elements, different versions of the page, design elements or redesigns, for user experience optimization.

Because there are only two versions of your software when conducting an A/B test, your tests will deliver dependable data quickly. The more variations you have, the longer it will take to gather significant data — the traffic required for A/B testing is much less than the traffic required for multivariate testing.

The first thing that needs to happen when you run an A/B test is to gather data on your current resources (homepage, feature, user flow, etc.) and figure out which ones aren’t performing as well as they should. This should be a list of the features that you would like to optimize.Once you have this list, you can prioritize them in order of the potential value that they could bring. You should work with both your data analyst and product person to gather this information.

Hypothesize different possible combinations of changes that will fix the problem. This is usually done by the product person. Segment your user base into two parts, showing the original page or feature to one part and the new version to the other. How quickly you get significant results depends on the amount of traffic you have, since for the test results to have statistical significance, they must come from a large population. After you have your results, if there’s a significant positive change, you can implement the new version for all users.

Testing Multiple Features

A/B testing can occur on more than two different variations (this is called A/B/n testing), but not much more than two. The mechanic of A/B testing doesn’t lend itself well to testing more than around four variations at once: testing a higher number of variations is slow, and even A/B/n tests won’t give you a granular view of which subtle changes actually produced the results.

What is Multivariate Testing?

Multivariate testing is a testing method using a statistical methodology using multiple variants that is similar to A/B testing in roughly the same way as a cube is similar to a square: same shape, higher dimensions. You can think of a multivariate test as multiple nested A/B tests. Industries such as ecommerce use multivariate testing extensively to test different elements of their website such as page designs, or different strategies for marketing campaigns for example.

Say you have two features that you’d like to test variations on instead of just one. If Feature A has two possible states (on and off) and Feature B also has two possible states, in a full factorial scheme, you end up with 4 different combinations: (A on, B off), (A off, B on), (A on, B on), and (A off, B off). Segmenting your user base into four parts this way will let you know which individual elements produced the change, and further, how much each one contributed.

How Do You Know Which Type of Test to Run?

The biggest problem with multivariate testing is that you need a high website traffic platform to have enough users coming through each group to achieve enough sample size and get significant results in a reasonable amount of time. Because the number of groups grows exponentially with the number of tested variations, you should be careful to make sure you have enough traffic to make a multivariate test worthwhile. So for a lower-traffic platform, it’s best to run an A/B test.

Learn More About A/B Testing

Interested in digging deeper on A/B Testing and Experimentation? We’ve got you covered:

As always, if you’re looking for more great content like this, we’d love to have you follow us on Twitter @splitsoftware, and subscribe to our YouTube channel.

Switch It On With Split

The Split Feature Data Platform™ gives you the confidence to move fast without breaking things. Set up feature flags and safely deploy to production, controlling who sees which features and when. Connect every flag to contextual data, so you can know if your features are making things better or worse and act without hesitation. Effortlessly conduct feature experiments like A/B tests without slowing down. Whether you’re looking to increase your releases, to decrease your MTTR, or to ignite your dev team without burning them out–Split is both a feature management platform and partnership to revolutionize the way the work gets done. Schedule a demo to learn more.

Get Split Certified

Split Arcade includes product explainer videos, clickable product tutorials, manipulatable code examples, and interactive challenges.

Read more: A/B Testing For Feature Flags, What It Is And What It Shouldn’t Be

Simultaneous Experimentation: Run Multiple A/B Tests Concurrently

Runtime Configuration

Simultaneous Experimentation: Run Multiple A/B Tests Concurrently

April 6, 2021

Harness

+ more
Time to Read

The ability to run multiple experiments simultaneously is one of the most significant force multipliers for development teams. Running multiple experiments simultaneously can maximize a company's velocity, flexibility, and revenue. For this process to be as impactful as possible, here are some best practices.

Use Randomization to Empower Simultaneous Experimentation

Eight user avatars divided into two groups of four, representing control and treatment segments for A/B testing

When you run a simple A/B test, you divide your users into two groups: the control, which receives the existing baseline functionality, and the treatment, which receives the new proposed change.

Imagine you were to divide your users the same way for each experiment. In that case, you would have only two groups — one which gets the baseline experience and one which receives each of the changes for every experiment you are running. As a result, when analyzing the data, you would see the combined effects of all changes in the results and could not parse out the source of the impact. They may both be improving equally, they might be doing so unequally, or one might even have a negative effect that is being overwhelmed by the other. Identical assignment confuses results, making it impossible to know which change is causing the effect.

Two rows of user avatars illustrating independent, randomized group assignments across two concurrent experiments

Fortunately, this isn't how an experiment is run. Users are sorted between the baseline and treatment experiences at random for each separate rollout plan, so each experiment's impact is distributed independently.

Four user groups representing combinations of baseline and treatment experiences across two concurrent experiments

This creates four groups: one group that has the standard experience, two groups that each receive one change alone, and a group that gets both changes.

When just focusing on one experiment, the impact of the other experiment does exist — however it is distributed between the baseline (control) and the treatment (variant). So while each group has a different absolute effect than the vanilla experience with your product, the relative difference between the treatment and baseline remains constant, and the experiment results remain accurate.

The Effect on Overall Velocity

Given that randomization allows you to isolate the impact of an experiment run in parallel, it's valuable to highlight how that process can significantly improve your experimentation and development velocity. If you choose to run the tests sequentially, the time to reach a final decision will be dependent on the combined length of all experiments. This runs the risk of engineers and other resources moving on to other projects once they finish the code for a feature and not being available to support its later release or wait until one experiment ends before they can start working on the next one.

Having seen how these experiments can be safely run in parallel, you can now reap the benefits of starting or completing experiments on a schedule that suits that particular test and team. The total time to complete the concurrent experiments will be capped at the longest experiment running. Any other experiments can be started or concluded during that run time without fear of interfering with overall results and decisions.

This distribution of impact holds even when the rollout is targeted to a fraction of the overall distribution vs. just a 50/50 rollout. Let's say you choose to test a new feature on only one-quarter of the population.

Eight user avatars split vertically with different colors to show overlapping user segments in concurrent A/B tests

The populations are seeing the same absolute impact as before. The only difference is that the treatment group is smaller.

Be on the Lookout for Interaction Effects

There is one area to keep in mind when running parallel experiments. That is the case where two changes directly interfere with one another, creating a different impact on behavior when combined than when in isolation. This happens when experiments are being run on the same page, the same user flow, etc. To avoid interaction effects, review concurrent experiments for interactions: use tags and naming conventions to track changed areas, manually test changes as part of the rollout, and look for other feature flags in nearby code. You should also design colliding tests to highlight interactions and compare each variant's performance against one another. When you receive surprising results from an experiment, be sure to examine them qualitatively to help you understand the cause.

Learn More About Experimentation

Experimenting with your business models and user flows can provide you with feedback on what your customers value most in your product. Running simultaneous experiments can give you even more insight into making a better product, increase your revenue, and increase your overall velocity. Be sure to avoid interaction effects by reviewing concurrent experiments and using guardrail metrics that will help you highlight them.

Here at Harness, we know feature flags and experimentation go hand-in-hand! These powerful tools are the future of software development, and our platform empowers organizations to drive clear business impact every day. Ready to learn more? Check out these resources:

Get Certified

Harness Arcade includes product explainer videos, clickable product tutorials, manipulatable code examples, and interactive challenges.

Switch It On With Harness

Harness gives product development teams the confidence to release features that matter faster. It’s the only feature management and experimentation solution that automatically attributes data-driven insight to every feature that’s released—all while enabling astoundingly easy deployment, profound risk reduction, and better visibility across teams. Harness offers more than a platform: It offers partnership. By sticking with customers every step of the way, Harness illuminates the path toward continuous improvement and timely innovation. Switch on a trial account, schedule a demo, or contact us for further questions.

Get Started

Get Started with Harness AI

Try the full platform free. No module restrictions, no credit card.

Aaron Newcomb
Senior Product Marketing Manager
aaron-newcomb
Aaron Newcomb