Article

7min read

How AB Tasty’s Feature Experimentation and Rollouts Enrich the Lives of Our Tech Teams

We developed our feature management tool to provide tech teams with the capabilities to deliver frictionless customer experiences more effectively. Naturally, we also use this tool at AB Tasty, but in the past, we also had to master our development cycles without the tool. 

In this article, I’d like to give you insight into how our tech teams’ work has changed thanks to our Feature Experimentation and Rollouts solution. How did we work before? What has changed, and why do we appreciate the tool? Without further ado, let’s find out!

What a typical development cycle without our feature management platform looks like

The beginning of a typical development cycle is marked by a problem, or user need that we want to solve. We start with a discovery phase, during which we work towards a deep understanding of the situation and issues. This allows us to ideate possible solutions, which we then validate with a Proof of Concept (POC). For this, we usually implement a quick and dirty variant – the Minimum Viable Product (MVP) – which we then test with a canary deployment on one or two clients.

When the solution seems to be responding to customer needs as intended, we start iterating the MVP. We’re allocating more resources to the project to get it into a robust, secure, and user-friendly state. During this process, we alternate between developing, deploying, and testing until we feel confident enough to share the solution with our entire user base. This is when we usually learn how most of our users react to the solution and how it performs in a realistic environment.

The pitfalls of this approach, or: Why we developed a server-side solution

Let’s see why we weren’t happy with this strategy and decided to improve it. Here are some of the main weaknesses we discovered:

Unconvincing test results.

A canary release with one or two clients is great for getting first impressions but doesn’t provide a good representation of the solution’s impact on a larger user base. We lacked qualitative and quantitative test data and the ability to use it simply and purposefully. Manual trial and error slowed us down, and our iterations didn’t always produce satisfactory results that we could rely on.

Shaky feature management.

Developers were often nervous about new releases because they didn’t know how the feature would behave under a higher workload. When something went wrong in production, it was always incredibly stressful to go through our entire deployment cycle to disable the buggy code. And that’s just one example of why we needed a proper feature management solution. 

We see tech teams around the world know and fear the same difficulties. That’s why we created a server-side and feature flagging solution to help them – and us – innovate and deliver faster than ever before while reducing risks and headaches. 

I spoke to some of my tech teammates to determine how their work lives have changed since we started using our new tool. I noticed some major themes that I’d like to share with you now.

We know the impact of a new feature

Our product teams need to make a clear connection between a business KPI and a feature under test. In the past, we’ve fiddled with Google Analytics for a rough idea, but without distinct control and test groups for our experiments, we couldn’t know if our changes made a difference.

With our feature management platform, we no longer have to guess and can follow a scientific approach. We now know for sure whether a business KPI is positively impacted by the feature in question.  

Suppose we publish a new feature while the marketing team starts a campaign without us knowing about it. We may get abnormal test results such as increased traffic, engagement, and clicks because of this. The problem: how can we measure the real impact of our feature?

The platform lets us define control groups to reduce this risk. And thanks to statistical modeling (Bayesian statistics), we get accurate data from which we can make a reliable interpretation.

The discovery phase lives and dies with qualitative information – but how can you get reliable data? Our answer is to conduct controlled experimentation and progressive deployments.

One time, we worked on a new version of one of our APIs and used our server-side solution for load testing. Fortunately, we found that the service crashed at some point as we gradually increased the number of users (the load). The problem wasn’t necessarily the feature itself. It had to do with changes in the environment, which can be easy to miss with traditional web testing strategies. However, we could stop the deployment immediately and prevent end-users or our SLAs with customers from being harmed by the API changes. Instead, we had the opportunity to further stabilize the API and then make it available to all users with confidence.

We iterate faster by decoupling code releases from feature deployments

We often deploy half-finished features into production – obviously, we wrap them in feature flags to manage their status and visibility. This technique allows us to iterate so much faster than before. We no longer have to wait for the feature to be presentable to do our first experiments and tests. Instead, we enjoy full flexibility and can define exactly when and with whom to test.

Additionally, we no longer have to laboriously find out who can see what in production during feature development, as we don’t have to integrate these things into our code anymore. Instead, we use the Decision API to connect features with the admin interface through which we define and change the target groups at any time. 

What’s more, everyone in the team can theoretically use this interface and see how the new feature performs without involving us developers. This is a huge time saver and lets us focus on our actual tasks.

“Our Feature Experimentation and Rollouts solution helps me take back control of my own features. In my old job, I was asked to justify what I was doing in real-time, and I sometimes had trouble getting my own data in terms of CDP MOA, now I can get it.”

