Comment by kareemm | Hacker News Reader

Comment by kareemm | Hacker News Reader

> 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

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.

> 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!

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?

> But isn't finding out clear priorities from sales and other teams, with the context behind it as well, useful as a PM?

Absolutely. But:

1. How are they defining clear priorities? With inexperienced support teams it's "here's the most common / last requests I've heard". With inexperienced sales teams it's "here's the feature that 'prevented' me from closing my last deal".

I'd rather understand how many people asked for a feature and who they are (enterprise vs SMB plan? active customer vs current prospect vs lost deal?)

2. As a PM I'd prefer to get as much of the context from the requester's own words (e.g. what did they actually write to support? or say to sales?) This is where capturing that snippet and sharing it with Product comes in handy... but this is hard to do at scale with an e.g. spreadsheet.

Reply on news.ycombinator.com