Nine Experimentation Best Practices

959
LaunchDarkly
Serving over 200 billion feature flags daily to help software teams build better software, faster. LaunchDarkly helps eliminate risk for developers and operations teams from the software development cycle.

This post is by Dawn Parzych of LaunchDarkly

Running experiments helps you bridge gaps between technical and business teams as you learn about user engagement patterns and application behavior. Experiments can validate that your development teams’ efforts align with your business objectives. You can configure an experiment from any feature flag (front-end, back-end, or operational), but what makes a good experiment?

Experiments use metrics to validate or disprove gut feelings about whether a new feature is meeting customers’ expectations. With an experiment, you can create and test a hypothesis regarding any aspect of your feature development process.

  • Will adding white space to the page result in people spending more time on the site?
  • Do alternate images lead to increased sales?
  • Will adding sorting to the page significantly increase load times?

Experiments provide concrete reporting and measurements to ensure that you are launching the best version of a feature that positively impacts company metrics.

General experimentation best practices

Let’s first talk about best practices around creating an experiment. Even with a solid foundation of feature flagging in your organization, missteps in these areas can yield flawed results. Consider these best practices for experimentation.

1. Create a culture of experimentation

Experiments can help you prove or disprove a hypothesis, but only if you are willing to trust the outcome and not try to game the experiment. Creating a culture of experimentation means:

  • People feel safe asking questions and questioning the answer. Sometimes the results of an experiment may not be what you were expecting. It’s ok to question the results and explore anomalies.
  • Ideas are solicited from all team members—business stakeholders, data analysts, product managers, and developers.
  • A data-driven approach is used to put metrics first, not as something that is only useful in dashboards after a feature ships.

Part of creating a culture of experimentation is providing the tools and training to allow teams to test and validate their features.

Tools needed for experimentation:

  • Tools to help you collect relevant metrics can include monitoring, observability, and business analytics tools.
  • Tools to help you segment users.
  • Tools to clean and analyze the results.

2. Define what success looks like as a team

Experiments help you determine when a feature is good enough to release. How do you define what “good enough” is, and who is involved in creating the definition? Experiments can involve a cross-functional team of people or only a handful, depending on the focus of the experiment. If an experiment is on whether to add a “free trial” button to the home page, you may need to involve people from demand generation, design, and business development.

A good experiment requires well-defined and agreed-upon goals and metrics by all stakeholders. Ask yourself, “What does success look like?” Success means improving a specific metric by a specific amount. “Waiting to see what happens” is not a goal befitting a true experiment. Goals need to be concrete and avoid ambiguous words. Tie goals and metrics to business objectives like increasing revenue, time spent on a page, or growing the subscription base.

Examples of poor goals include vague and ambiguous statements:

  • Users will be happier with the home page.
  • The response time of search results will improve.

Examples of better goals include concrete statistics:

  • Paid conversions from a trial will improve by 7%.
  • The response time of search results will decrease by 450ms.

Looking at a single metric is good; looking at related metrics is even better. Identify complementary metrics and examine how they behave. If you get more new subscribers—that’s great, but you also want to look at the total number of subscribers. Say you get additional subscribers, but it inadvertently causes existing subscribers to cancel. Your total number of subscribers may be down as a result, does that make the experiment a success? I would say no.

3. Statistical significance

The number of samples will depend on your weekly or monthly active users and your application. No matter the size of the samples, it is important to maintain a relatively equal sample size. Significantly more samples in one cohort can skew the results.

Think about how and when users access your application when starting an experiment. If users primarily use your application on the weekends, experiments should include those days. If users visit a site multiple times over the course of a couple of weeks before converting and before the experiment starts, early results may be skewed, showing a positive effect when it was neutral or negative.

4. Proper segmentation

There are two aspects to segmentation. First, how will you segment your users, and second, how will you segment the data? A successful experiment needs two or more cohorts. How you segment your users will vary based on your business and users. Some ways to segment users:

  • Logged in vs. anonymous
  • By company
  • By geography
  • Randomly

