We did exactly this for the two-month sprint for the initial code for Dawdle. I moved into the contracting firm's office, and we did this stuff all day long. It was great; they got a sense for what was "nice to have" and non-negotiable and I traded stuff that wasn't as important (a functioning search; we ended up using SWISH-E, shudder) for stuff that was (user account management). Both sides learned a lot, and I now know that most programmers aren't as good as the people who did that code.

To this day, two years later, our search still sucks, but the basis of that user account management has meant that we haven't had to touch that code in almost two years.

I definitely agree . . . it's a fairly standard "agile" practice to make sure that product managers/"customers" work closely with developers, but it's often not done that way. The bottleneck at my company has historically been around seating; we have an open office plan with clusters of 4-6 desks, but even then you have to make tradeoffs around who sits near who, and we've historically put developers next to developers and product managers next to other product managers so that they could all talk and coordinate with each other. That tends to mean the product managers are just far enough away from the developers that they don't talk much.

For our most recent development cycle (which started about 10 months ago), we finally bit the bullet and split the product team into cross-functional sub-teams we call "pods" consisting of (roughly) 5 developers, 3 QA, and 1 product manager. Having the product manager sit literally next to the developers, instead of 15 or 20 feet away, has made a huge difference in the interaction there and our ability to quickly iterate on features. Instead of just making assumptions when the product requirements are unclear or don't seem to make sense, we have much more of an ongoing dialog all day about how things should work, meaning we waste a lot less time building the wrong thing.