Julien Madiot, Technical Support Engineer

We can rely on secure deployments

Proper feature management has definitely changed how we work and how we feel about our work. And by managing our feature flags with our feature flagging platform, the whole process has become much easier for our large and diverse teams. 

EVERY feature has to be wrapped in a feature flag – this is possibly one of our most essential rules in development. But it pays off:

  1. They’re ON/OFF switches. Let’s not lie: we still make mistakes or overlook problems. But that’s not the end of the world. Especially not if our code is enclosed in a feature flag so that we can “turn it off” when things get hairy! With our feature flagging platform as our main base for feature management, we can do this instantly, without code deployments.
  2. They help us to conduct controlled experiments. We use feature flags to securely perform tests and experiments in real-world conditions, aka in production. A developer or even a non-tech team member can easily define, change, and expand the test target groups in the dashboard. Thanks to this, we don’t have to code these changes or touch our codebase in any way!

They cut the stress of deployments. Sometimes we want to push code into production, but not yet for it to work its magic. This comes in handy when a feature is ready, but we’re waiting for the product owner’s final “Go!”. When the time comes, we can activate the feature in our dashboard hassle-free.

DevOps engineers have many responsibilities when it comes to software delivery. Managing our feature flags with our server-side solution is an effective way to lift the burden off their shoulders:

I honestly sleep better since we started using our server-side solution 🙂 Because I’m the one that puts things in production on Thursdays. When people say ‘Whoops, we accidentally pushed that into production,’ now I can say, ‘Yeah, but it’s flagged!’

Guillaume Jacquart, Technical Team Leader

Wrapping up

I hope you found the behind-the-scenes look at AB Tasty both interesting and informative. And yes, if there was any doubt, we actually use AB Tasty’s Feature Experimentation for all AB Tasty feature development! This helps us improve the product and ensure that it serves its purpose as a valuable addition to modern tech teams. 

Subscribe to
our Newsletter

bloc Newsletter EN

We will process and store your personal data to respond to send you communications as described in our  Privacy Policy.

Article

7min read

The Step-by-Step Guide to Progressive Rollout

You’ve heard all about the surface-level benefits of rapid product releases. They let you explore, experiment with, and test features faster. They create a more collaborative development process. And they let you run an efficient high-output team.

All of these benefits are true, but the biggest benefits you’ll enjoy from driving rapid releases lie even deeper than is commonly acknowledged…

Rapid releases do create better products. Rapid releases create a short feedback loop between you and your users. You learn very quickly what’s working and what isn’t, and you can quickly adjust.

But even more important, rapid releases get you and your team out of your own heads. Rapid releases force you to get your product and feature ideas out of the lab and into the real world. This constant contact with reality leads you to create products that simply and directly deliver the actual functions your users need most, while leaving the nice-to-have fluff on the whiteboard. 

Rapid releases do create happier users. Rapid releases let you provide new features, and fix bugs, as quickly as possible. You constantly give your users a better and better product.

But on an even deeper level, rapid releases demonstrate that you care about your users. It shows them that you are listening to their feedback, and that you are taking it seriously. It tells your users that you care about them so much that you have structured the heart of your product management strategy around doing whatever it takes to make them happy and loyal.

Rapid releases do create better businesses. Rapid releases—when properly executed—can create a lot of excitement and enthusiasm throughout your entire organization. They create a culture of progress and forward momentum, where everyone feels that they are contributing to real outcomes and not just spinning their wheels.

But rapid releases also improve your organization’s culture through an even subtler mechanism. Each release can act as a touchpoint that connects the product team with everyone else in the organization. It gives you a common reason to celebrate, to collaborate, and to realign groups that are too often siloed.

Now, we don’t want to oversell rapid releases here. They are not a cure-all, and they are not even appropriate for every single situation. But if you are operating in a context where you can accelerate your product and feature release cycle, you’ll experience a whole lot of upside with little-to-no downside.

To help you drive rapid releases in your organization, we’ll use this piece to explore why rapid releases can be challenging to pull off (even in an agile product development framework), what is the key ingredient you can adopt to overcome all of these challenges, and how to bring that ingredient to life in your organization.

The Biggest Challenges to Driving Rapid Releases

Let’s be clear about one thing— not every organization is well set up to deliver rapid releases. Product managers at big, legacy corporations tend to have a hard time getting anything out in a timely manner. This is almost never their fault. They just have so many layers of review and approval for everything they do that it can take months to push out a small feature that a smaller, nimbler organization could release in weeks or days.

