As a consequence of this dependency on other teams, there is a need to have a regular synch-up with these teams to ensure that there is a ongoing discussion with these teams - these regular discussion could be related to the requirements, the schedule, the process of coordination, and and so on. However, some of the discussion that gets missed unless the teams have already had an agreement over the requirements and the schedule is that of the technical teams and the architecture. A lot of time there is the assumption that unless there is an agreement between the teams, there is no need for a regular technical discussion.
However, this can be a fallacy. When the discussion is between teams within an organization, there are far greater chances that there will be an eventual agreement between them. And in many other cases, this would not be the first time that the component will be integrated into the product, the discussion would be related to a newer version of the component that will be integrated into a newer version of the product. In such a case, it makes sense to have an ongoing technical discussion between the product team and the component team. It is also very likely that the technical discussion will be as important as the requirements discussion, since most of the issues in such an integration are of a technical nature. Further, having an ongoing discussion also means that then needs of your team remain high in the attention span of the product team, and that also makes it easier to get what you need from the requirements team.