Prepare a useful customer advisory discussion
For hosts and product partners planning an external customer advisory session. This fictional Northstar Works example explores how product teams can make account handoffs clearer; it illustrates a discussion method, not a claim about real customers.
Set the learning objectives
Keep the session focused on what the team needs to understand, not on securing agreement to a solution.
Locate the handoff friction
Learn where context is lost when an account moves between teams.
- Ask which information participants had to repeat.
- Notice where ownership or next steps became unclear.
Understand what useful context looks like
Explore which details help the next team act without making the customer start over.
- Ask what the receiving team needed to know.
- Separate essential context from information that was merely available.
Identify unanswered questions
Capture what the team still needs to learn before proposing changes.
- Record conflicting experiences as separate perspectives.
- Do not treat one example as proof of a universal pattern.
Keep learning separate from decision-making
Use the session to: hear specific experiences, understand the context behind them, and identify questions for follow-up.
Do not use the discussion to: promise a product change, announce a delivery date, or imply that participants are approving a decision. The host summarizes what was heard; accountable product and business roles consider any next steps through their established decision process.
Customer advisory discussions are external research. They are distinct from employee listening sessions, which gather perspectives from employees about their own work.
Prepare participants
Share these three requests in the invitation or pre-read.
-
1
Review the discussion topics
Read the session goal and the areas the group will explore: handoff context, repeated explanations, and unclear next steps.
-
2
Bring one recent example
Choose a specific account handoff you can describe without sharing confidential information that is not appropriate for the discussion.
-
3
Start with what happened
Describe the situation and its effect before suggesting a feature or process change. The host can then ask what would have made the experience clearer.
Illustrative 60-minute discussion agenda
A reusable reference sequence, not a live schedule or work queue. The host may adjust the allocation to fit the group while protecting time for participant examples and a clear close.
| Time | Activity | Facilitator intent |
|---|---|---|
| 0–5 min | Welcome and scope | State the learning goal, how notes will be summarized, and that the session does not commit the organization to a decision. |
| 5–12 min | Participant context | Invite each participant to briefly describe their role in the handoff experience. |
| 12–27 min | Recent examples | Ask what happened, where information was repeated or missing, and what the participant needed next. |
| 27–42 min | Explore useful context | Compare what the sending team knew with what the receiving team needed to continue the work. |
| 42–52 min | Test understanding | Reflect back the themes and ask participants what is missing or does not fit their experience. |
| 52–60 min | Close and explain follow-through | Summarize what was heard, name the role that will consolidate themes, and explain when participants can expect a summary. |
Facilitate for specific experience, not agreement
Use open prompts, then follow the participant's example.
“What was happening when the account moved to another team? What information did you have to explain again?”
“What did the next person need to know to continue the conversation? How did you discover that?”
“What became harder or slower for you because that context was not available?” Ask for the observable effect rather than assuming one.
“Can you walk me through the last time that happened?” Follow with “What would have helped at that point?”
Participant: “I had to explain the account history again.” Leading response: “Would an automatic handoff summary fix that?” More useful follow-up: “Which part of the history did you repeat, and what did the next team need to do with it?” The neutral question clarifies the need without steering the participant toward a feature.
Close the feedback loop
Before the session ends, reflect back the themes in plain language and invite corrections. Distinguish a participant's direct experience from the host's interpretation, and keep differing experiences visible rather than forcing a single conclusion.
Afterward, the host organizes notes by theme and records the accountable role for each follow-up question. For example: Theme: account context is repeated during handoff. Next step: Product Operations consolidates examples for review with the relevant product partners. Participant update: share a summary of themes and open questions after that review. This records coordination, not an approved product decision or delivery commitment.
Tell participants what will be shared back and the communication point they can expect. If timing is not yet agreed, say that the host will provide an update when the review is complete rather than inventing a date. Business Operations owns this fictional example. Send a correction to the session host, who can bring it to Business Operations through the established review route.