Bringing Validated Learning to All Enterprises

Atlassian has rolled out a groundbreaking integration.  You can now view feature flag information right within a Jira issue. At first glance, this might seem passingly interesting more than groundbreaking.  If you deploy a feature guarded by a feature flag, you can check its status.  Is it on or off?  What percentage of your user base is seeing it?  In which environments is it active?

This is all certainly useful, but how is it groundbreaking? Well, let me explain. The integration provides continuous visibility for all issue types, up to and including in production.  Historically, issue tracking systems have provided valuable workflow management and insight into issues everywhere but production.  You can track and audit all sorts of historical information about the flow of a feature or issue between states before you send it out into the world.  But once it gets there, it enters a dead zone that relies on other systems for actionable information. With this integration, that dead zone becomes a thing of the past.  You can see what's happening in production and use that intelligence in a quick feedback loop to guide future product and software decisions. That ability—the ability to act quickly in a tight feedback loop—allows something known as validated learning

.  And validated learning, for enterprises, is the key to acting more like a startup and avoiding being on the business end of industry disruption.

To understand validated learning and how it helps in the context of an enterprise, let's take a look at a glaring pain point for most enterprises: silos.  Silos create miniature organizations within your organization.  And their motivations and goals can often become orthogonal to one another—or even conflicting.  The silo problem is such an Achilles' heel for the enterprise that celebrated management consultant Patrick Lencioni wrote one of his famous business fables about the issue. Silos are actually pretty understandable when you think about the nature of scale.  A startup consists of a handful of folks fighting for their professional lives.  They often keep long hours, work crazy schedules, and wear so many hats they lose track of them all.  Because of this, and because their numbers are few, they form a tight, cohesive bond, all working together on everything to deliver success. Then they start to grow.  The core team becomes the management team, which then becomes the executive team in something resembling a more traditional organization.  Scale like this requires systemizing the organization and establishing processes, which, in turn, leads to specialization and increasingly complex interactions. Before you know it, you've got significant organizational silos.  Adding a single open source tool to one of your applications requires a cross-department committee hailing from four different countries.  And once you get to this point, you're primed for a cohesive startup to come along and start eating into your market share.

Enterprises have strategies for dealing with this.  Some innovate through acquisition, and others throw waves and waves of consultants at their processes, trying to eke a bit more optimization out of their various processes. But in more recent years, some have taken a different tack.  They've looked at the startup for inspiration and asked, "How can we be more like that?"  Or at the very least, they've asked, "How can we create little strategic pockets of our organization that behave more like that?" An enormous influence in this direction was the Lean Startup, by Eric Ries.  It's a book and also a first-class movement of sorts.  While this book was, by and large, aimed at entrepreneurs and would-be startup founders, there was also a section dedicated to the subject of "lean startups" within the enterprise.  This gave rise to the neologism "intrapreneurship." Checking back in with the premise of feature flags in enterprise-class issue tracking software, we're seeing a product integration that will represent a crucial tool for intrapreneurs.

To drive the point home, let's consider the Lean Startup movement. We'll take a very brief tour through how it works.  This will likely cover some terms you've heard tossed around, possibly incorrectly at times. To understand the lean startups, the first thing you need to do is start thinking about entrepreneurship and business through the lens of the scientific method.  You observe the world and make a business-related hypothesis, such as "I think people would pay for an app that identified bird calls."  You then contrive of an experiment to reinforce or disprove this hypothesis. Coming back to the business world and to lean startups, you can think of your experiment as your minimum viable product (MVP).  A lot of people confuse the MVP with a beta version or a minimum feature set that a customer will accept. But that's not the case.  An MVP is the cheapest vehicle that you have for running an experiment. For instance, you could put a do-nothing app into the app store that claimed it identified bird calls and see if people bought it.  That's hardly a good long-term business model, but it's a very cheap way to confirm or disprove your hypothesis. Validated learning is the iterative process of running such experiments and accumulating actionable business knowledge based on them.  Knowing whether or not people would pay for a bird app via an actual experiment is a lot more valuable than convening a focus group or simply guessing.

Using MVPs and validated learning is par for the course in the startup world.  Uncertainty dominates everything and entrepreneurs live a daily existence of "adapt or die." (Dying, in the metaphorical sense, meaning that the startup fails.)  So this mode of operation comes naturally. It comes much less naturally in established enterprises, where committees of planning committees ensure that, whatever words you may use to describe your life, "uncertain" isn't on the list.  In this environment, you might spend a year planning a product's development, two years executing it, and another year teeing up the launch. And while that used to cut it, these days, that's a recipe to fall way behind.  So the adaptive enterprises that remain competitive do so through validated learning and MVPs. They shorten their development cycles and push to market faster.  Microsoft, for instance, used to ship their Visual Studio IDEs every few years.  Now, they do it in a constant stream of small updates. But it's not just a technical matter of releasing more frequently, either.  Organizations are instrumenting their software with mechanisms to capture user data.  They're employing analytics on all kinds of data to figure out weaknesses and even anticipate problems before they're happening. Now, if they want to keep up, they're rolling changes out at the feature level. And they're using their issue tracking software to see how users are responding and updating their feature priorities on the fly accordingly.

So in the end, it isn't about seeing whether a feature is turned on in production or in pre-prod.  It isn't about how many users are currently seeing the new version of something. It's about validated learning. It's about product management personnel working tightly with the DevOps organization to form hypotheses about which features will delight users and drive conversions.  And it's about delivering those features quickly to market.  Then it's about all of those people keeping an eye on a Jira issue to see how those features are doing in production. That way, they can immediately start planning their next move. So look for the feature flag status associated with each issue as you go forward.  Sure, it's a window into how the feature is doing in production.  But it's also your window into an approach that can give you a decisive competitive advantage in a world where enterprises can be slow to react.