"Troy Magennis adds a fourth type of dependency which I think is also quite useful. That is ‘product dependency’"

Yes, and IME that is actually the most common type of dependency that tech teams deal with, especially in a CI/CD environment. The whole point of CI is to allow/enable everyone to work in parallel, never waiting for each other.

Pre-CI, programmers would "check out" code. When code was checked out, it was locked and no one else could touch it - people had to wait. CI dispenses with that - no one locks code. Instead, people make their changes, and they merge their conflicts. High coverage tests detect when conflicts are present.

But CI was created when apps were monolithic. Now apps consists of many separate deployable components. Thus, CD was born. CD extends the concept of "integration" to multiple separately deployable components.

The problem is: programmer working in parallel on overlapping things deal with dependencies every day: dependencies between source files, and - with CD - dependencies between separately deployable components. It is a constant struggle that they wrestle with. Tools and techniques such as git, pull requests, API versioning, and myriad others evolved to help.

Product depencies are, in fact, the central problem is software development today. I wrote an article summarizing some common techniques for dealing with product dependencies: https://www.linkedin.com/pulse/agony-dependency-management-cliff-berg/