7 ms·

Managing product requests from customer-facing teams

46 points by brettcvz 7y ago

monkeydust 7y ago
One of the realities of 'software eating the world' is managing client driven requests with finite engineering resource. Forcing sales to prioritise their requests amongst themselves (fight it out) periodically is generally good practice that all product teams should employ although doing this on global scale across multiple regions and products with same pool of engineers can be challenging.
aklemm 7y ago
“ And as the PM, at a minimum you should commit to making some progress on at least one of those top-two issues every quarter or two.” Thinking from the client-facing side, this would HAVE to be progress on BOTH items EVERY quarter or it’s hard to take it seriously. And taking each other seriously can often be part of the problem.
- brettcvz 7y ago
  I haven’t found this to be the case. If needed, you can always surface the constraint of “look, I have N other teams who are giving me their top two requests, in addition to trying to move goals X, Y, Z. I want to support you and move the ball forward on these issues, but I can’t do everything immediately”
bbulkow 7y ago
Brett, i have evolved a different system, and i agree on the difficulty and importance of the problem. Give me a ring, we can have a coffee and discuss.
motohagiography 7y ago
Top two is good. Being transparent with your feature stack ranking is also nice, but consider that everyone's incentives are rarely aligned across sales/eng/product. I'd like to propose a controversial view on this and to understand the tension better. It should be on members of customer facing teams to demonstrate that they are capable of saying "no," before coming to product with a request. Not every time, or even often, but a sales guy recognizing he's losing the sale and only brings in support from product and elsewhere to diffuse the blame for it is the basic sales anti-pattern. I get that for a relationships sake they need to use the "let me speak to my (product)manager" routine to deflect frivolous objections from the customer, but unless I know what you were willing to say "no," to, it's difficult to value what you said yes to. This is why the relationship with salespeople is so critical, as you need to have an empathetic view of that dynamic, but if the sales persons solution to everything is to claim powerlessness and blame others, we need some neutral language to describe that pattern so we don't have to sound it out and re-litigate it every time it happens. The question, "what did you say no to?" seems like a practical filter.
- brettcvz 7y ago
  I hear you - instead of “what did you say no to”, I prefer “would you say <new thing> is a higher priority than <previous thing you said was #1 or #2>?” - it’s much easier for people to evaluate “A or B” tradeoffs than “A or not A” tradeoffs
  - motohagiography 7y ago
    Appreciated. The reason that isn't my first choice is, while it unasks their question by shifting cognitive load back on them, it doesn't build trust by establishing a way of relating. To me this is a really interesting generational communication style question. What I'll admit to criticizing as the Teflon PM approach is a very nuanced skill, but it is about enforcing that boundary instead of establishing a foundation of trust. It's philosophical whether value comes more from the quality of relationships or from individual leverage, and of course that's dynamic, but this underlying tension between what has been problematized as transactional vs. collaborative communication, and whether it actually creates value or rides it out is the defining cultural question of companies today. I really like your blog, and I"m a bit chuffed you've responded directly. So, tactically, yes, "how would you prioritize your request?" disarms their urgency, but to provoke, I'd say it doesn't take the necessary risk or build a relationship that yields value.
dchuk 7y ago
I have a large team of product people, and work with a growing team of sales people. Something I’ve been doing recently that’s really important for this is highlighting to everyone customer facing the difference between client and customer. Clients hire you to work for them on something. Customers buy your product. Said simply, it’s an inverted demand situation. Clients flow requirements to you, customers get features deemed most valuable by product folks. Shit starts to break down horrifically when you treat your customers like clients, the reason being is that you’re not internally dedicating engineering resources to that customer, so you’re mismanaging their expectations for delivery of asks. There’s a whole detailed flow on this I need to complete as a blog post, but understanding and educating on this basic distinction helps a lot.
- brettcvz 7y ago
  “customers get features deemed most valuable by product folk” - perhaps I am misreading the intent here, but this seems like a license for product people to ignore really getting to know the customer problem. Contrary to popular SV wisdom, I believe that most customers really do know what they want, at least most of the time and in broad brushstrokes. Many of the best products I’ve worked on have come from asking customers what they want! See http://brettcvz.com/posts/49-finding-product-ideas-in-new-customer-expecations http://brettcvz.com/posts/49-finding-product-ideas-in-new-cu... for a more detailed write up.
  - dchuk 7y ago
    It's not about what they want typically, it's what they need. Most customers/users aren't incentivized to solve upstream problems for themselves, instead they just need to use the tools they're given to do their job (at least in B2B area). Product people should rarely if ever react directly to WHAT customers ask for, but instead dig in and understand WHY this ask is coming up. Then you'll get to the good stuff. EDIT: For clarity, I fully agree that product people must learn the customer's problems. Just be careful responding to what they ask for when doing so.
    - brettcvz 7y ago
