Diving Into the Chaos: Why Innovation Teams Need to Explore

If you're the leader of a large company, you might be looking nervously at some of the scrappy startups that enter your market. Sure, they’re tiny, but they also seem to punch way above their weight, delivering product features at a dizzying pace and snatching away market share.

In response to this challenge, many larger organizations are exploring ways to “disrupt themselves”, creating “intrepreneurs” and innovation teams in the hopes of bringing some of that lean startup mojo to their conservative enterprise culture. However, despite the best of intentions, these innovation groups often struggle to break through the organizational inertia of their BigCo setting, leading to frustratingly slow progress.

Why does this happen? Often the problem is that innovation teams are using inappropriate working models. Their aspirations may be different from their organization’s status quo, but their way of working still doesn’t reflect that.

Why Innovation Needs Exploration

Extreme programming creator, Kent Beck describes product development in three distinct phases: explore, expand, and extract. He calls this 3X.

At the beginning of a product’s life, we are in the explore phase, casting around the market, trying out different ideas to see what sticks. We may not even really know what our product is yet. Then, if we’re lucky, we strike upon an idea that resonates with a set of users who are willing to pay for it;  we have uncovered the mythical Product-Market Fit. Beck explains the importance of focusing on cost in the Explore phase. “Successful exploration is unpredictable, so the highest expected value strategy is to reduce the cost of experimentation and put a little investment into many, uncorrelated experiments.” This risky but necessary free dive feeds into the next phase.

Innovation teams, on the other hand, love this phase. Their purpose and drive are to push the needle forward; this phase of guerrilla development gives them the space to imagine.

‍

“To keep pushing the envelope, innovation teams have to adopt working models that serve them in the early explore phase.”

‍

It’s no wonder that innovation teams struggle to function in environments optimized for efficiency and cost control rather than for experimentation, fast iteration, and maximum learning.

The expand phase addresses the challenges associated with scaling the product. This is also the phase in which users begin to arrive, often, at a terrifying pace. “Unanticipated bottlenecks appear,” says Beck, “All you have time for is to eliminate the next bottleneck just before it derails you.”

Finally, after a whirlwind of scaling, we reach the extract phase, where focus shifts to maximizing efficiency and reducing costs. Because the extract phase aligns with the already existing work models of large organizations, they spend most of their time operating in this stage--possibly even years.

To keep pushing the envelope, innovation teams have to adopt working models that serve them in the early explore phase.

Mapping Out the Explore Phase

To understand how innovation works effectively in the explore phase, we’ll look at what this phase means for a product life cycle. The central theme is uncertainty; we’re not sure that what we’re building will be useful. We don’t even entirely understand the needs of our market and may not be sure which market we’re targeting. In some ways, this is similar to what the Cynefin framework calls the complex domain. This is an area of “unknown unknowns”, where there are no obvious right answers to the problem at hand, but rather many alternative answers.

The Cynefin framework tells us that when operating in a complex domain, we should proceed by probing, sensing, then responding. Experiment, observe the result, then adjust your tactics based on what you’ve learned. As an aside, we can also see this as an OODA loop, a rapidly repeating loop of observing, orienting, deciding, and acting.

Frequent, Small Releases

When operating in the explore phase, we should focus on product delivery practices that maximize rapid feedback loops and frequent course corrections. In terms of release management, this means establishing a rapid cadence of small production releases. We can do this by applying the principles of Continuous Delivery--specifically, the concept of keeping our product releasable at any time. By doing this, we can release small changes to production very frequently; this is the key to establishing a rapid feedback loop.

Lean Product Development

A cadence of frequent production changes is just one half of a feedback loop. We also need to close that loop by adjusting our plans based on what we learn from our most recent changes. This requires a Lean approach to product development. Typical “enterprise agile” practices, such as committing to 2-week sprints planned out ahead of time, do not provide sufficient responsiveness. Instead, teams should look to kanban-style approaches which allow just-in-time course correction for any work that hasn’t yet entered active development.

Operational Independence

For large organizations operating in the extract phase, it makes sense to form centralized teams that provide standardized services by way of a formalized service interface. For example, interacting with a central IT team through a ticketing system. After all, operating in Extract is all about reducing costs and leveraging economies of scale.

However, it is hard for an innovation team to operate in a hyper-responsive way when they are dependent on these sort of centralized teams. Therefore teams operating in an explore phase should aim to decouple themselves from the rest of the organization wherever possible. For example, working in a completely separate, cloud-based environment, rather than relying on shared, centralized infrastructure might be better for productivity and exploration.

Build to Learn

In the explore phase, you’re not building things to last, you’re building them to learn. Innovation teams should be using engineering practices that trade-off long-term maintainability for short-term velocity. It’s OK to cut corners in your software’s internal quality if you’re making those decisions in a conscious way.

Engineers must keep in mind that many quality practices will deliver a positive return-on-investment, even if a codebase is only around for a few months. For example, well-thought-out automated testing will allow engineers to make changes to their code with confidence, allowing innovation teams to move faster.

Why Context Matters

Innovation teams operate with fundamentally different goals compared to other teams within an enterprise organization. Because of this, they have to work differently in order to be successful. Innovation teams need rapid feedback, especially while they are gaining a high volume of vital information during the explore phase. Meet your innovation team where they are and support their diverse set of needs to empower them to deliver on their promise.

‍

Featured Illustration By Jonathan Carrington

Jonathan Carrington was born and raised in Baltimore, MD. He's a multi-disciplined creative with a 12-year background in illustration and design. He enjoys escaping to beaches along the east coast, test driving cars, and being a self-proclaimed avid member of the anime community.