How Agile Is Your Triangle?

Traditional project management represents constraints as an “iron triangle”, meaning that a given project has 3 inter-related considerations: schedule, cost, and scope.

Iron Triangle 1

Someone defines the scope up front, then project managers figure out the cost (resources like materials and people) and the schedule (time lines, Gantt charts, critical path, and so on).

The idea is that the customer (or someone, at least) knows the scope. In fact, scope is not under the control of project managers. If the estimated amount of materials was too low, project managers can request more materials (increase the costs). If the estimated time line was too low or the project team is slower than estimated, project managers can request more time (increase the schedule). The scope is non-negotiable.

Iron Triangle 2

In traditional projects – whilst the focus is on delivering the scope (defined up front) – the risks therefore are that schedule and/or cost increase. This is the way organisations manage waterfall software projects. And it results in many projects running over budget, over schedule, and (worse still) delivering a broad scope only to discover later it is not what the customer really wanted.

Agile project management flips this. The agile project management philosophy is that you – as a product company – know the schedule and cost. You know when you want to release. You know the resources you have (developers, testers, devops, and so on). The thing that can change is the scope.

Iron Triangle 3.jpg

The risk with this approach is reducing the delivered scope. However, agile combines this with the incremental delivery of the highest value backlog items (features, bug fixes, improvements) thus enabling organisations to focus on what really matters: optimising the output of fixed resources.

Who decides the highest value backlog items? Why, I’m glad you asked. The Product Manager, of course.

With various flavours of agile taking over the product world, it is easy to see why the Product Manager role is central to success.

Have a look around in your organisation and ask yourself: how agile is your triangle (on the scope vertex, at least)?

Context Is Everything

There is no shortage of advice available for product managers. There are hundreds of websites, blogs, books, courses and experts willing to offer their opinions to whoever will read or watch or listen. A lot of the advice revolves around techniques to ensure that thinking of customers is the central concern of product management. Indeed, if you do not have customers as a central concern, then advice on how to ensure they are will be helpful for you. At least as important as happy customers, however, is aligning product management efforts to what your organisation is trying to achieve. Your organisation exists for a reason and has goals to achieve (and hopefully the goals are explicit), so to be successful the product must help your organisation achieve its goals. Context really does matter.

In a philosophical sense, the idea is to take the time to understand where you are before you set out on a journey: if you don’t know where you are, how can you get where you are going?

What is the context for product management? Each organisation is unique, but we can reduce “context” to a short list of considerations.

First, your goals.


Path to profit

What business model(s) is your organisation targeting, to make money? The choice of business model impacts product. Subscriptions, marketplaces, platforms, brokerage, services, …: the way you commercialise the product impacts what product you build.

Type of innovation

Are you inventing something truly new, or improving an existing thing? A lot of research has been done on removing barriers to different types of innovation, and understanding the type of innovation you are trying to do is a first step to efficiently achieving your goals.

Bigger picture

Are your goals part of a broader industry transformation? The move to music streaming is an example where many players were part of an entire industry shifting to new product technology (and business) models. The history of industry transformations is well researched and lessons can be learnt without repeating past mistakes.

Second, your constraints.



How risky / complex are your goals? Building mission control software for a human journey to Mars differs in complexity and risk from an app that delivers weather forecasts to a mobile phone. Clearly the level of risk and complexity impacts the product management approach.


How mature is your organisation? Size: The environment in a lean startup is different to a large multinational corporation. Capability: An organisation without repeatable processes and with no ability to learn from past mistakes is different from one with clear processes and continuous improvement ideas embedded. Product managers in organisations at different levels of maturity need to adjust how they go about their work.

The Iron Triangle

Every organisation and project (and therefore product) will have – in one way or another – time, cost and schedule constraints. Working within these constraints is obviously a consideration for product managers.

What is YOUR context?

Each of the 6 considerations above is a topic in itself. Later blog posts will dive into each of these.

In the meantime, have a think about your context. Do you understand your unique goals (path to profit, type of innovation, bigger picture)? Do you understand your unique constraints (scariness, maturity, your iron triangle)?

If not, try to step back and consider each. It might just change the way your take your product forward.