| I like turning negatives into positives, as a way of providing constructive feedback. I'm doing product management on the side (I'm the CTO and also do a lot of the engineering) and the key issue I face is dealing with a large influx of good ideas and dealing with that in a way that minimizes my time having to evaluate things in our backlog. Saying no in a constructive way without pissing people off is key to being a good product manager. You need to be firm and decisive. But also very clear. The way I deal with this is several custom fields in our issue tracker kanban board that qualify any idea, no matter how good, crazy, in-feasible, etc. The most important ones are: - Value & Effort (one field) this is a quadrant of HighLow, HighHigh, LowLow, LowHigh. It's a reflection on what we would get out of doing something with the idea. High value and Low effort means you need a good reason not to kick an idea further. Low value and High effort kind of means a no, unless there's a really good reason. Anything in between can be decided on a case by case basis. I like the Low effort ones. They may not be that valuable. But sometimes they are nice to do. And you can just squeeze them in. - Next Step: This is a range of values that provide me an indication of when I should look at it again. Some things need to be fast tracked. Some things need more discussion/elaboration. And the rest is stuff that we might revisit or reject right now. I don't tend to spend time on rejected ideas unless somebody brings those to the table again. Things that linger too long without being actioned are going to end up labeled as rejected. Which just means they stop consuming my time. I have a few other fields (tags, priority, etc.) that are a bit more standard. But those two are the primary tools I use for deciding where to bucket ideas and how often to look at them. I should spend more time on high value ideas than on low value ones. And I should prioritize actioning items that have a next step that says I should do so. Anything else I can safely ignore indefinitely. If somebody doesn't agree, we can always discuss and change it. But there needs to be a good reason. This isn't perfect but it's a good mental model of dealing with incoming ideas in a bit structured way. I hate overly long and poorly organized backlogs because they suck up a lot of time and energy without delivering much value. And the longer and more unwieldy they get, the less likely it is anything will happen. I sometimes refer to these things as idea shredders. Good stuff goes in, and then nothing happens. Anyway, I'd be curious to learn what others are doing with their backlogs. |