A customer advisory board is a recurring group of customers who help you understand important problems and make better-informed product or business decisions. Start with a decision you genuinely need help with, invite people who experience that problem, and show them what happened after their input.
Do not start with a prestigious member list or a roadmap presentation. Start with this sentence: “We need to decide [decision], and customer experience could change our answer because [uncertainty].” The worksheets below turn that sentence into a participation brief, a useful meeting and a feedback-to-decision ledger.
Choose the job before creating a board
A customer advisory board, often shortened to CAB, is not the same as hiring a fundraising advisor, appointing a corporate director or finding customer references for a sales call. Its job is to learn from customers' experience over time.
CRV's guide to customer advisory boards describes an ongoing customer input program, with concrete questions and follow-through on decisions. That is more useful than treating the board as a one-off event. It does not mean every team needs the same member count, executive sponsor or meeting schedule.
Choose the smallest research format that fits:
- One unclear customer problem: an individual discovery interview may be enough.
- A specific prototype or task: a focused usability session may answer the question more directly.
- Repeated strategic questions across customer contexts: a recurring advisory group may be useful.
- A current bug or service incident: use the support or account escalation process, not an advisory-board meeting.
Keep future product feedback separate from help with today's product. Pendo's own feedback policy makes that distinction and explains how feedback informs research rather than guaranteeing development. Use the same clarity in your invitation: the board provides input, not a promise that each suggestion will ship.
Frame a decision customers can improve
“Tell us what features you want” creates a long list without explaining the work behind it. Frame a choice and the uncertainty behind the choice instead.
| Weak question | More useful decision question | Evidence to look for |
|---|---|---|
| What should we build? | Which part of preparing an account review creates the most rework? | A recent example, people involved and the steps repeated. |
| Would you like a dashboard? | What decision are you unable to make with the information you can see today? | The actual decision and the information missing or arriving too late. |
| Is our roadmap good? | What would have to change for this proposed direction to be useful in your workflow? | A condition, constraint or counterexample that could change the plan. |
Pick a decision owner who can explain the tradeoff and return with an answer. The program coordinator can arrange the meeting without owning every product decision. Separate those roles if needed.
Write down what is still open. If a decision is already fixed, tell members you are explaining it or learning about implementation, not asking them to influence an outcome that cannot change.
Choose members for perspective, not prestige
List the customer situations relevant to the decision. A daily user, an administrator and the person accountable for the business outcome may describe different problems. A happy power user alone cannot speak for a new customer struggling to adopt the product.
Create a coverage map before invitations:
| Perspective needed | Why it matters for this decision | Missing perspective or limit |
|---|---|---|
| [People who perform the task] | [They can show the steps and workarounds.] | [Who is absent?] |
| [People accountable for the outcome] | [They can explain the decision and constraints.] | [Whose goals differ?] |
| [People who manage access or rollout] | [They can explain implementation restrictions.] | [What cannot this group verify?] |
| [A relevant underserved customer context] | [It may expose a failure hidden by enthusiastic users.] | [Does the invitation genuinely fit their experience?] |
This map does not turn a small invited group into a representative market sample. State what the group can and cannot tell you. If all participants use the same workflow, do not present their preferences as evidence about every customer segment.
Ask people whether participation fits their role, time and information-sharing restrictions. Do not make advisory participation a condition of ordinary support or assume a customer reference permission covers a board discussion.
Write a short participation brief
Before someone accepts, explain the purpose, likely preparation, meeting format, information boundaries and follow-up. The brief below is an operating outline, not a legal agreement or confidentiality template.
Purpose: We are seeking customer experience to inform [specific decisions].
Why your perspective matters: [relevant work or responsibility].
Participation: [proposed format, timing and preparation].
Questions we want to explore: [current questions and examples].
What is not included: Support resolution, a sales commitment or a promise to ship suggestions.
Information boundaries: Share only material you are authorized to discuss.
Recording and quotation: [explain the proposed practice and obtain the required permission].
Follow-through: We will explain [decisions, further research or deferrals] through [channel].
Program contact: [coordinator and decision owner].
Questions or constraints: [how members can raise participation concerns].Review confidentiality, recording, incentives and quotation permissions with the appropriate owner. An informal invitation should not invent legal protections. If members cannot discuss certain material in a group, offer a suitable private research route or change the question.
Worked example: two feature requests, one unresolved decision
Illustrative example: A fictional account-management software team is deciding how to improve weekly account reviews. One operations participant asks for an easier CSV export. A finance participant asks for tighter controls on exports. A feature-vote exercise would make these look like opposing camps.
The coordinator asks each person to walk through a recent review. Operations exports records to combine updates that arrive in separate places. Finance worries that a broad export contains information outside the review's scope. The group has identified a workflow and a control problem, not proved that an unrestricted export is the right feature.
| Input | Evidence state | Underlying job or constraint | Decision and next check |
|---|---|---|---|
| “Make the CSV export easier.” | One participant describes manually combining account updates before a weekly review. | Prepare a complete review without repeated copying. | Map the review's required information and observe an authorized example before choosing a solution. |
| “Restrict exports more.” | One participant reports concern about sharing information beyond the review group. No incident is established. | Keep review information within the appropriate audience. | Ask the responsible access/security owner to review requirements; do not infer an incident or promise a control. |
| A scoped review view might help both jobs. | Team hypothesis, not a customer-confirmed requirement or shipped feature. | Combine relevant context without unnecessary disclosure. | Prepare a prototype for authorized testing, or explain why another direction was chosen. |
The product owner does not tell members that the board “approved the new review view.” Two accounts are not a market-wide mandate. The owner records the hypothesis, the missing perspective and the evidence needed before making the product choice.
The follow-up could say: “Your examples showed that the review requires information from several places and has audience restrictions. We are checking those requirements before choosing an export or review-view change. We have not committed a feature or release date.” That closes the loop without pretending the decision is finished.
Run a meeting around examples and choices
Send the question and relevant context beforehand. Ask members for an example they can discuss without exposing confidential records. Do not require a polished presentation; a description of a recent task can be more useful.
Here is an illustrative 60-minute agenda. Change the timing to fit the question and participation constraints.
- Minutes 0–5: Confirm the purpose, participation boundaries and decision still open.
- Minutes 5–20: Hear recent examples of the task, including where the process became difficult.
- Minutes 20–40: Explore differences, tradeoffs and counterexamples. Distinguish customer experience from the team's interpretation.
- Minutes 40–50: Test what further evidence or a useful experiment would need to show.
- Minutes 50–60: Recap what was heard, correct misunderstandings and name the next owner and update.
Do not spend the discussion defending the current roadmap. If a participant raises an urgent account issue, acknowledge it and route it to a responsible owner outside the strategic discussion. Record the follow-up without turning the meeting into an unplanned support queue.
Copy the feedback-to-decision ledger
Keep each input separate from the team's interpretation. This is the working record that makes a recurring program more than a collection of meeting notes.
| Decision question | Customer input and source | Evidence limits | Interpretation or hypothesis | Owner and next step | Return to members |
|---|---|---|---|---|---|
| [Choice still open] | [Authorized example; source and date] | [Reported, observed or unknown; missing perspectives] | [What the team thinks this means] | [Accepted owner; research, decide or defer] | [What was explained and when] |
| [Competing choice or constraint] | [Separate input, not a blended quote] | [What this does not establish] | [Alternative explanation] | [Evidence that would change the answer] | [Update due or delivered] |
Use clear decision states: researching, testing, decided, deferred or declined. “On the list” does not tell a member whether you are learning, building or politely saying no. When you decline an idea, explain the relevant tradeoff without exposing another customer's private information.
Measure whether the program changes decisions
Track a few operational questions first: Did the discussion change a decision or identify a missing assumption? Did the owner follow up? Did members understand what happened to their input? Which perspectives are still absent?
If you track retention, expansion or referrals among members, keep that separate from a claim that the board caused those outcomes. Members may have been selected because they were already engaged. An invited cohort and other customers are not automatically comparable.
A useful review might report: “We brought three open decisions to the group, changed one research plan, deferred one choice pending an access review and returned an explanation on all three.” These are illustrative program measures, not a Finta customer result or a required quota.
Fix the common failure modes
| What happens | What to change |
|---|---|
| The meeting becomes a product demo. | Return to the unresolved customer decision and ask for a concrete recent example. |
| The loudest member becomes the roadmap. | Separate intensity from evidence; seek missing contexts and record counterexamples. |
| Every suggestion is described as a commitment. | Review the language of the recap and distinguish research, decisions and approved delivery. |
| Members repeat the same feedback without an update. | Assign a decision owner and explain what changed, what did not and why. |
| The group shares material others should not see. | Stop that discussion and use an approved channel or a safer example. Review the participation plan. |
Before the next session, check that you have a real open question, relevant perspectives, safe participation boundaries, a decision owner and a way to return the answer. If one is missing, repair that part before adding more members or meetings.
For earlier one-to-one learning, use the customer discovery interview worksheet. For interpreting broader customer signals, use the product-market-fit evidence checklist. When a customer is being asked to help another buyer evaluate your product, use a separate customer reference permission workflow.
This is operational education, not legal, tax or accounting advice. We are not lawyers. Ask your attorney or accountant to review participation, confidentiality, incentive or accounting requirements that apply to your situation.