There seems to be a lot of misunderstanding about this article.
First, you have to understand the context. This person is talking about an Extreme Programming team. Speaking as someone who wrote a book about XP, here are some things that are true about by-the-book XP teams:
1) All production programming is done in pairs, all the time.
2) Everybody sits in a shared team room at dedicated "pairing stations."
3) The atmosphere is highly collaborative and friendly, and there's always a low buzz of conversation in the room. Interruptions are normal and expected, as the team's overall performance is valued more highly than individual performance. Due to pairing, interruptions tend not to interrupt flow.
4) Requirements are conveyed verbally, not through written documents. Stories are short "reminders to hold a conversation," not fully-fleshed out.
5) The team values feedback and wants frequent conversations with their on-site customers (including the product manager) to confirm that they're on the right track, particularly about nitpicky details that are difficult to anticipate in advance.
Given this context, the author is talking about how he, as a product manager, does his job of providing business context and customers' points of view.
This material is not meant for people who aren't on an XP team. It's good advice for product managers who are.
First, you have to understand the context. This person is talking about an Extreme Programming team. Speaking as someone who wrote a book about XP, here are some things that are true about by-the-book XP teams:
1) All production programming is done in pairs, all the time.
2) Everybody sits in a shared team room at dedicated "pairing stations."
3) The atmosphere is highly collaborative and friendly, and there's always a low buzz of conversation in the room. Interruptions are normal and expected, as the team's overall performance is valued more highly than individual performance. Due to pairing, interruptions tend not to interrupt flow.
4) Requirements are conveyed verbally, not through written documents. Stories are short "reminders to hold a conversation," not fully-fleshed out.
5) The team values feedback and wants frequent conversations with their on-site customers (including the product manager) to confirm that they're on the right track, particularly about nitpicky details that are difficult to anticipate in advance.
Given this context, the author is talking about how he, as a product manager, does his job of providing business context and customers' points of view.
This material is not meant for people who aren't on an XP team. It's good advice for product managers who are.