Sorry to the “Sorry, but this feature/bug isn't going to get built/resolved.” So, how do you build a better working relationship with customer success to deliver the right product?
Thanks Shaw for the great article and summary regarding customer success and their motivations!
Another approach for a product manager to have a good working relationship with customer success (and any other internal stakeholder group - sales, etc) is something we've adopted called "product stakeholders".
One person from cust success is designated the "product stakeholder" - the expectation is that they meet with the PM for 30 minutes each week to:
1) Give feedback on recent releases
2) Weigh-in on upcoming releases
3) Feed back anything else that's bubbling up from their team
4) Help the PM answer ad-hoc questions related to their group ("does cust success see a lot of issue x?", etc)
They are also viewed as their group's resident expert for anything related to that product area - so they 1) help to take "inbound question" load off the PM, 2) act as a signal filter/ amplifier for
feedback to the PM, and 3) can more effectively announce releases and also pulse their teams with questions (since they know what effective comms channels are, who is trustworthy in their group, etc).
This role typically is fulfilled by an IC (not a manager), and takes 5% of someone's time. In return, they get some exposure to product management and also gain a little soft influence over product development.
With this role in-place, we always eliminate a) the stakeholder group being unpleasantly surprised by a releases [since the forced weekly meetings ensure no surprises], b) releases not taking the group's feedback into account [again, the weekly meetings help], and c) the group feeling un-heard [the product stakeholder takes the group's most important feedback and can force those conversations during the weekly calls].
Lastly, will note that "product stakeholders" ***always*** seem to work better than feedback boards, suggestion inboxes, etc... the invariant pattern with these is that there's a surge of interest from folks initially and then it quickly tapers off when the feedback can't be actioned quickly enough to maintain interest (and the quality of the feedback is bad, and the effort it takes to comb through is high, and and and). If there is a stakeholder group that feels they aren't
being heard, we always implement a "product stakeholder" - seems to work pretty well!
Love the practical and detailed example. Not only do you go into the details, but you help paint a picture for how someone else could make this "product stakeholder" work. Thanks Geoffrey
Thanks Shaw for the great article and summary regarding customer success and their motivations!
Another approach for a product manager to have a good working relationship with customer success (and any other internal stakeholder group - sales, etc) is something we've adopted called "product stakeholders".
One person from cust success is designated the "product stakeholder" - the expectation is that they meet with the PM for 30 minutes each week to:
1) Give feedback on recent releases
2) Weigh-in on upcoming releases
3) Feed back anything else that's bubbling up from their team
4) Help the PM answer ad-hoc questions related to their group ("does cust success see a lot of issue x?", etc)
They are also viewed as their group's resident expert for anything related to that product area - so they 1) help to take "inbound question" load off the PM, 2) act as a signal filter/ amplifier for
feedback to the PM, and 3) can more effectively announce releases and also pulse their teams with questions (since they know what effective comms channels are, who is trustworthy in their group, etc).
This role typically is fulfilled by an IC (not a manager), and takes 5% of someone's time. In return, they get some exposure to product management and also gain a little soft influence over product development.
With this role in-place, we always eliminate a) the stakeholder group being unpleasantly surprised by a releases [since the forced weekly meetings ensure no surprises], b) releases not taking the group's feedback into account [again, the weekly meetings help], and c) the group feeling un-heard [the product stakeholder takes the group's most important feedback and can force those conversations during the weekly calls].
Lastly, will note that "product stakeholders" ***always*** seem to work better than feedback boards, suggestion inboxes, etc... the invariant pattern with these is that there's a surge of interest from folks initially and then it quickly tapers off when the feedback can't be actioned quickly enough to maintain interest (and the quality of the feedback is bad, and the effort it takes to comb through is high, and and and). If there is a stakeholder group that feels they aren't
being heard, we always implement a "product stakeholder" - seems to work pretty well!
Love the practical and detailed example. Not only do you go into the details, but you help paint a picture for how someone else could make this "product stakeholder" work. Thanks Geoffrey