Two questions from readers triggered this post:
"What is your opinion of the effectiveness of Client Advisory Groups, and do you think that PMs should organize and facilitate them?"
"Assuming you have an existing CAG, how do extract useful feedback and integrate it with the development process? A ‘rate this feature’ tool? Something all together better?"
Awesome questions. But first, let me go on record. I LOVE Client/Customer Advisory Groups, provided they are done right. Customer Advisory Groups can get you WICKED AWESOME unvarnished information about:
- The actual BUSINESS problems that your customers are facing now and in the future
- How customers view your products' approach to those problems
- The market and technology trends your customers sees and what their effects might be
- How the market views you versus your competitors
Further, if the CAG goes well, you have an unparalleled opportunity to build real relationships with actual customer decision makers. Play your cards right and make friends, and you'll leave with relationships with a handful of customers you can call directly -- to get impromptu reaction to your product strategy, product feedback, and even competitive information.
Developing these direct customer relationships is ESSENTIAL for a product manager. Because you need to find out what REALLY turns your customers on. Without your own direct relationships, you have to rely on sales reps to setup and supervise all your customer conversations. And that's like having your dorky Dad chaperon you on your hot dates -- no fun, kind of embarrassing, and no one gets what they really want out of the interaction.
Alas, Customer Advisory Groups are often done wrong. They turn into multi-hour bitch-n'-moan sessions where each customer lists all the low-level enhancements (and bugs even) that they already filed with Tech Support. None of the above questions are answered, and none of the right relationships develop -- wasting the time of all involved.
So, how do you do a Client Advisory Group RIGHT?
There's a lot of magic, but the biggest thing is getting the RIGHT people there.
Who are the RIGHT people? Usually a higher level person than a PM might normally get to talk to, and definitely higher up than those Tech Support talks to. The RIGHT people are those who OWN the business problems your product solves; they write the big checks and are responsible for actual business results.
So, for example, assume your customer runs all their call centers using your product. Well, try to get the customer's Sr. VP of Customer Service to attend, plus maybe the main tech influencer -- often the CIO or CTO.
Who are the WRONG people? The software engineers who don't like the wording of particular error messages. The system administrators who are primarily concerned with automating things they can do perfectly well via the interface. The content developers. The customer's QA guy. (See footnote 1).
Um, Problem. I can't get any of the RIGHT people to attend.
Yes, it is VERY difficult to get the real decision makers to attend your little Customer Advisory Group. They are very busy people and very important to their companies. Even if one agrees to attend, the chance of him/her bailing out at the last minute is > 50%. These folks will be VERY tempted to delegate this to the more technical, lower-level members of their team -- the WRONG people. And then all is lost.
So you gotta make attending your Customer Advisory Group a SWEET deal. You gotta make these high level folks want to attend desperately, enough that they'll actually keep their schedule free.
So repeat after me:
Location is everything: If your typical sale has a multi-million dollar price tag, your decision makers are C-level business-side execs. Better go for Pebble Beach or a high-end resort in Napa Valley, or something similar for your locale. But if your product goes for a few thousand bucks, the local Marriott might do. You get the idea. Whatever you do, don't cheap out and make them buy their own food/drinks or eat rubber chicken on a stick.
A good excuse to attend: Your target attendee will catch flak for going on a vendor-sponsored boondoggle to a vacation locale unless you provide a way to justify attending to his/her boss and shareholders.
Best Bet: Have a topical presentation by a well-known, "impartial" outsider. Preferably a charismatic author of a best-selling business book that somehow relates to the problems your software solves. Second choice is an "honest broker" presentation by an industry analyst, or maybe a former exec at a well-known, admired company. Last choice: a professor. Please, let her at least have tenure. Also, you might want to have the outsider stick around to moderate some of the discussion.
Oh yeah, if your company has a rock star CEO/Guru (i.e. Ellison, Andreesen, ...) try to at least get a meet-and-greet.
Agenda: Two days with plenty of breaks, a cocktail hour and an awesome dinner. Include the following sessions:
- The thought-provoking presentation by the outsider (see above), preferably related to the problems your product solves
- A moderated discussion on the general business trends and strategic issues customers see and what it means to them
- A product discussion that links the trends/problems to potential product directions.
- Plenty of time to facilitate networking among the attendees. Help them break the ice and get to know each other.
Who Attends: 4-5 of your company execs and product management leaders. Have key Engineering directors/VPs and junior PMs attend relevant parts, but they must sit quietly in the back of the room. (NO banging away on laptops).
Salespeople stay away or shut the heck up.
What Product Managers Should Do: Milk this session for all its worth. PREPARE. Big Time. During breaks, socialize with the attendees as often as possible without annoying them. (Which is hard if you have a crabby personality, so make sure you drink your morning coffee first.)
More Specifics on the Product Session:
Product Management should design and facilitate the Product Session. And NO, I'm not going to tell you exactly how to structure the Product session. Deal with it. Your approach should vary anyway, depending on the burning questions you have. The key is to get the customers ENGAGED and learning from each other -- Interactivity! That's what makes them happy and will get them to come back next year.
OK, a hint. DON'T DO THIS: Each customer gets up, gives a presentation about how they use the product and the enhancements they want to see. This will bore the bahjeezus out of everyone, the RIGHT people will decide then and there not to come next year, and -- trust me -- Tech Support already has this entire list anyway.
OK, Yet Another Hint. I've had lots of success with workshop-style exercises that involve walking around the room and pasting sticky notes to flip charts -- an artifact from my days as a management consultant at one of those big-dealio strategy consulting firms. Read Luke Hohmann's book, Innovation Games: Creating Breakthrough Products Through Collaborative Play to get some ideas.
Who Organizes the CAG?
Get an admin assistant or Marketing's event planning people to handle the logistics. PM should recruit the attendees with the help of Sales -- if you leave the invitation list up to another function, more than likely you will end up with the WRONG people in attendance. Also, PM should set the agenda, provide guidance to the outside speaker/moderator, and design the above-described product session.
But WAIT there's more.
There's a lot more to say on how to get the most out of Customer Advisory Councils. Lots. I could go on and on, but alas my hands are cramping up. So, here are a few other links you might find interesting. Note that these authors don't agree with me on every point (idiots!), but they are still worth reading.
- On Rocket Watcher (April Dunford): 10 Rules for Running A Customer Advisory Council
- Pragmatic Marketing (Steve Johnson): Running Customer Advisory Boards
Footnote 1: These people have valuable feedback, but there should be another venue for them: USER GROUPS and your usual customer meetings and conference calls.