The 'Iron Triangle' of resources / scope / time usually misses the point
When discussing roadmaps and how long things might take to deliver I occasionally use or hear others use the project management triangle (aka the iron triangle). The triangle posits that the time, scope and resources for a project together define the ability for that project to be delivered successfully and with sufficient quality to meet the organizations’ standards.
The framework is helpful when faced with questions like ‘why can’t we deliver project X by aggressive date Y’ since the triangle shows that we can indeed deliver by that date, but not without either compromising quality (and the likelihood of success of the project), cutting scope or increasing resources.
As an explanatory tool the triangle is useful, but as a general operating model in Product Management it’s pretty much useless. Why?
Scope doesn’t really mean anything in the abstract: If the goal is to build a mobile app to meet a particular consumer need there are a million different decisions on tech stacks, UI patterns and vendor options that could lead to that scope being either manageable or monstrous
Resources implies that everyone involved in the project delivers at a fixed rate: It’s obviously true that some members of a project team will be much more skillful and productive than others. But more importantly than individual skill or talent, people differ in how motivated they are. Highly motivated project teams have a tendency to demolish even ‘hard’ projects quickly
The net result is that highly motivated and skilled project teams make a mockery of the triangle.
ShipIt Days at Atlassian
Every quarter at Atlassian we would hold a 24 hour ShipIt day. For 24 hours everyone in the company would be free to work on a project that mattered to them. The projects could be technical or non technical but the goal was to ‘ship’, i.e. produce something with meaningful real world value in the short time available. I was constantly amazed by the work that was produced, some examples that come to mind:
A solo engineer found several memory hogging features in Confluence that were rarely used and managed to ship a delayed initialization change that reduced the memory usage in our data centers by 100s of GBs
A solo engineer designed and implemented an algorithm to automatically theme a Jira instance based on the company logo that was uploaded. This small change instantly made Jira feel more like home for millions of users
A cross disciplinary team implemented the first version of what is now ‘Confluence Questions’, enabling knowledge workers to ask and answer questions from their peers. As a result the team was funded, the product shipped and is now installed in thousands of organizations
There are hundreds of examples like these, none of which could ever have been accomplished in such a short amount of time if they were a ‘set of requirements handed to developers from “management”’.
Motivating project teams isn’t just important, it’s everything
The motivation and enablement of a team is drastically more important than resources, scope or time. What this ultimately means is that the job of product management isn’t to manage, it’s to inspire, encourage and empower project teams to accomplish a mission in line with the company’s objectives. We should spend more time sharing the market problems we’re seeing and the effects those problems have on humans than debating scope and time.
Ironically, many times when project teams push back on ‘management’ by quoting the triangle, what they often mean is one of the following:
they don’t really understand the problem you’re asking them to solve,
they don’t really believe the problem is impactful enough to be worth solving; or
they don’t have enough knowledge of the user or technical problem space to solve the problem so they’re afraid
None of these problems will be solved with timeline increases, resource increases or scope reduction.