awinter-py 7y ago
Including sales teams in the product process is hard because of the time aspect The worst-case scenario here is to find out that someone has already sold something and now it's screwing up your dev schedule. This becomes a power struggle between sales & product because allowing this will make it the norm, but turning them down can look to non-technical senior management like PMs are directly harming the company and undercutting sales. ICs are also nice + not political savvy, and can be plied and subverted by sales -- 'hey come out with a drink with us' turns into taking on random work. This gets political fast, especially because the power balance between sales and product is usually off -- one or the other is the star and doesn't listen to anybody. Good information flow requires trust, skill and good leadership.
lmeyerov 7y ago
For small teams, this goes to the weekly leadership mtg and VP's 1-1s: CEO/cto or vp eng/prod should be reporting their side, but also asking sales+marketing if they need enablement. For next scales, two models I like are "Tiger teams" (top dev team who can jump onto stuff for pushing a VP Sales picked acct through) and dedicated analysts+devs. I'm skeptical of say A/B testing until you are huge, but stuff like sales/success/marketing automation can hit way earlier.
kareemm 7y ago
> Why set the limit at two requests per team? It seems to strike a good balance - asking teams for a single top priority tends to make teams bundle all issues into one big ask, making it harder to find quick wins to slot into sprints, whereas asking teams for three or more can quickly overwhelm the PM and lets teams off the hook from making as many hard choices. Maybe it's just me, but as a PM I want to hear as much as possible from customers. Asking other teams to prioritize e.g. two requests ensured that I'd be missing potentially valuable customer feedback which made me twitchy. It's not support or sales' job to decide what's important. It IS their job to tell Product what they're hearing a lot of (ideally with minimal disruption of their workflow). But it's Product's job to decide what's important. Not having that information leaves Product (and by extension the business) more in the dark than it should be. Solving this problem is why I built Savio[1] to help support and sales teams quickly send customer feature requests from Intercom, Help Scout, and other tools to their Product team... and for Product to have a sane list with tools to prioritize their features (e.g. "Show me feature sorted by # requests, or cumulative MRR, or from Churned customers"). 1- https://www.savio.io https://www.savio.io
- brettcvz 7y ago
  Totally agree! I use this technique as a complimentary layer to “send all possible feedback my way”. Tactically, we achieve this through having a handful of different “feedback-X” channels for different audiences that people dump feedback into. But over time that can start to feel like a black hole that isn’t listened to, so I like adding this layer on top. Good point though, I can add a clarification to the post.
  - kareemm 7y ago
    > over time that can start to feel like a black hole that isn’t listened to Great point. Definitely need to ensure teammates feel like their feedback is making a difference so they keep sharing it!
- this2shallPass 7y ago
  Totally agree. But isn't finding out clear priorities from sales and other teams, with the context behind it as well, useful as a PM?
