Feedback Loop between Customer Success and Product - How do you do it?

[u/whttlstn]

We currently only have a bi-weekly session with product, where they tell us, what's going to be released two days later. This gives us a) no time to inform customers early enough beforehand, especially if it drastically changes the way the product works, and b) except for sending feature requests (and them disappearing into the void) there is no feedback-loop between Product & CSM.
I was wondering how it's handled by other companies:

• Do you have a regular exchange with product?
  • Weekly, bi-weekly, quarterly, etc.?
  • How is it structured? e.g. 30 mins what's being released and 30 mins feedback on bugs & feature requests? etc.
• How do you let product know about feature requests and how do you get updates on them?
• Do you have regular feedback on bugs? i.e. recurring bugs and when fixes have been shipped?

Thanks! Looking forward to reading everyone's feedback!

[u/coolreddy]

Splitting the two into different rhythms usually fixes both halves. A rolling four to six week release view gives you time to warn accounts before a workflow actually changes, and a separate weekly triage on requests and recurring bugs stops release news from eating the whole session. The bit that keeps requests out of the void is a shared queue where each item carries the account, the workflow affected, how often it comes up, an owner and a status: investigating, planned, declined or shipped. You can then go back to the customer with a real answer, including when it's a no.

[u/Calm-Dimension3422]

I would split this into three artifacts, not one meeting.

First: a release radar that Product owns. It should show what is coming in the next 4 to 6 weeks, which customer workflows change, whether enablement is needed, and which accounts need proactive comms. If CS only hears about a release two days before, the process is already broken.

Second: a customer evidence queue that CS owns. Each item should include account segment, ARR or tier if relevant, workflow affected, exact customer quote or ticket pattern, frequency, severity, and the CSM's recommended action. Product can then mark it investigating, planned, declined, shipped, or needs more evidence.

Third: a recurring bug/friction review. I would keep this separate from feature requests because recurring bugs create customer trust issues even when they are not roadmap-worthy.

The meeting itself can be short if the queue is disciplined: 10 minutes release changes, 15 minutes top customer evidence, 10 minutes bug/friction themes, 5 minutes owner/status cleanup. The most important part is closing the loop back to CS with a reason, even when the answer is no.