In the small corner of the blogosphere devoted to product management, you'll often find musings about the value of customer advisory boards (CABs), such as this post from the Cranky Product Manager. In my own experience, CABs are frustrating beasts, which is why PMs keep talking about how to handle them:

• Development teams know that they should have some regular contact with customers.
• However, they view regular contact as a luxury--particularly if CAB meetings turn into an expensive boondoggle. (Fly in the customers, treat them to an all-day session, have dinner with them in the evening...)
• Therefore, CAB meetings often happen, at best, only once per year.

In short, CAB meetings happen just often enough to raise the customers' hopes that the development team will actually listen to them. Unfortunately, since the development team only meets with the customers once per year, the product direction is usually significantly out of whack with the customer's wish list. Therefore, the development team recoils from the substantial work needed to respond to these enhancements, so the requests into the "When we have time to get to these" memory hole. One year later, the cycle of mutual frustration starts all over again.

That's why, when I ran PM teams, my rule of thumb was, "Don't bother having a CAB if you're only going to meet once per year." CABs should be trusted advisors, which isn't possible with yearly "drive by" meetings. I'd rather have quarterly webinars with the customers than a yearly face-to-face meeting. The conversation might not be quite as good, but at least you'll keep in touch with them often enough to ask for clarification, get their feedback on ideas, and show them how their requests are affecting the trajectory of the product.

CABs have lots of other problems that I won't cover here, but are worth a short mention:

• Confusion of product marketing and product management goals. Not every good candidate for the CAB is willing to be a customer reference. Unfortunately, that's the entrance requirement for some CABs.
• Too many CAB members. You can quickly reach a point of diminishing marginal returns, past which you'll get only superficial discussions with CAB members.
• Too few CAB members. On the other hand, too few CAB members increases the risk that you're not really hearing representative requests.
• Skewed samples. Even if you get the right number of CAB members, you might pick too many from a particular vertical, too many of a particular size, or otherwise skew the sample.
• Talking at the customers. Many CAB meetings turn into a marketing campaign, in which the company tries to sell the next release to the CAB members, instead of listening carefully to what the CAB members really want.
• Hearing what you want to hear. I've also seen CAB meetings fail because the company has some strong opinions about the product direction. Development team members are therefore looking for confirmation of the product strategy, and generally tune out information that challenges the roadmap.
• Talking about features, not solutions. CAB meetings can quickly devolve into a prioritization exercise for the Big Honkin' Spreadsheet Of Features. That's a big mistake, since the CAB is a critical source of insight into the business problems customers are trying to address, and the necessary component of the solutions needed to address them. Features are details that need to fit into the solution, which the CAB members are usually eager to discuss.