Recently, we announced a new addition to the Split SDK lineup: mobile support. While non-mobile teams have been reaping the benefits of using Split for feature flagging and feature experimentation for some time now, the logical next step was to enable mobile product teams with Split’s robust feature set. I wanted to talk about what these benefits are and why they are important for the modern product team.
Feature releases are becoming more frequent
In the not too distant past, organizations were making updates to their products on a periodical basis. As customer demand grew, automation became trivialized, and subscriptions became commonplace, the boundaries between releases has blurred into a continuous line. Nowadays, releases aren’t happening just on a regular basis, they’re happening multiple times per day.
Separating the signal from the noise
The goal of nearly every software feature release is to make improvements to the software itself. The reality is that not every feature release will result in positive improvement and the consequences for this could be severe: loss of users, revenue, or worse – both. The objective for most product teams is having to balance the ever growing product roadmap and business objectives with risk mitigation.
With the sheer amount of data that is becoming readily available, organizations such as Microsoft, Amazon, Netflix, LinkedIn, Vevo, and Twilio are turning to measuring their metrics against their feature releases to mitigate risk and understand their users in greater detail than ever before. The process is as follows: release your features to a subset of your users and observe their behavior. Once you find statistically significant results, roll it out to the rest of your users. Simple, right?
The challenge becomes not only collecting this data but also producing meaningful results from the data. This is actually extremely difficult to do, especially in a scalable and cost-effective manner.
Split enables feature experimentation
Split separates code deployment from feature release through the use of feature flags, and closes the feedback loop by gathering customer usage data and correlating them to the individual features. Essentially, every feature becomes an experiment. In turn, it helps make product development teams more successful by arming them with the right data to pay attention to while analyzing user activity and success metrics.
Conducting a feature experiment in Split is straightforward:
- Wrap your new feature with feature flags using the Split SDK (we refer to these as “Splits”).
- Toggle features within the Split Console to a subset of your users (we refer to these as “treatments”).
- Gather customer feedback via events and tie metrics with your treatments. Split can also integrate with your favorite third-party tools.
- Analyze the results and make the decision on whether or not the feature should be rolled out to the rest of your userbase.
Feature experiments can range from minor UI updates to entire system overhauls. As of the time of writing, Surfline is currently using Split to manage a migration to a new platform. Once their users are 100% on the new platform, they anticipate putting every code change behind Split before exposing them to their entire user base.
What if I want to take advantage of other use cases that Feature Flags provides? Can Split do that?
Yes. All you need to do is wrap your features in a Split. When you’re ready to turn the feature live, simply do so from the Split Management Console. You can also turn it off whenever needed as well.
For example, within mobile environments, a common use case is to control features remotely. You can’t always rely on users to update your software to the latest version, so config files won’t be fully effective. Instead, by use of the Split’s management console, you can toggle a feature without needing to deploy a new update.
Split can accomplish feature flagging in way that is not only easy for non-technical product managers to use, but also in a performant manner as every Split is cached and processed locally to reduce overhead.
Start experimenting with Split today
If you would like a hands on demo or have additional questions not covered here, please do not hesitate to contact us. We’ll get in touch as soon as possible.
Stay up to date
Don’t miss out! Subscribe to our digest to get the latest about feature flags, continuous delivery, experimentation, and more.
Split manages more than 50 billion feature flags changes around the world every day. A recent study shows that about 5 to 6% of feature flags are rolled-back (or killed, using Split terminology in reference to a kill switch) within 30 days of being created. This speaks to the importance…
At Split we believe in the power of metrics, and are always striving to improve the ways we help our users make more data-driven product decisions. In this previous post we talked about the importance of understanding the impact of a new feature release via key and guardrail metrics. With…
When we speak to our customers, one of the most common reasons they say they made the move towards feature flags was the need to make sure their releases didn’t cause more errors for their users. By leveraging feature flags to ramp the release of their features to just small…