I never liked this framing, because the tradeoff space over the short and long term are very different. If you first focus on good, economies of scale make cheap possible and the lack of technical debt makes fast for future versions after the requirements have changed a lot much easier.
If you start with fast and cheap, that can work in the short term but the only way to get to good is to abandon cheap. As technical debt accumulates, you end up losing both fast and cheap - you can't respond to changing requirements because of decisions you made a long time ago and you can't do cheap because you've accumulated too many inflexible small fixed costs.