How to Quantify the Value of Product Feedback and Feature Requests Effectively

Beth S. · 2026-06-23T11:14:17.295Z

Hey, this isn't a Tightknit-specific question, but figured I would post here anyway and ask the question. Is anyone quantifying the value of product feedback/feature requests, and if so, how are you approaching it? We improved the intake process for product feedback in our Slack community and have been receiving more feedback as a result. I'd love to figure out a way to tie value to this. Would it be in the associated accounts/users renewing, an estimated value of customers using these new features, further adoption of said features, something else? This isn't something I've heard many people talking about so curious if/how people are thinking about this. Thanks!

How to Quantify the Value of Product Feedback and Feature Requests Effectively | Tightknit Community

12 comments

· Sorted by Oldest

Joel P.
·
·
Starting points:
Is there a list of strategic accounts you could map feedback to through?
Using the feedback giver as customer proof when the update is live?
Tie them back ARR and/or consumption rates
Explore it by Geos
1
Max P.
·
·
I'd probably recommend syncing with your product team and seeing what their goals are with this and tying the two together. In the past we had specific metrics assigned to how many product features were implemented, adoption rates, etc. I think showing how many community requested to product implemented numbers would be cool and show the value that these requests bring
👍1
Beth S.
·
·
Thanks pals! We've done some mini CAB-like feedback groups and we have a new CPO who is pushing for more of this type of programming in the community, with each PM owning a focus area. We're also looking into a more formalized early access program VS doing one-off recruitment every time for alpha/beta participants. I think this might align with what you're saying, Max?
1
Joel P.
·
·
Working on the early access program now for mine!
Beth S.
·
·
That's great!
Max P.
·
·
Yes definitely, I think having an early access program would be awesome!
1
Joel P.
·
·
10000%
Patrick M.
·
·
later to this early morning party, but more feedback = more people watching, means more people see how your team is working to make the product better. that should definitely show up in NPS scores imho.
Joel P.
·
·
If you do a community survey, questions and scores around:
Future of the product
Product feedback is valued and actioned on
🙌1
Beth S.
·
·
I've definitely heard a lot of anecdotal feedback that people appreciate seeing our product team in Slack, talking to them directly about feedback, that we like to build alongside our users, etc. I can probably do a better job surfacing this stuff more formally and figuring out ways to quantify it through NPS, adoption, etc like you guys mentioned
3
Patrick M.
·
·
Don’t beat yourself up, but also never underestimate the power of morale toward what you’re building. Getting a problem solved through a support ticket is like level 1; if you can show that people’s ideas and needs are being met by the evolution of the product, you have reached level 10.
❤️1
Brian K.
·
·
Also, a feedback program usually generates way more feedback than the product team can/will act on, depending upon goals, scope and roadmap. 1) if someone proposes something the team is already working on, you can just accept it, don't need to disclose the WIP, makes everybody happy and 2) set expectations with your feedback status items, it's okay to have one for "this doesn't match our current roadmap or thinking." 3) great if you can attach people who vote on an idea to auto-magically be notified of status updates. As you all have noted, for feedback that is implemented, being overly communicative on these to show that strong link between customers and product is gold. Tracking usage of those new features, or blocking issues that go away in support tickets, etc. are good validators.

Joel P.
·
·
Starting points:
Is there a list of strategic accounts you could map feedback to through?
Using the feedback giver as customer proof when the update is live?
Tie them back ARR and/or consumption rates
Explore it by Geos
1
Max P.
·
·
I'd probably recommend syncing with your product team and seeing what their goals are with this and tying the two together. In the past we had specific metrics assigned to how many product features were implemented, adoption rates, etc. I think showing how many community requested to product implemented numbers would be cool and show the value that these requests bring
👍1
Beth S.
·
·
Thanks pals! We've done some mini CAB-like feedback groups and we have a new CPO who is pushing for more of this type of programming in the community, with each PM owning a focus area. We're also looking into a more formalized early access program VS doing one-off recruitment every time for alpha/beta participants. I think this might align with what you're saying, Max?
1
Joel P.
·
·
Working on the early access program now for mine!
Beth S.
·
·
That's great!
Max P.
·
·
Yes definitely, I think having an early access program would be awesome!
1
Joel P.
·
·
10000%
Patrick M.
·
·
later to this early morning party, but more feedback = more people watching, means more people see how your team is working to make the product better. that should definitely show up in NPS scores imho.
Joel P.
·
·
If you do a community survey, questions and scores around:
Future of the product
Product feedback is valued and actioned on
🙌1
Beth S.
·
·
I've definitely heard a lot of anecdotal feedback that people appreciate seeing our product team in Slack, talking to them directly about feedback, that we like to build alongside our users, etc. I can probably do a better job surfacing this stuff more formally and figuring out ways to quantify it through NPS, adoption, etc like you guys mentioned
3
Patrick M.
·
·
Don’t beat yourself up, but also never underestimate the power of morale toward what you’re building. Getting a problem solved through a support ticket is like level 1; if you can show that people’s ideas and needs are being met by the evolution of the product, you have reached level 10.
❤️1
Brian K.
·
·
Also, a feedback program usually generates way more feedback than the product team can/will act on, depending upon goals, scope and roadmap. 1) if someone proposes something the team is already working on, you can just accept it, don't need to disclose the WIP, makes everybody happy and 2) set expectations with your feedback status items, it's okay to have one for "this doesn't match our current roadmap or thinking." 3) great if you can attach people who vote on an idea to auto-magically be notified of status updates. As you all have noted, for feedback that is implemented, being overly communicative on these to show that strong link between customers and product is gold. Tracking usage of those new features, or blocking issues that go away in support tickets, etc. are good validators.