erader 7y ago
As a PM that has started my career in Support/Success... I don't think I could ever advocate a strict two-request limit. Customers (and customer teams) are a non-stop firehose of feature requests. It's important for the product team to hear all these requests, mostly so they can be understood. It's tedious work, but I do it with the intention of looking for patterns and having a pulse on the customers. You might be surprised by what you find, especially how many feature requests are actually different solutions to 1 larger problem. My team does this using ProductBoard (https://www.productboard.com/ https://www.productboard.com/) to synthesize all incoming feature requests on a weekly basis. We sit for 30 minutes as a team to go through direct requests, lost sales opps, etc.. This weekly work pays dividends when it comes time to prioritize features for the next quarter/year, etc. Customer teams can feel empowered when they are given the tools/opportunity to prioritize things on their own, but the huge downside is that they feel silenced on a large majority of things they can't tell you (i.e. the "lower" priority" requests). This can really eat away at the morale of customer teams that feel they can't share their customer stories with you. When they hear feature requests from customers that they know are low-priority, it feels horrible to tell a customer it won't even be looked at by Product (it's even worse to lie). I'd recommend a system where all feedback is shared, but only 2-4 feature requests are "voted" for officially by each customer-facing team.
- brettcvz 7y ago
  Totally agree with the “yes and” approach of firehose plus top two - I haven’t had a chance to update the post yet, but responded to similar feedback here: https://news.ycombinator.com/item?id=21971011 https://news.ycombinator.com/item?id=21971011
  - erader 7y ago
    Cool! Another weird thing I've noticed when feature requests are capped for customer teams, is that customer teams will "game" the system. At scale, customer facing ICs will do things to benefit them personally. It's not a bad thing, it's just human. Sales people do what they need to get quota, Support want to keep their ticket backlog down and CSAT high, etc. If you receive all customer facing feedback, you can make the final prioritization call on your own. If requests have been filtered too much before they reach you, the priority must be taken with a grain of salt.
lbotos 7y ago
Hi, Support Engineering Manager here. This is an okay approach. But let's talk about where it breaks down: Bugs. Some premises: - The majority of Support Requests are around bugs or administration. - Product teams are incentivized to ship features. - Bugs are often de-prioritized or "balanced" with feature requests. Solution: Embed an engineer (or build engineers out of support -- who will focus on support problems) and let them fix the bugs that are most important to support (and have full access to pair/partner with greater eng if the bug is gnarly.) This will reduce Product's backlog, and product can then focus on feature requests of which are usually ~15-20% of requests. Let that support engineer Build the tooling needed to make support more efficient. This is often a problem in orgs (getting eng resources for cost-centers) because it's not "product features". This process allows bugfix to circumvent the product planning and prioritization process and ultimately make for a better customer experience (where the bug can be solved quickly.) Product can still get customer feedback and focus on building new features, support solves their problem, and everyone is happier.
- anon73044 7y ago
  >Solution: Embed an engineer (or build engineers out of support -- who will focus on support problems) and let them fix the bugs that are most important to support (and have full access to pair/partner with greater eng if the bug is gnarly.) I suggested that once and Risk said it was a "Segregation of Duties" SOX violation. When asked if Support could prioritize bugs to the Dev teams responsible, I was laughed out of the meeting.
  - lbotos 7y ago
    My understanding is that Support Engineers following CI/CD & Code Review process can't be a "lone ranger" so it follows the spirit of Segregation of Duties. But that laugh out of the meeting is real. I've experienced it too.
- brettcvz 7y ago
  It’s a neat idea! We have an “internal products” team at Clever that is tasked with building tooling for our support team (and all our other teams too!) that makes them more efficient. They are definitely worth the investment, and I’d encourage the approach to other companies. Re. Bugs - I actually really like the “top 2 things” approach for exactly this reason. It’s very illuminating when you as the PM are like “look at all these exciting things we have on the roadmap!” and your support counterpart responds with “my #1 request is that you fix this bug.” This is why I think that the customer facing teams can sometimes be better at doing this prioritization - even with lots of data about the size of a problem and anecdotes the pain, it’s still easy as a PM to not give it the appropriate attention, whereas the support team that lives with the pain will fight for it.
cmhnn 7y ago
Been doing this for while now in the crazy competitive world of cloud and enterprise. At that scale, this recommendation does not work. Customer facing teams are also very different in focus and there are dangers to thinking one is prioritizing a feature vs. fixing an issue depending on the team they are talking to. Some prioritization is of course normal but it is fluid and not simple unless you're just ready to hand off the business and not improve your platform.
Someone1234 7y ago
I'm a really big fan of the concept of UserVoice (no affiliation). Essentially direct the end-users there and let them vote on product features, track them, discuss them, and so on. A lot of organisations are scared of this, because they don't want to be put into the position of saying "no." Which is likely to occur as not all feedback is actionable, even if popular. But saying "no" and explaining WHY is in itself a great relationship building exercise with end users. I'm not saying they will always agree with the decision or explaination, but they will feel closer/more connected. This won't improve the empowerment of Customer Service roles however. Just might make them less of a punching bag for customer feedback that won't go anywhere.
- brettcvz 7y ago
  Do you know anywhere that does this really well in practice? My concern is that it would end up similar to the internal feedback problem where people feel like they submit requests into a queue that never gets worked on. I feel like I know how to solve that problem when there’s a small number of internal stakeholders I can go over and talk to, I’m not sure how one does it at scale with users

46 points by brettcvz 7y ago

One of the realities of 'software eating the world' is managing client driven requests with finite engineering resource. Forcing sales to prioritise their requests amongst themselves (fight it out) periodically is generally good practice that all product teams should employ although doing this on global scale across multiple regions and products with same pool of engineers can be challenging.

aklemm 7y ago

“ And as the PM, at a minimum you should commit to making some progress on at least one of those top-two issues every quarter or two.” Thinking from the client-facing side, this would HAVE to be progress on BOTH items EVERY quarter or it’s hard to take it seriously. And taking each other seriously can often be part of the problem.

brettcvz 7y ago
I haven’t found this to be the case. If needed, you can always surface the constraint of “look, I have N other teams who are giving me their top two requests, in addition to trying to move goals X, Y, Z. I want to support you and move the ball forward on these issues, but I can’t do everything immediately”

bbulkow 7y ago

Brett, i have evolved a different system, and i agree on the difficulty and importance of the problem. Give me a ring, we can have a coffee and discuss.

motohagiography 7y ago

Top two is good. Being transparent with your feature stack ranking is also nice, but consider that everyone's incentives are rarely aligned across sales/eng/product. I'd like to propose a controversial view on this and to understand the tension better. It should be on members of customer facing teams to demonstrate that they are capable of saying "no," before coming to product with a request. Not every time, or even often, but a sales guy recognizing he's losing the sale and only brings in support from product and elsewhere to diffuse the blame for it is the basic sales anti-pattern. I get that for a relationships sake they need to use the "let me speak to my (product)manager" routine to deflect frivolous objections from the customer, but unless I know what you were willing to say "no," to, it's difficult to value what you said yes to. This is why the relationship with salespeople is so critical, as you need to have an empathetic view of that dynamic, but if the sales persons solution to everything is to claim powerlessness and blame others, we need some neutral language to describe that pattern so we don't have to sound it out and re-litigate it every time it happens. The question, "what did you say no to?" seems like a practical filter.

brettcvz 7y ago
I hear you - instead of “what did you say no to”, I prefer “would you say <new thing> is a higher priority than <previous thing you said was #1 or #2>?” - it’s much easier for people to evaluate “A or B” tradeoffs than “A or not A” tradeoffs
- motohagiography 7y ago
  Appreciated. The reason that isn't my first choice is, while it unasks their question by shifting cognitive load back on them, it doesn't build trust by establishing a way of relating. To me this is a really interesting generational communication style question. What I'll admit to criticizing as the Teflon PM approach is a very nuanced skill, but it is about enforcing that boundary instead of establishing a foundation of trust. It's philosophical whether value comes more from the quality of relationships or from individual leverage, and of course that's dynamic, but this underlying tension between what has been problematized as transactional vs. collaborative communication, and whether it actually creates value or rides it out is the defining cultural question of companies today. I really like your blog, and I"m a bit chuffed you've responded directly. So, tactically, yes, "how would you prioritize your request?" disarms their urgency, but to provoke, I'd say it doesn't take the necessary risk or build a relationship that yields value.

dchuk 7y ago

I have a large team of product people, and work with a growing team of sales people. Something I’ve been doing recently that’s really important for this is highlighting to everyone customer facing the difference between client and customer. Clients hire you to work for them on something. Customers buy your product. Said simply, it’s an inverted demand situation. Clients flow requirements to you, customers get features deemed most valuable by product folks. Shit starts to break down horrifically when you treat your customers like clients, the reason being is that you’re not internally dedicating engineering resources to that customer, so you’re mismanaging their expectations for delivery of asks. There’s a whole detailed flow on this I need to complete as a blog post, but understanding and educating on this basic distinction helps a lot.

brettcvz 7y ago
“customers get features deemed most valuable by product folk” - perhaps I am misreading the intent here, but this seems like a license for product people to ignore really getting to know the customer problem. Contrary to popular SV wisdom, I believe that most customers really do know what they want, at least most of the time and in broad brushstrokes. Many of the best products I’ve worked on have come from asking customers what they want! See http://brettcvz.com/posts/49-finding-product-ideas-in-new-customer-expecations http://brettcvz.com/posts/49-finding-product-ideas-in-new-cu... for a more detailed write up.
- dchuk 7y ago
  It's not about what they want typically, it's what they need. Most customers/users aren't incentivized to solve upstream problems for themselves, instead they just need to use the tools they're given to do their job (at least in B2B area). Product people should rarely if ever react directly to WHAT customers ask for, but instead dig in and understand WHY this ask is coming up. Then you'll get to the good stuff. EDIT: For clarity, I fully agree that product people must learn the customer's problems. Just be careful responding to what they ask for when doing so.
  - brettcvz 7y ago

awinter-py 7y ago

Including sales teams in the product process is hard because of the time aspect The worst-case scenario here is to find out that someone has already sold something and now it's screwing up your dev schedule. This becomes a power struggle between sales & product because allowing this will make it the norm, but turning them down can look to non-technical senior management like PMs are directly harming the company and undercutting sales. ICs are also nice + not political savvy, and can be plied and subverted by sales -- 'hey come out with a drink with us' turns into taking on random work. This gets political fast, especially because the power balance between sales and product is usually off -- one or the other is the star and doesn't listen to anybody. Good information flow requires trust, skill and good leadership.

lmeyerov 7y ago

For small teams, this goes to the weekly leadership mtg and VP's 1-1s: CEO/cto or vp eng/prod should be reporting their side, but also asking sales+marketing if they need enablement. For next scales, two models I like are "Tiger teams" (top dev team who can jump onto stuff for pushing a VP Sales picked acct through) and dedicated analysts+devs. I'm skeptical of say A/B testing until you are huge, but stuff like sales/success/marketing automation can hit way earlier.

kareemm 7y ago

> Why set the limit at two requests per team? It seems to strike a good balance - asking teams for a single top priority tends to make teams bundle all issues into one big ask, making it harder to find quick wins to slot into sprints, whereas asking teams for three or more can quickly overwhelm the PM and lets teams off the hook from making as many hard choices. Maybe it's just me, but as a PM I want to hear as much as possible from customers. Asking other teams to prioritize e.g. two requests ensured that I'd be missing potentially valuable customer feedback which made me twitchy. It's not support or sales' job to decide what's important. It IS their job to tell Product what they're hearing a lot of (ideally with minimal disruption of their workflow). But it's Product's job to decide what's important. Not having that information leaves Product (and by extension the business) more in the dark than it should be. Solving this problem is why I built Savio[1] to help support and sales teams quickly send customer feature requests from Intercom, Help Scout, and other tools to their Product team... and for Product to have a sane list with tools to prioritize their features (e.g. "Show me feature sorted by # requests, or cumulative MRR, or from Churned customers"). 1- https://www.savio.io https://www.savio.io

brettcvz 7y ago
Totally agree! I use this technique as a complimentary layer to “send all possible feedback my way”. Tactically, we achieve this through having a handful of different “feedback-X” channels for different audiences that people dump feedback into. But over time that can start to feel like a black hole that isn’t listened to, so I like adding this layer on top. Good point though, I can add a clarification to the post.
- kareemm 7y ago
  > over time that can start to feel like a black hole that isn’t listened to Great point. Definitely need to ensure teammates feel like their feedback is making a difference so they keep sharing it!
this2shallPass 7y ago
Totally agree. But isn't finding out clear priorities from sales and other teams, with the context behind it as well, useful as a PM?

erader 7y ago

As a PM that has started my career in Support/Success... I don't think I could ever advocate a strict two-request limit. Customers (and customer teams) are a non-stop firehose of feature requests. It's important for the product team to hear all these requests, mostly so they can be understood. It's tedious work, but I do it with the intention of looking for patterns and having a pulse on the customers. You might be surprised by what you find, especially how many feature requests are actually different solutions to 1 larger problem. My team does this using ProductBoard (https://www.productboard.com/ https://www.productboard.com/) to synthesize all incoming feature requests on a weekly basis. We sit for 30 minutes as a team to go through direct requests, lost sales opps, etc.. This weekly work pays dividends when it comes time to prioritize features for the next quarter/year, etc. Customer teams can feel empowered when they are given the tools/opportunity to prioritize things on their own, but the huge downside is that they feel silenced on a large majority of things they can't tell you (i.e. the "lower" priority" requests). This can really eat away at the morale of customer teams that feel they can't share their customer stories with you. When they hear feature requests from customers that they know are low-priority, it feels horrible to tell a customer it won't even be looked at by Product (it's even worse to lie). I'd recommend a system where all feedback is shared, but only 2-4 feature requests are "voted" for officially by each customer-facing team.

brettcvz 7y ago
Totally agree with the “yes and” approach of firehose plus top two - I haven’t had a chance to update the post yet, but responded to similar feedback here: https://news.ycombinator.com/item?id=21971011 https://news.ycombinator.com/item?id=21971011
- erader 7y ago
  Cool! Another weird thing I've noticed when feature requests are capped for customer teams, is that customer teams will "game" the system. At scale, customer facing ICs will do things to benefit them personally. It's not a bad thing, it's just human. Sales people do what they need to get quota, Support want to keep their ticket backlog down and CSAT high, etc. If you receive all customer facing feedback, you can make the final prioritization call on your own. If requests have been filtered too much before they reach you, the priority must be taken with a grain of salt.

lbotos 7y ago

Hi, Support Engineering Manager here. This is an okay approach. But let's talk about where it breaks down: Bugs. Some premises: - The majority of Support Requests are around bugs or administration. - Product teams are incentivized to ship features. - Bugs are often de-prioritized or "balanced" with feature requests. Solution: Embed an engineer (or build engineers out of support -- who will focus on support problems) and let them fix the bugs that are most important to support (and have full access to pair/partner with greater eng if the bug is gnarly.) This will reduce Product's backlog, and product can then focus on feature requests of which are usually ~15-20% of requests. Let that support engineer Build the tooling needed to make support more efficient. This is often a problem in orgs (getting eng resources for cost-centers) because it's not "product features". This process allows bugfix to circumvent the product planning and prioritization process and ultimately make for a better customer experience (where the bug can be solved quickly.) Product can still get customer feedback and focus on building new features, support solves their problem, and everyone is happier.

anon73044 7y ago
>Solution: Embed an engineer (or build engineers out of support -- who will focus on support problems) and let them fix the bugs that are most important to support (and have full access to pair/partner with greater eng if the bug is gnarly.) I suggested that once and Risk said it was a "Segregation of Duties" SOX violation. When asked if Support could prioritize bugs to the Dev teams responsible, I was laughed out of the meeting.
- lbotos 7y ago
  My understanding is that Support Engineers following CI/CD & Code Review process can't be a "lone ranger" so it follows the spirit of Segregation of Duties. But that laugh out of the meeting is real. I've experienced it too.
brettcvz 7y ago
It’s a neat idea! We have an “internal products” team at Clever that is tasked with building tooling for our support team (and all our other teams too!) that makes them more efficient. They are definitely worth the investment, and I’d encourage the approach to other companies. Re. Bugs - I actually really like the “top 2 things” approach for exactly this reason. It’s very illuminating when you as the PM are like “look at all these exciting things we have on the roadmap!” and your support counterpart responds with “my #1 request is that you fix this bug.” This is why I think that the customer facing teams can sometimes be better at doing this prioritization - even with lots of data about the size of a problem and anecdotes the pain, it’s still easy as a PM to not give it the appropriate attention, whereas the support team that lives with the pain will fight for it.

cmhnn 7y ago

Been doing this for while now in the crazy competitive world of cloud and enterprise. At that scale, this recommendation does not work. Customer facing teams are also very different in focus and there are dangers to thinking one is prioritizing a feature vs. fixing an issue depending on the team they are talking to. Some prioritization is of course normal but it is fluid and not simple unless you're just ready to hand off the business and not improve your platform.

Someone1234 7y ago

I'm a really big fan of the concept of UserVoice (no affiliation). Essentially direct the end-users there and let them vote on product features, track them, discuss them, and so on. A lot of organisations are scared of this, because they don't want to be put into the position of saying "no." Which is likely to occur as not all feedback is actionable, even if popular. But saying "no" and explaining WHY is in itself a great relationship building exercise with end users. I'm not saying they will always agree with the decision or explaination, but they will feel closer/more connected. This won't improve the empowerment of Customer Service roles however. Just might make them less of a punching bag for customer feedback that won't go anywhere.

brettcvz 7y ago
Do you know anywhere that does this really well in practice? My concern is that it would end up similar to the internal feedback problem where people feel like they submit requests into a queue that never gets worked on. I feel like I know how to solve that problem when there’s a small number of internal stakeholders I can go over and talk to, I’m not sure how one does it at scale with users