Are You Scared?

Size and Uncertainty

It might seem like an odd question to ask a Product Manager, but here goes … Are you afraid? If you’re working on a non-trivial, interesting product, of course you are! If you’re not at least a little afraid, you’re probably not being adequately challenged.

A better question to ask is: how afraid are you (or should you be!) about your organisation’s intentions for your product? Going even further: What impact does this have on the best ways to steer product efforts? What lessons have already been learnt about how to effectively deal with and manage this kind of fear?

It’s common knowledge that agile methods came about precisely because on most technology projects, scope has most uncertainty at the beginning, and scope uncertainty only reduces through continuous learning as the projects progress.

One way to get started in understanding the impact this has on the best approach to product management is to consider the range of all possible product initiatives on a scale of uncertainty. At the risk of stating the obvious, the less uncertainty there is, the more you can lean towards waterfall or step-by-step phase-gated project approaches. Conversely, agile methods come into their own for initiatives with more uncertainty. This can be represented as a spectrum of uncertainty: as uncertainty increases, agile methods become more appropriate.


Equally important is the project management approach and amount of rigour applied. A single project (for example, building a customer invoicing product) requires a different management approach to a portfolio of projects (for example, building all the modules that make up a full ERP system). We can represent this on a spectrum of project management approaches according to size: as size increases, more rigour is required.


At this point it is worth noting that project size is very closely related to project complexity. In fact, leading authors have explicitly called out size as the reason for complexity in large software projects, simply because as projects get bigger, interactions between elements of the system increase in a nonlinear way. For example, this is from the Fred Brooks 1986 classic No Silver Bullet:

…a scaling-up of a software entity is not merely a repetition of the same elements in larger sizes, it is necessarily an increase in the number of different elements. In most cases, the elements interact with each other in some nonlinear fashion, and the complexity of the whole increases much more than linearly.

What this means is that uncertainty and size are intimately related. If we plot uncertainty against size, we can see that each product initiative has a unique position on a 2-dimensional map. This position can be used to get a handle on when it is appropriate to apply which techniques.

It is impossible, of course, to determine the absolute uncertainty and size of a given initiative ahead of time. However, it is useful to consider the relative position of initiatives within your organisation’s context, on a chart of size plotted against uncertainty. This can inform as to the best product management approach to apply in each circumstance.


To help visualise how this applies practically, consider some familiar examples plotted relative to each other on a size/uncertainty chart.


Building a residential house is a relatively small initiative and it has low scope uncertainty. It can be considered as a single project and it is entirely appropriate to use waterfall together with conventional project management techniques.

Staging the Olympic Games is a large undertaking, consisting of many sub-projects. Yet it too has low uncertainty: after all, the Olympics has been run plenty of times before and the format remains largely unchanged, so we pretty much know the requirements upfront. It is appropriate to use waterfall, but this time with the significant added discipline and rigour of programme and portfolio management techniques.

Most mobile applications are relatively small projects, often with high uncertainty. Specifically, it is unlikely that the functional requirements are known in full up front, and the appropriate user experience (UX) can typically only be discovered with some level of trial and error. Agile methods are appropriate here, together with conventional project management.

A technology start-up is likely to be have very high scope uncertainty and potentially unbounded size. We know that agile methods are appropriate to help deal with the scope uncertainty and for all but the simplest examples, it calls for some form of portfolio management.


Taking this a step further, the diagram below shows common methodologies and when they are relevant in terms of size plotted against uncertainty.


PRojects IN Controlled Environments (PRINCE2)/Project Management Body of Knowledge (PMBoK): These methods were designed to bring discipline to individual projects, with low uncertainty. Both come with a significant body of knowledge and associated certifications. PRINCE2 was developed in the UK and is the most commonly utilised project management methodology in many industries and contexts. PMBoK was developed in the USA. PRINCE2 and PMBoK position themselves as complementary products – PRINCE2 as a “methodology” and PMP as a “standard”.

