Experimental Product Management Demands a New Approach to Resourcing

tl;dr

The traditional model of fixed development teams and rigid road-maps hinders innovation in an experiment-driven product environment. To truly embrace agility and respond to the unpredictable nature of discovery, we need dynamic resourcing.

Key takeaways:

• Embrace shorter-range, probabilistic resource planning that aligns with the evolving nature of experimentation.
• Build a mix of core and flexible resources to scale capacity up or down as needed.

Actionable steps:

• Invest in strong product management to drive effective discovery and experimentation.
• Create core teams with flexible "halos" of external or internal resources.
• Split development into different types with varying degrees of flexibility.
• Ensure backlogs of valuable tasks for underutilized resources.
• Foster a culture of internal mobility to encourage flexibility and knowledge sharing.

The Paradox of Experimentation

The true concept of digital product management is, for me, identical to the (true) concept of experimentation. In the perfect vision of the product operating model (which I will refer to as experimental product management), we begin with a product vision and strategy and synthesize this with customer listening and research to generate many ideas. We then take each of these ideas through iterative and progressive forms of discovery, validation and experimentation.

This iterative process is designed to ensure that what we build will actually deliver value, thereby ensuring we invest resources only in what really matters. Much like a scientist who starts with a theory, we gradually test to refine that theory and invest more time and resources only as we become more confident in the theory.

Many ideas that seem compelling to begin with will be proven fruitless. Conversely, things that at first seem weak often develop and grow into highly successful ideas. This is, in fact, exactly the way in which some of the world’s greatest businesses came into being.

This vision has already been popularised by the likes of Itamar Gilad , author of Evidence-Guided, and Teresa Torres , author of Continuous Discovery, as well as being the basis of the Eric Ries ' Lean Startup.

The Road-map Problem

However, this (rightly so) completely destroys the traditional notion of the ‘road-map’. While it is desirable and possible to plan out strategic themes and business questions that will guide the discovery work, or even to plan a focus on specific product components, the idea that a year’s worth of large ‘features’ can be nicely scoped and time-boxed just makes no sense.

The fact that a road-map exists at all in a digital product operating environment is very often a clear indication that it has been unable to shake itself free from waterfall, or the culture and politics of the functional servant IT model. I appreciate this is not easy, and that there are also legitimate reasons for road-maps in certain types of product, but remember I am talking here about the perfect product model in a digital innovation product.

The Resource Allocation Conundrum

But the key point is that the road-map is the traditional method of long-range resource planning, and herein lies the problem I want to focus on in this article: The process of discovery, validation and experimentation at the heart of the true product model contains an inherent conundrum: while we iteratively and progressively align resources to innovate in the most efficient way as we discover value, we nevertheless mostly have fixed teams of engineering resources that need to be kept busy. The process of experimentation and discovery is inherently unpredictable in terms of what it will produce.

However, this is actually an issue that goes way beyond the concept of experimentation of which I am talking. Who in product management has never had to quickly think up ideas for teams to work on to keep them utilised? The fixed set of resources is a cup which must be filled to the brim, and yet the critical thinking and innovation skills and resources required to ensure that cup is filled effectively are almost always under-invested. What, therefore, gets put into the cup? Anything that fits, and especially that which sounds cool and interesting when it is communicated upwards internally!

Furthermore, this often leads to a downward spiral. Big vanity projects are created to keep the resources busy, but these projects mutate and grow in complexity and end up taking all the resources away from the actual innovation work, which then fizzles out. The project then ends and a new vanity project is required to keep them busy again.

Fixed resources, then, are an undeniable challenge to the process of innovation, and the big question becomes: How can we create more dynamic resource pools that can flex and shrink in different disciplines as demand requires? Is this possible?

Framing the Problem

Let’s frame the problem properly that we are trying to solve: In order to achieve the promise of experiment-driven product management, I believe we need two things:

• Shorter-range resource planning/forecasting which is probabilistic in nature
• Resources which can be easily flexed around those shorter terms.

Let’s deal with these separately:

Probabilistic Resource Planning

