Not sure if you use ideation yet, but it could be part of a solution. We have Community as a “Product Category” for our Ideas module and encourage users to submit community ideas and requests, including events, as ideas. 

It helps shift one person’s pet peeve into a more democratic process for upvoting and prioritizing what’s really important. However, i’ll be honest that it doesn’t get a ton of use for community and other non-product ideas. 

For scheduling, I would prioritize a time that works for most, but especially the product side (obviously) and the instigator. If there are some others that are positively impacting the productivity of the conversation, it’d be good to have them there to balance. 

From there, I’d recommend replacing the Google Doc with an open thread of questions they have or feedback they want to do discuss: “Open Thread: Topics for Product Event on ______.” 

1. You want them to use your community, not google docs. It’s a valuable opportunity to reinforce adoption of the new community and get used to the UX and other features. Encourage others to like the questions and topics they agree with (akin to upvoting ideas)
2. It gives you and your colleagues visibility into what the audience will want to discuss and time to prepare. 

Private group is a great idea as well. But you also want to encourage others to engaging in this open collaboration approach to community. Perhaps reinforce the Open Thread concept and incentivize things a bit: “To keep the conversation productive, we are going to limit the audience to X. We’ll share back question answers and takeaways from the conversation. Invites to this feedback session will go to those whose questions and comments in the thread below receive the most likes by __________.”

Thanks again @DannyPancratz  - voice of reason! 
Announcing we’re limiting the audience to X on the open thread is a good idea, rather than moving it to a private group discussion.
I agree GDocs is not helpful in this situation so will encourage we keep things in the community.
Also, getting the cheerleaders in to balance what could be a negative discussion I will do that too.
 

This feels to me like it’s less a question about the logistics of a customer roundtable with your product team, and more about how your company wants to work with an unhappy customer. That’s a Customer Success question, not a Community Management question. Just because a customer rallies support doesn’t mean that they get to demand whatever feedback forum they want. It also doesn’t mean that providing the feedback would actually make them feel much better, especially if their need is misaligned with the product team’s priorities, or if the product team already has absolutely all of the insight that they would value about the feature. And it sure wouldn’t make your colleagues feel great about community if they felt that customers could use it at any moment to derail their lives.

It seems fair that this customer has important feedback and needs to be heard. All the rest is just what they’re grasping at to try to achieve it. Respect their need and their attempt, but work with Product and CS leadership to design how the company will make a dissatisfied customer be and feel genuinely heard, and how the company is going to talk to customers about this (apparently) sub-par feature. Plus, there’s an immediate-term need for a senior CS or Product person to lavish your rabblerouser with attention and care, helping them to slowly unwind from being SO CRAZY FIRED UP.

Hey @seth  Thanks for putting your thoughts down here. This absolutely does need a precedence being set and agree that we can’t be bowing to every customer demand for an audience with our product team.
This has highlighted that I need more detailed guidelines around how these sessions take place - of which a discussion does need to happen with my product and customer success stakeholders too.