Brett van Zuiden

Time, cost, quality: chose 2

Time, cost, quality - for any project you can specify hard constraints on at most two of these factors; where the third ends up will depend on luck and skill.

This is often referred to as the “Iron Triangle” of project management and is one of the better-known concepts from the field. The premise is straightforward but exceptionally helpful in creating alignment amongst stakeholders:

  • If we commit to a predefined launch date and assign a team of fixed size, we have to be comfortable shipping whatever we end up with. We will of course try as hard as possible to build a great product, but if time and cost are fixed, we may need to cut scope or launch with known bugs. In this case, we’re holding time and cost (team size) constant, and letting quality vary.

  • If we hold a high quality bar and have a fixed-size team, we have to be comfortable taking as long as it takes to meet that bar. We will of course try to move as fast as possible, but in this case we are holding quality and cost constant, and so it may take a long time. Superhuman is a great example of this: it was beta launched in august 2017 and is still not accepting public signups as of this post 2.5 years later - but I hear it’s a great product!

  • If we have a fixed time-frame and a certain quality bar, we have to be willing to pay as much as it takes. In most cases, this means adding more people to the team. It is true that you cannot always throw more people at a project to make it go faster, but that’s only one way to vary cost: you could put more senior people on a project or buy pre-made solutions or components. You could put multiple teams on the same problem in parallel to hedge against unforeseen issues with a particular approach. If you are willing to pay arbitrary amounts of money, you can usually find world-class experts that will produce high-quality work in less time than your current team.

Everyone wants high quality products built quickly at low cost - of course they do! And as a product or project owner you should do everything possible to make that happen. But not everything goes to plan, and by surfacing these tradeoffs early, you can ensure that everyone is aligned on which constraints are the critical, immoveable ones.


  • There are variants of this principle that separate “scope” and “quality” but I prefer to consider these as a single constraint - customers consider both features and bugs when assessing whether a product is “good”, and when making tradeoffs you can cut scope and/or cut corners.

  • High-performing teams can produce great quality work faster and with fewer people; that’s why we call them high-performing. There are ways to invest in better practices or train people such that your projects are often completed faster, higher-quality, or cheaper - these are worthwhile investments and should be encouraged. None of this takes away from the fact that on any given project, even the best team in the world cannot guarantee all three of time, cost, and quality - there’s always a chance of unforeseen circumstances. It’s worth discussing in advance what constraint will need to flex to accommodate the other two.

  • It’s worth noting that “time” refers to both building and discovering what to build - if you’re willing to have a team spend a year prototyping and researching a problem, they’ll probably come up with a higher quality product idea than a one hour brainstorming session. You might even save time by investing in discovery: perhaps the team discovers a different solution that takes less time to build, so much so that it more than pays back the time spent uncovering that solution. Balancing exploration and execution is an important skill, but because of the unpredictable nature of exploration, you will eventually have time/cost/quality tradeoffs to make.

  • You don’t need to stick to a certain priority for the entirety of the project - perhaps you start with a fixed launch date and team size (time & cost), but as launch date approaches you realize the quality isn’t quite good enough so you decide to put a few more people on the project to get it over the finish line (time & quality). At any given time, however, you can only pick two.

See also