Daily interaction with the customer team, which includes the product manager, helps ensure that the development efforts stay on track to meet the needs and expectations of the customer.
One of the key tenets of APM is close interaction with product managers and customers. When dealing with uncertainty, risk, fluid requirements changes, and technological frontiers, product managers need to be fully involved in identifying features, specifying feature requirements, determining feature priorities, making key tradeoff decisions (cost, schedule, etc.), developing acceptance criteria and tests, and more. Being the "customer" for an agile project is not an insignificant job, but it may not need to be full time. The key to keeping the project moving is very frequent, if not daily, interaction in which the project team receives a constant flow of information and decisions from the product manager.  While interaction with customers may be important to other types of projects, it is absolutely essential with high exploration-factor projects.
 While, strictly speaking, daily interaction may not be necessary or even possible, titling this practice "frequent" interaction leaves too much room for misinterpretation. A more explicit title such as "regular, high-frequency interaction" would be somewhat more specific, but not enough to overcome the verbosity of the phrase. In the long run, I choose to stick with "daily" since it better conveys the sense of this practice.
In both general business and product organizations, individuals often blanch at the prospect of daily interaction with development teams. As I noted earlier, product managers often wear two hatsan external marketing hat and an internal product development one. Unfortunately, the external demands often override the internal ones, and time with the development team suffers. When exploration factors are lower and development teams possess product domain knowledge, the project might not suffer as much from lack of interaction between the customer and development teams , but when exploring uncertainty prevails, this interaction is vital to ultimate success. Feedback is critical to exploration because, without it, experiments veer off into costly and unproductive directions.
Finally, the project manager (and the team in certain circumstances) needs to coordinate not only with customers, but also with stakeholders in order to obtain required resources and ensure support. Dee Hock (1999) has a unique perspective on the responsibilities of a manager. The first is to manage self, which he defines as "One's own integrity, character, ethics, knowledge, wisdom, temperament, words, and acts." The second is to manage the people who have authority over onemanagers, supervisors, executives, regulators, and others. The third is to manage peers, "those over whom we have no authority and who have no authority over usassociates, competitors , suppliers, customers."
The response to this list of managerial responsibilities, Hock reports , can often be paraphrased as, "If we do all that, we won't have time to manage subordinates ." To which Hock says, "Exactly!" The more teams manage themselves , the less the project manager has to intervene. And the more time the project manager can spend managing upwards and outwardsthat is, managing the participants outside the project teamthe more effective he is.
Another project manager responsibility is stakeholder coordination. Project managers must secure resources and ensure ongoing support for the team. A project team may need a component from another team or an external supplier. The accounting department may need periodic information. Executives may need to be briefed on the progress of the project. Project managers who don't identify each stakeholder and initiate a coordination plan to ensure that each one gets the service he or she needs from the team run the risk of getting blindsided by a disgruntled stakeholder. Some stakeholders contribute to the project's success, and others can be serious impedimentsbut they all have to be managed. While members of the project team can assist, managing up and out is generally the responsibility of the project manager, who must shelter the team from the sometimes crazy politics of stakeholder coordination. 
 For some specific tools for managing stakeholder relationships, see (Thomsett 2002).
The Agile Revolution
Guiding Principles: Customers and Products
Guiding Principles: Leadership-Collaboration Management
An Agile Project Management Model
The Envision Phase
The Speculate Phase
The Explore Phase
The Adapt and Close Phases
Building Large Adaptive Teams