If this is your context, then the best thing you can do is attempt to establish the core principles of lean product development in your organization. This will represent a huge win, and speed things up significantly for you, all by itself.

Now for the rest of you— Let’s assume you are working at one of those smaller, nimbler organizations. And you are already following an agile product development process. And you still are not releasing new products and features as quickly as you’d like. Chances are, you’re being bottlenecked by one or more of these subtle challenges:

  • You are completing sprint after sprint but you never seem to get any closer to having something to release. Your entire development process feels like it’s focused on completing code, and not completing products and features.
  • You are getting products and features close to release, but they get trapped in the testing and QA process. This delays their release significantly—sometimes indefinitely.
  • You are able to complete new features and products, but release gets delayed because it’s such a miserable process. It’s always a big, chaotic scramble. And everyone—from your product team to your business stakeholders—gets stressed and worried about what’s going to happen when you publish the changes and delay the process.

None of these issues are solved by the fundamentals of agile product development. It’s easy to focus agile workflows on development and never give much thought to release. It’s easy to put off testing and QA until the last minute for the sake of velocity, and wind up with a huge backlog to deal with at the end. And agile products and features have developed a reputation (deserved or not) for being buggy, broken, and more aligned with what the product team thinks is right, and not what the customer actually wants.

It’s clear that agile in and of itself will not solve these problems, nor ensure rapid releases. But a small tweak to agile will.

How Progressive Rollouts Unlock Rapid Releases in Agile Product Development

You’ve heard of progressive rollouts before. They are considered an optional subset of agile methodology that restructure the entire release process.

Traditionally, a product manager would release a new product or feature in its full form, to every user, at the exact same time. But a product manager that follows progressive rollouts would release that same new product or feature in smaller forms, to a few user groups at a time, and in staged intervals.

Essentially, progressive rollouts let you break up “big bang” releases into smaller chunks. And along the way, you end up solving a lot of the challenges that prevent rapid releases. For example:

  • Progressive rollouts shift the product team’s focus off developing new code, and onto driving releases.
  • Progressive rollouts force you to focus on code quality, and readiness to deploy, instead of code volume.
  • Progressive rollouts remove most of the risks—and resulting stress—from releases by shrinking them into smaller, easier-to-control stages.

Progressive rollouts are the key ingredient that takes the solid foundation of lean product management, and ensures it’s properly lined up to deliver rapid releases. Here’s how you can bring it to life in your organization.

7 Steps to Ensuring Rapid Releases with Progressive Rollouts

  1. Structure Your Release Phases: Don’t let them be hurried, disorganized dashes at the end of a development cycle. Give them the same time, attention, and care as you give every other element of your product management framework. Create formalized processes, and adopt the tools you need to make those processes automatic habits.
  2. Decide Which Products and Features to Release. Review your current queue. Identify the highest impact products and features that you can drive to completion soonest. Employ feature flags to hide features in products that aren’t ready yet, and focus your users on one small subset of new functionality at a time.
  3. Establish Your Personas and User Groups. Identify your highest-value users, and the opportunities they represent. Leverage these groups to test the new products and features they will love most. Personalize and customize their experience to let them know they’re getting early access because of just how valuable they are to you.
  4. Plan Your Progressive Rollouts: Define the features and products you are going to release. Define who they are going to be released to. Define when they are going to be released, and what the stages look like. And then organize your sprints to deliver to these requirements.
  5. Define the Impact of Each Rollout. Establish the exact, measurable, accountable business metrics you plan to improve with each of your rollouts. Define the hard and soft impact each release will have on every function in your business— and tell each function about the release before it happens.
  6. Communicate Your Release. Loop your business stakeholders in on each element of your release plans that might give them pause or concern. Show them how progressive rollouts mitigate their risk around product and feature quality and alignment. And update them on the progress of each release at each stage of your rollout. 
  7. Automate as Much of Your Rollout as Possible. Remove yourself and your team as the bottleneck. Automate your QA and testing. Set your deployment intervals and parameters, and then let your software execute it for you. Monitor your release’s performance at each stage. A/B test as much as possible. And intervene ASAP when an issue is identified. But otherwise, let the right tools make rapid releases through progressive rollouts a smooth element of your agile product development process.

With a little bit of intentional planning, with a shift in the focus of your agile product development, and with the right tools, you can easily bring progressive rollouts to your organization, and rapidly increase the rate of your releases.