3 Ways to Use Feature Flags

and none of them are experimentation

Here at Whatnot we love our data. We use it to make all kinds of decisions about what and how to evolve our product. Experimentation is a great way to test out how features impact your users and uncover how your changes move metrics, sometimes in directions you didn’t expect. Our feature flagging product of choice is Statsig which helps us make these decisions. The flags automatically show us the impact each change has on important metrics like watch time, engagement, and purchases. While using feature flags we’ve found other uses that are just as valuable. Heres how we leverage them

Internal Dogfooding

Whatnot is heavily based on real time ephemeral livestreams that start and stop at any time. Sellers start streaming and list items for sale with auction and set price formats. The real time aspect makes it difficult to test our features that depend on live interactions so we use flags to enable features for employees. We can use new features in production, with real users, in a real production workload, so we can test and polish before they’re rolled out. One of the advantages is we don’t have to manage pipelines and releases for different builds of the app since the flags allow us to ship in the same builds!

User Beta

Employees testing in production is one thing, but sometimes you might want to enable new features to a subset of public users that you have contact with. It’s useful to get different perspectives and polish based on real user feedback. One feature we launched did great in internal dogfooding, but as soon as we turned it on for some users we quickly noticed a significant uptick in request timeouts for all users. We uncovered the issue, rolled back the flag, and deployed a fix quickly.

Derisking App Releases

With large projects and features pieces may make it into your app builds before they’re ready. We release our apps weekly and backends multiple times a day, with flags you can control which versions/builds have them enabled so you don’t risk the releases that your team and others depend on. If a new release slips due to an issue then not only does it slow down the current release, but also takes our focus away from the next. With the time and overhead it takes to build, QA, submit, and release an app it’s critical that they stick to a timeline. Deployments don’t mean releases, and decoupling both takes timing out of the equation.

Bonus: April Fools

We have always been inspired by the fun April Fools jokes that companies temporarily run(except Windows 3.1 StackOverflow, my eyes still hurt). This year we ran our own April Fools by temporarily changing our name to WhatKnot.

These are some of the ways we get tremendous value out of flagging that aren’t experimentation. Interested in building with us? We’re hiring!