Follow us and stay on top of everything CRO

Feature Flagging Your Way to Product Success

Duration - 60 minutes

Key Takeaways

  • Feature flags can be used to control the release process, allowing product managers to choose the timing and audience of the release, and reduce risks associated with releases. This decouples deployment and release, allowing for more flexibility and control.
  • Feature flags can be used to manage delivery pin codes in real-time, allowing logistics managers to respond to disturbances or issues in certain areas. This can help prevent negative customer experiences due to delivery issues.
  • Feature flags are not suitable for long-term access permissions or authorizations. They are best used for short-term changes and should be removed once they've served their purpose.
  • Feature flags can be used for A/B testing, allowing for different versions of a feature to be presented to different users. This can help with product development and improvement.
  • It's important to monitor key performance indicators (KPIs) and metrics when releasing new features or changes to ensure they are not adversely affected. Feature flags can help with this by allowing for gradual releases and easy rollbacks if issues arise.

Summary of the session

The webinar, hosted by Shanaz Khan, features Puneet Kaura, the Associate Director of Product Management at VWO, discussing the importance of speed in product success and the role of feature flags. Puneet shares his experience at NetMeds, where feature flags were used to manage delivery pin codes during a political disturbance. He also explains the different types of feature flags, their longevity, and frequency of change.

Puneet emphasizes the role of feature flags in decoupling deployment and release, allowing product managers to control the release process and timing. His insights are based on his 11 years of experience in product management and entrepreneurship.

Webinar Video

Webinar Deck

Top questions asked by the audience

  • When should we use an open-source solution versus buying a SaaS solution for feature flagging?

    - by Abhishek Verma
    Okay. So I have strong views about this. Open source solution essentially never, but let me clarify. Only use an open-source solution at the point where it gets prohibitively expensive to use any of t ...he SaaS solutions. I'll give you a nuanced answer here. See, we are all going towards a world of specialists where each product should do one thing very well. And outsource any other noncore things. Since this is an internal product, your developers will not enjoy building this out, there will be high attrition in the team that is building out this product. You will obviously not be able to achieve the kind of finesse that a SaaS provider offers. So unless you are at a point where the cost of this solution or procuring the solution is relatively expensive, which is like only 1% of the companies in the world, you should never roll out your own solution or use an open-source solution. You should always delegate this to a specialist.
  • What is the best practice for handling turning off of a feature, while users are in the system, especially ones who actively use the new feature or the workflow.

    - by Troy
    So, essentially, the rollback only happens when there is some adverse effect of the feature. So I don't have a great answer to this. The pullback has to happen because it is providing a bad answer. On in one context, this can be slightly bad. So imagine you are experimenting with something and users are exposed to that experiment, and then you want to pull back. So companies like Italy offer sticky features you can enable the option if a customer has been exposed to a certain experiment, and it'll continue to be part of that experiment for a period of time. In any other case, where this feature is adversely affecting the performance or the customer experience, it has to be rolled back.
  • How do you manage removing the feature flags? How does the full stack link to the insights team?

    - by Kelly Twist
    Okay. I'll answer the second question first. As of now, the full stack does not link to the inside tool. So the full stack product and our front-end product are separate pieces, separate containers, a ...nd they do not interact with each other. There are plans to do so, but there is no defined timeline regarding removing the feature flags. This is a very essential element of managing the feature flag cycle. I've seen a lot of instances where customers do not remove these feature flags. And suddenly there is a product breakdown due to one of these. So there is no good way. Essentially, as I told you, there are 4 kinds of feature toggles. This should be part of your clearing of technical debt to remove the dead feature plans from your system. I do not have a great process to propose here, but essentially do it after a certain period of time. Probably it should be the owners or the product manager to make sure that a feature that has been rolled out to everyone or an experiment that has ended is removed from this.


Disclaimer- Please be aware that the content below is computer-generated, so kindly disregard any potential errors or shortcomings.

Shanaz from VWO: Hey, everyone. Welcome to another session of VWO webinars. We’re experts in digital marketing, experimentation, data, and products and share their treated and inspiring stories for you to learn from. I’m Shanaz Khan, Marketing Manager at VWO. For those of you who do ...