PRINCE2 Agile/DSDM: These are ways to apply the traditional single-project methods while simultaneously utilising agile methods to deal with uncertainty. PRINCE2 Agile combines agile principles with the discipline and governance of PRINCE2. The Dynamic Systems Development Method (DSDM) project lifecycle grew out of the Radical Application Development (RAD) movement in the 1990s, a precursor to modern agile methods.

Managing Successful Programmes (MSP): MSP is a framework for breaking large and complex changes into manageable, inter-related projects. It defines a set of programme management principles and best practices and is designed to be adapted to specific circumstances. Some MSP users include London Olympics and the UK Ministry of Defence.

Management of Portfolios (MoP): MOP was developed as a way to scale project management disciplines to the management of multiple programmes. It focusses on the needs of decision makers at senior levels and how to sustain progress across a range of parallel initiatives. MoP extends the programme and project management methodologies of MSP and PRINCE2 by putting focus on change management and organisation-level benefits realisation, rather than individual projects or programmes.

Scaled Agile Framework (SAFe) / Large Scale Scrum (LeSS) / Scrum@Scale / Disciplined Agile Development (DAD): These methods are appropriate for large projects with high uncertainty; the idea is to get the benefits of agile methods but at scales beyond single teams.

How is Software Different?

As we have seen, Product management is a mature discipline for physical or “bricks & mortar” products in industries such as groceries, retail goods, planes, trains, automobiles.

For physical products, typically design and manufacturing takes place before the discipline of product management even gets involved. This is because product designs and manufacturing for physical products have long lead times. Even incremental changes to physical products can take a long time to implement. For example, changing the recipe of a breakfast cereal might involve sourcing new suppliers, reconfiguration of processing plants, extensive testing and certification. Thus, the evolution of physical product is a series of discrete increments.

The original conception of the Product Manager role places it in the marketing function. The development of ideas around product management throughout the 20th century has honed the focus to understanding customer needs and finding a way to satisfy those needs using what are termed “the four P’s”: the right product, in the right place, at the right price, using the right promotion. Or alternatively “the 4 C’s”: commodity, cost, communication, channel. Either way, their metrics are sales and profits.

This makes sense. New physical products have long development and production lead times, so Product Managers focus on things they can control like place, price, promotion, and leave the development of the underlying product to others.

By contrast, for contemporary technology products – and especially those involving software – discovery of product requirements occurs throughout the development process. Ideal solutions are arrived at through continual development both before and after first use by customers. In fact, in many cases product development never ends, and evolution of the product becomes a continuous process. This means the very nature of product management is different. Product management must be involved from the beginning of product development and that involvement must continue as the product changes over time.

The consequence is that, in the software world, separation of product management from product development is simply not feasible.

Product Managers can no longer simply rely on place, price, promotion to succeed. Aligning product development with other contributors to products relies on understanding the customer’s needs and the organisation’s intentions for the product, something product management is uniquely positioned to do.

In the modern world, product management is about owning the vision, design, and execution of a product. And whilst Product Managers may not be expert-level professionals in any one aspect, they are involved in conceiving, planning, designing, developing, verifying, validating, testing, launching, iterating, and retiring products.

Some product management frameworks, including some still in use by technology and software product companies – draw a stark distinction between “new product development/acquisition” and “commercialization & manufacturing operations”. In the “bricks and mortar” world, where product developments typically have long lead times, this makes sense – product managers spend most of their time commercialising already-developed products.

However, software (especially given the nearly universal adoption of agile methods) is fundamentally different in that product development happens continuously and never ends.

Here are some of the key differences between physical product management and technology product management.

Physical Product Management Technology Product Management
Product is “given” to the Product Manager Product Manager decides what to build
Product changes have long lead times Products have short lead times
Big design up front Continuous change and redesign
Manufacture/duplication costs time+money Manufacturing / duplication is instant & free
Difficult to add value after development Easy to continually add value

The bottom line is that technology products (especially those based on software) are different, and these differences mean that traditional product management does not work. A new approach is needed, aligned with agile methods.