However you segment users, make sure the sample sizes are balanced. Having skewed cohorts will result in skewed results.

When analyzing the data after an experiment, you may want to do additional segmentation to see if the results vary based on other parameters.

In AirBnB’s experimentation blog, they described an experiment where they received neutral results when they were expecting to see an uplift. Analyzing the results per browser, they uncovered a bug in IE that skewed the results. When the bug was fixed, they saw the improvement they expected. If there was not a culture of experimentation where it was ok to question the result and look for answers, this feature might not have rolled out.

Caution: don’t go digging to find data to support your hypothesis. The segmentation should be done to understand anomalies better, not make a case to call the experiment a success.

5. Recognize your biases

And this brings us to the subject of biases. Everybody is biased. This isn’t a bad thing; it is a matter of how our brains work. Understanding your biases and the biases of others around you will help when running experiments. Our biases influence how we process information, make decisions, and form judgments.

Some biases that may creep in:

  • Anchoring bias – our tendency to rely on the first piece of information we receive.
  • Confirmation bias – searching for information that confirms our beliefs, preconceptions, or hypotheses.
  • Default effect – the tendency to favor the default option when presented with choices.
  • And my personal favorite, the bias blind spot – our belief that we are less biased than others.

It is common in an experiment to scrub the data to remove outliers. This is acceptable, but make sure you aren’t eliminating outliers due to bias. Don’t invalidate the results of your experiment by removing data points that don’t fit the story.

6. Conduct a retro

Experiments are about learning. So after every experiment, hold a retrospective. Ask:

  • Was the experiment a success? Did we get the results we expected? Why or why not?
  • What questions were raised by the experiment? What questions were answered?
  • What did we learn?

And most importantly, should we launch the feature? You can still decide to launch a feature if the results of an experiment were neutral.

Experimentation feature flags best practices

Now that we’ve covered the basics of experiment best practices, let’s dive into best practices around using feature flags in your experiment. Well done feature flagging is a foundation for a well-run experiment.

If you’ve embraced feature management as part of your teams’ DNA, any group that wants to run an experiment can quickly do so without involving engineering. Follow these best practices to get the most from your existing feature flags.

7. Consider experiments during the planning phase

The decision of whether to wrap a feature in a flag begins during the planning phase. This is also the right time to think about experiments. When creating a feature, evaluate the metrics that will indicate whether the feature is a success—clicks, page load time, registrations, sales, etc.

Talk with the various stakeholders to determine whether an experiment may be necessary and provide them with the essential information on the flag, such as the name of the flag, to configure an experiment.

8. Empower others

When giving others the ability to run experiments, make sure you have the proper controls in place to avoid flags accidentally being changed or deleted. Empower other teams to create targeting rules, define segments, and configure roll-out percentages while preventing them from toggling or deleting flags.

9. Avoid technical debt

Experimentation flags should be short-lived. This means removing a flag after an experiment completes and is either rolled out to 100% of users or not released. Put processes and reminders in place to remove the flag. We highlighted some creative ways to do this in our short-term and permanent best practices blog.

To get started with your own experiments, check out the LaunchDarkly documentation.

Are you looking for other best practices? Check out the other blog posts in the series.

Long-term and short-term flags best practices

Operational flags best practices

Release management flags best practices