In the traditional methodology, levels of product engineering resources are planned based on features. Especially where a company has committed to in-house resources, it is not easy to grow and shrink this pool, so it generally becomes necessary to view this on an annual basis; hence a full annual road-map of features and their scope is required to plan levels and types of resources for the full year.

In the experimental product management model, we will work from a constantly evolving set of ideas, each of which will progress through increasingly involved development efforts as they are prioritised, discovered, validated and tested before eventually going into full feature development. While it is not possible to create a road-map of big features, it is nevertheless possible to analyse this pipeline of ideas in terms of what possibilities it projects forwards at any one time.

Sales teams and sales organisations do something very similar: a sales pipeline will have individual opportunities that are sized in terms of revenue and the likely resources needed, and which have a degree of confidence against them. This sizing and confidence can then be used to calculate likely upper and lower levels of likely revenue assuming those things actually happen.

While the technical detail of how you would go about this will need to be the topic of another post, it is nevertheless pretty straightforward. As long as you are tracking individual steps within your broader ideas, including projecting the future steps, their sizing and timing, and your current confidence in them, then you should easily be able to project a what-if scenario for an upcoming month or quarter.

Flexible Resources

In a mythical perfect world, we would just be able to pay-as-you-go and flex resources like turning up or down a dial on something, but this is simply not possible, as there are a myriad of instant challenges before we even get started:

Resources are inherently not flexible, especially in-house full-time employees. For example, it takes a long time to recruit people. Even agency resources and contractors mostly cannot be switched on and off at the drop of a hat.

Good product teams thrive on having stable, long-standing expert resources who own, live and breathe their code domains. Truly flexible, transient development resources would be an unmitigated disaster in ways too numerous to mention here.

Such a model is predicated on having very highly skilled product managers and other resources that can support discovery, validation and experimentation. Unless this part is well managed, the whole thing falls apart. Very few businesses will have this.

So it’s certainly difficult, but the conceptual importance of it doesn’t go away just because it’s difficult. What is the answer?

Building a Dynamic Resourcing Model

In actual fact, this isn’t going to be the same in every company, and trying to create a one-size-fits-all is hopelessly naive. Instead, here are a few ideas that might be pieced together in different ways:

• Invest in Effective Product Management: The kind of model that I am talking about requires critical thinking and advanced organisation skills, as well as experienced support resources adept with data, research and experimentation. While this in itself will not help with the flexibility of engineering resources, it is the most vital starting point.
• Create Core Teams with Flexible Halos: The exact detail of this is going to be highly different in different organisations, but one possible solution is to have minimally sized but senior and highly proficient core teams big enough to do a ‘bare minimum’ level of development, who are then augmented with flexible resources as larger projects demand it. The absolute prerequisite of this, which is not necessarily easy, is that those core teams need to be adept at managing/mentoring and coaching these flexible resources. This is not detail for this article, but this is important: it would not work to simply start throwing freelancers into a squad and hoping that solved the problem.
• Split Development into Different Types: Critical maintenance and support should be easy to forecast, resource and keep constant. Product discovery and experimentation activities further up the funnel (in the sense that they are lower-effort idea tests before they evolve to bigger projects) should be relatively easy to control via ‘velocity’ style metrics at the ideation level. Conversely, the biggest, most involved pieces of development are much less easy to predict and need greater allowance for flexibility. Clear definition of types of tasks allows for more accurate resourcing.
• Utilise a Variety of Flexible Resources: Those flexible resources could come from external agency partners or could be individual freelancers, but equally it would be possible in larger product organisations to maintain a flexible task force of multi-skilled resources who can drop in and out of the core teams as needed. A culture of inward mobility in certain aspects of roles would therefore be beneficial.
• Ensure You Have Backlogs for Under-utilised Resources: As previously mentioned, throwing big vanity projects at under-utilised teams is going to block those resources and therefore create the opposite of flexibility. These resources need to perform valuable tasks, but which either can be easily paused when needed or which take very little time in and of themselves. Technical debt, bug fixing, documentation and developer-experience tasks all suffice, but this will be different for different teams.

This is not exhaustive, but is intended to be a stimulus for you to think about how you can create this flexibility in the most effective and efficient ways. It needs thought and, ultimately, transformation, but if you are looking for quick wins and easy fixes then you probably won’t have read this far anyway!