Skip to main content

Standard Operating Procedure

Overview​

This document details how to cross-functionally set up experiments between the Lead Gen Growth Pod's Product Manager (PM) with Engineers (SWE).

Ticket & Feature Flag Setup​

  1. PM writes a Linear ticket in the Lead Gen team board, under the respective feature flag experimentation project, with acceptance criteria – for business and technical requirements.
  • Each project has pre-built templates for: issues and teardowns.
  1. PM to set hypothesis, metrics, and variant values:
  • If it is an A/B test, we should use the boolean type (true and false)
  • If it is an A/B/C… test, we should use the string type
    • When using string type, we want to use “A”, “B”, “C” respectively
  1. PM creates Growthbook feature flag:
  • Naming convention: [COMPONENT]_[TEST-NAME]_[YYYY_MM]
    • pdp_color-selector-placement_2026_01
    • lp_color-bar-layout_2026_02
  • Enable qa and staging/development environments only, not production.
  1. Set up the corresponding experiment and assign the feature flag to the experiment. Please keep the experiment key name short, but the GrowthBook title descriptive! This will help with keeping the cookie storage small.
  • Experiment Title: 2026-02 | PDP | Simplified Dual Sale Selectors
  • Key naming convention: [COMPONENT]_[MAX-3-WORDS]
    • pdp_enable-reviews
    • lp_test-h1-titles

You can refer to the GrowthBook documentation, but please utilize the above internal rules, so we're consistent on all our experiments + feature flags:

Technical Implementation + QA​

After the Linear ticket and project brief has been refined, estimated (pointed), and assigned to the SWE.

  1. SWE completes technical implementation and gets PR reviewed by larger tech dept.
  2. After completing the task and after the PR is merged into the codebase and graduated to QA, SWE writes manual testing steps for PM and attach to #lead-gen-tech Slack channel for PMs to test experimental features.
  • If there are errors, PM will reach out for fast-follow/refinement ticket.

Feature Flag + Experiment Launch​

After the Feature Flag and Experiment are pushed live into the production website.

  1. When the pre-release is graduated to production release, PM will:
  • Update any Builder configurations that are necessary.
  • Check on the live site (incognito mode) to ensure tests are running correctly using the /gates console or Growthbook Chrome extension.
  • Send back to SWE for final QA on content and configurations.
  1. When production QA passes, PM to turn on the production environment in the feature flag and start the corresponding experiment.

After test wins:​

  1. PM creates a teardown ticket in Linear (template is available in project), indicating which variant won, and attaches the corresponding implementation ticket in the description of teardown.
  2. SWE implements teardown. Engineer is to:
  • Write formal automated tests for the updated implementation
  • Update docs.birdygrey.com where relevant
  • Create utility/helper functions, organize into proper libraries
  • Strip out functionality for the losing variants
  1. SWE sets up pull request for larger engineering team to review.
  2. Monthly archive: SWE to go through codebase with the PM to walk through stale feature flags and experiments to archive. Create additional cleanup tickets as needed.

Please note: this is a living document and will be updated sporadically as processes change. Last updated 3/25/26.