LaunchDarkly
Serving over 200 billion feature flags daily to help software teams build better software, faster. LaunchDarkly helps eliminate risk for developers and operations teams from the software development cycle.
Tools mentioned in article
Open jobs at LaunchDarkly
Solutions Engineer
Oakland, CA
As a Solutions Engineer, you will educate and guide prospects on the proper implementation of LaunchDarkly's SaaS product and Private Instances. You are passionate about trends and technologies involved in modern application development. You will be the technical voice during our sale and ensure our customers are comfortable with the way our systems work. You are passionate about the developer tools space and helping development teams eliminate risk and deliver value. LaunchDarkly is a rapidly growing software company with a strong mission and vision carried out by a talented and diverse team of employees. Our goal is to help teams build better software, faster. You'll join a small team from companies like Atlassian, Intercom, and GitHub, and you'll have an immediate impact on our product and customers. Software powers the world and LaunchDarkly empowers all teams to deliver and control their software.
  • Evangelize and advise customers on the importance and different uses of feature flags and how to administer them
  • Create solutions to customer's challenges implementing feature flags across large monolith and microservice applications, large organizations, and different technology stacks
  • Become a domain expert on LaunchDarkly architecture
  • Demo LaunchDarkly product to technical and business audiences
  • Become a subject matter expert on LaunchDarkly and communicate our value and features to potential customers
  • Be the voice of the customer by translating, aggregating, and representing customer feedback to the Product and Engineering teams

  •  4+ years of experience consulting with enterprise customers and large development teams
  • You led successful technical proof of concepts 
  • Proven success in building strong customer relationships
  • Ability to learn and synthesize large amounts of information with little context
  • Effective communicator with the ability to simplify complex technical concepts
  • A self‐starter and problem solver, willing to take on hard problems and work independently when necessary.
  • Experience working with teams that underwent development process transformation
  • Familiarity with at least one of our supported languages: Java, .NET, GO, JS, Python, PHP, Node, Ruby, Rails, iOS, or Android
  • Experience with data persistence technologies like Varnish or Redis
  • Developer Advocate
    This Developer Advocate role blends expertise from engineering, marketing, and product with the mission of developer engagement. This is done by engaging our community of developers and driving excitement around developer-related technologies. This is a great opportunity to help improve awareness and usage of LaunchDarkly’s technologies through both marketing programs and in-depth engagement with our key accounts. LaunchDarkly is a rapidly growing software company with a strong mission and vision carried out by a talented and diverse team of employees. Our goal is to help teams build better software, faster. Software powers the world and LaunchDarkly empowers all teams to deliver and control their software. About You You love solving problems with software and have an enthusiasm for educating and sharing solutions with your community. You have a background in engineering and a passion for the community. You have passion, curiosity, technical depth, and extraordinary written communication skills. You should have the ability to converse with a broad range of programming language communities (Java, .NET, Node.js, Python, Ruby, iOS, Android, etc.), and have a real passion for modern application development trends at the intersection of development and operations. Our Developer Advocates can be responsible for anything from organizing developer events, to writing production-quality code and contributing to LaunchDarkly’s SDKs. Ultimately, your goal is to empower developers with the tools they need to make their job better. We meet developers wherever they are and support their journey, wherever that may lead.
  • Develop demo applications against our integrations and/or SDKs to showcase the product use case.
  • Collaborate with our Partnerships team to advocate for the developer voice and create impactful content in the form of demos, blog posts, webinars, and workshops.
  • Write about technology trends focused around feature management, modern application architecture with the goal of engaging developers, developer managers, and senior technical leaders.
  • Lead conversations in the community around best practices for feature flag management.
  • Articulate the technical value proposition of LaunchDarkly experience vs competitive solutions
  • Provide cross-audience support and in-depth technical enablement
  • [SENIOR AND PRINCIPAL ONLY]
  • Plan, own and launch technical enablement programs and training course materials
  • Be the local subject matter expert on identified technologies that are meaningful to the company.
  • Minimum 3 years of production-level software development or operations experience
  • Ability to independently build apps, craft solutions, interact with developers and operators to help them learn through the articulation of your experience.
  • Engaging written and verbal communication skills
  • Ability to work autonomously, willingness to travel when need be.
  • [SENIOR OR PRINCIPAL ONLY]
  • Ability to speak on a variety of topics ranging from deep technical talks to strategy and culture. 
  • Known leader or contributor in your community
  • Preferred Qualifications
  • PM experience and/or have experience building communities.
  • A history of successful speaking engagements, industry influence and / or recognition in technology publications
  • Technical Support Engineer (London)
    London
    Note: This Technical Support Engineer position is located at the LaunchDarkly office in Hoxton, London. The hours will be London-based; however there is an expectation of overlapping some Pacific Time hours as well. * At this time our offices are closed due to COVID-19. We are looking for a Technical Support Engineer who will take end-to-end ownership of customer issues, including initial troubleshooting, identification of root cause, and issue resolution. To best serve our customers, you will become an expert in the LaunchDarkly product and develop tools to improve the LaunchDarkly customer experience. You should be a self-starter who works well with little supervision; we trust you to do the right things with little oversight. LaunchDarkly is a rapidly growing software company with a strong mission and vision carried out by a talented and diverse team of employees. Our goal is to eliminate risk and deliver value for development teams. You'll join a small team and have an immediate impact with our product and customers.
  • Become a technical expert on the LaunchDarkly platform (including SDKs)
  • Use this expertise to troubleshoot customer issues and answer questions internally
  • Communicate with customers in a friendly, timely manner
  • Reproduce and document bugs with Engineering for product issues that are impacting customers
  • Create process or troubleshooting documentation in the support knowledge base
  • Contribute to process improvements and new ways to delight customers
  • Represent customers in internal company discussions
  • 2+ years of customer support, technical support, or related customer facing role
  • Technical fluency with one (or more) development platforms: Python, Node.js, Java, JavaScript, Ruby/Rails, Go, .NET, PHP, iOS, and Android
  • Passion for solving customer issues and advocating for their success, in a fast paced, highly technical environment
  • Experience working with APIs or building integrations between SaaS services
  • Ability to learn new technologies quickly
  • Excellent relationship management, customer service and communication skills in variety of forms (written, live chat, conference calls, in-person)
  • Ability to work independently with little direct supervision and as a part of a team
  • Ability to remain calm, composed and articulate when facing tough customer situations
  • Interest in working on technical side projects to validate what you’ve learned
  • Excellent time management skills and ability to balance numerous projects at once
  • Backend Software Engineer
    Oakland, CA
    Software powers the world, and LaunchDarkly empowers all teams to deliver and control the best software. We serve trillions of feature flags daily to help teams ship better software faster and eliminate risk for companies big and small. We're based in downtown Oakland and growing quickly. We're looking for a backend engineer to help us build features, design and implement API methods, and improve the performance and reliability of our systems. We're looking for someone who knows what it takes to deliver value to customers and takes pride in the quality of their work. The core technologies we use daily include Golang, React, Redux, MongoDB, ElasticSearch, Redis, HAProxy, and NATS. LaunchDarkly is a rapidly growing software company with a strong mission and vision carried out by a talented and diverse team of employees. Our goal is to help teams build better software, faster. You'll join a team from companies like Atlassian, Intercom, and GitHub, and you'll have an immediate impact with our product and customers.
  • Build and expand our APIs and services, written in Go
  • Collaborate with frontend engineers to deliver user-facing features
  • Monitor and improve server-side performance
  • Write unit, integration, and load tests as necessary
  • Actively participate in code reviews
  • Write and review technical proposals
  • Improve engineering standards, tooling, and processes
  • 4+ years of experience and fluency with server-side web development (e.g. in Java / Scala, Ruby, Python, Golang, Node.js)
  • Experience building RESTful APIs
  • Strong computer science fundamentals: data structures, distributed systems, concurrency, and threading
  • Strong communication skills, a positive attitude, and empathy
  • You write code that can be easily understood by others, with an eye towards maintainability
  • You hold yourself and others to a high bar when working with production systems
  • You value high code quality, automated testing, and other engineering best practices
  • Experience with NoSQL databases (MongoDB, ElasticSearch)
  • A deep understanding of networking technologies (TCP, HTTP, websockets, server-sent events, etc.)
  • Verified by
    Engineering Lead
    Director Marketing
    VP of Product and Engineering
    You may also like