If your product management group doesn't have a Customer Advisory Board (CAB), first things first, you need to build one. These boards are some of the most valuable feedback assets you can have.
Pragmatic Marketing defines a CAB as a customer group that meets periodically to offer product insights. This is only partially true. These groups can function at much higher levels of frequency than on just a periodic basis. The key is to do so in a meaningful manner.
I like to treat my CABs as extensions of our product management group; I think of them as deputized members of our team that are always ready and willing to offer feedback and participate in product development. These are folks who want to be involved in your process, so it is imperative that they be included to a degree that is meaningful to them.
Here's what you need:
1). Customer List
2). Organize the Group Around Characteristics and Demographics
3). Leveraging the Boards
The first point is fairly explanatory. You likely have a CRM that contains customer data such as contact info, years with the product, patch numbers, version, etc. Contact your board candidates, make the expectations clear, gain consent, and then compile them into a workable board contact list.
The second point, how you will organize your board, is most important. Sometimes it's acceptable to have a general board that you can lob general questions at. But that's meh. Most times, however, it's deeply beneficial to have a board for a specific purpose. In our case, I have created boards comprised of individuals representing agencies of varying sizes from small to large, individuals in technical or non-technical positions, and varying combinations of those demographics. In so doing, I have created an array of demographics that I can tap for diverse feedback.
In a previous post, I advocated for the "Who's Who" consideration when developing survey projects. In a previous engagement project, we had two lists of survey respondents to which we would send the survey: the highly technical respondents and the non-technical respondents. The data we received from both sides couldn't have been more different and telling. The same practice should be used when building your CABs. The key here is to not allow for homogenous demographics that comprise your boards.
Third point: Last year, we were working on a feature that we felt may have more of a negative impact on larger agencies than smaller. In order to validate that presumption and design it accurately, I group messaged (I highly recommend Slack for this) our board that represented larger, high-volume (the higher the volume of the agency, the more likely they were to be impacted by the change) agencies and queried them with a prototype and sentiment questions. Surprisingly, they were not worried about how that change would impact their processes and we moved forward with clear minds. A year later, no complaints.
While this is not a significant example, it works to show how these boards function. The ability we had to contact them without a formal process also enabled us to receive rapid, actionable feedback rather than waiting on a survey period to end or a focus group date.
The second and third points, in a nutshell, stipulate that you ensure your CAB organization and execution align with your product strategy. Without that alignment in mind, the CAB isn't necessarily worthless, but it will not function in a way that would otherwise be productive if it was initially aligned correctly.
Additional Consideration: Your boards will require maintenance as turnover occurs. Don't let them fall derelict because doing so undermines their utility which is ready access. Keep them active, give them material to work with often, and their data [feedback] will pay dividends in customer satisfaction.
Some other items I've learned from our boards: they make for great beta candidates. The beta process will feel like an organic extension of their CAB responsibilities. Because you've trained them to provide frequent, candid feedback, leveraging them for beta opportunities sets you up for a successful and smooth beta process that would otherwise be fairly risky by employing another untrained, unfamiliar group.
Additionally, these boards tend to act as emissaries and advocates for your product. During our annual user conference last year, we encountered a relatively new customer who was having some significant difficulties reconciling their policies and procedures with one aspect of our software. Knowing this customer would be in attendance and prior to the conference, I reached out to a "sage" member of one of our larger boards and asked that they join us - while at the conference themselves - for a strategy meeting with this new customer. I knew that our sage customer had battened down a solid process for using our software with their own cumbersome and complex policies and procedures, so I felt it'd be a good fit for the two to meet. More proof that CABs are not only an intimate part of your product management strategy, but can also be part of your customer service/training paradigm.
In short, devote time to creating, organizing, leveraging, and maintaining CABs - the benefits of doing so will be readily apparent in your product design and success.
Comments