Product teams that don’t take into account a user communication and user feedback collection strategy as part of their experiments risk not getting enough data to evaluate results. This article walks through a couple key communication steps that products should follow to ensure effective and timely product experiments.
As our software development processes have evolved we’ve mostly said goodbye to the idea of defined product versions. Many modern product delivery teams are taking this a step further – even the concept of a “product release” is starting to fade. Instead our products are becoming a fluid, rapidly evolving set of features, assembled uniquely for any given user.
Following up from the excellent post by Pete Hodgson on Retiring Your Flags, and his presentation at the Meetup we recently sponsored, I wanted to …
Teams working with feature flags usually come to the conclusion that a large number of active flags isn’t necessarily a good thing. While each active feature flag in your system delivers some benefit, each flag also comes with a cost. I’m going to explain those costs, such as cognitive load and technical debt, and explain how to avoid them.
Feature flagging systems can sometimes become victims of their own success. The benefits of feature flagging along with the broad applicability of the technique can lead to rapid adoption within an organization, and pretty soon the number of active flags can start to feel overwhelming. One way to keep your feature flags manageable is to introduce a categorization system.