> I recommend using the backlog as a diplomatic tool and a polite way of letting things get lost.
I hate this approach. I totally get it, to be clear. I've done it. But I hate it. It's a sign of a really bad culture if you have to placate people in this way.
If your senior leadership is clearly communicating priorities, you should be able to say, "Look, this is an interesting idea, but as you know this quarter we're very focused on X, and this just doesn't align with that. The best route to get this done is to give your feedback in the next planning process and see if you can push Y to be a priority, then we can definitely talk about getting this on the roadmap."
A huge part of the job of a PM is to say no. If people aren't able to take a no on feature requests, there's a problem somewhere. Maybe it's with the way you're delivering it, maybe it's with the overall culture or maybe it's with the person making the request. Whatever the issue is, though, it's better to deal with it and create an environment where people understand that sometimes their requests will get declined for valid reasons.
So nothing goes in the backlog? How do you keep track of ideas that might make sense but aren't high priority right now? If you have an idea to do X, and then over 2 years you find lots of customers asking for it and it's a few weeks work, how does that get captured somewhere?
If it's just a ticket in a 2000-task long backlog somewhere, it won't help much anyway. What you actually need to have around is the person who had the idea in the first place, so they can champion it, adapt it, and flesh it out.
But if they're around anyway, they can keep it in whatever personal backlog they have instead.
This doesn't work at any reasonable sized org. Maintaining ideas in people's heads falls over quickly as people come and go.
It's work to keep a backlog not a total disaster, but that doesn't mean the answer is "tool x" or whatever. It's just work. Ugly annoying work. Ie, work.
> But if they’re around anyway, they can keep it in whatever personal backlog they have instead.
How should I manage my personal backlog? There’s over a 100 post-it’s on my desk. Should I create another backlog for longer-term ideas or maybe hire a personal PO?
> Should I create another backlog for longer-term ideas
IMO yes. That way you can easily review it before meetings, and come ready to said meetings with your most important items. I think this is quite a personal thing, so this kind of workflow may not work for you. But I found it almost impossible to work without such a list.
Bad ideas are cheap. Good ideas are extremely difficult to come by. The same idea might come by frequently and seem like a nothing each time. Product managers come and go.
There are whole classes of software that are built around aggregating and storing customer feedback in a more-raw format than JIRA tickets. See: Prodpad or Productboard or even JIRA product discovery.
I use ProductBoard. It’s not perfect, but it basically does a good job of making it easy to get feedback into the tool, and then tag/sort/organize it in a variety of ways. At this point we’ve got 5k “insights” all tied to customers & prospects. It helps us identify smaller things we might have missed, and makes it really easy to get a lot of historical feedback quickly when we do decide to tackle a feature.
If done right it forces the asker to really think about and flesh out their idea, most ticket systems don’t necessarily enforce great descriptive hygiene. But if you use an idea portal you can force the requester to answer a bunch of questions with min char counts that make them really think about the idea, then they can get feedback from others who might have a similar problem. Additionally most other channels for receiving feedback are unstructured and won’t result in high quality feedback, nor an accurate description of the problem, these types of tools have a much better chance of getting real serious feedback, bec only the ones who really care will persevere through all the questions.
If you just drop every customer email complaining about a supposed problem into a ticket in your company’s private queue, no one but internal employees will ever see it (and 99% of those won’t ever notice it or read it) but if you give your users a place to vent and discuss their ideas (with moderation of course) you can have a pretty powerful new idea/roadmap tool.
I hate this approach. I totally get it, to be clear. I've done it. But I hate it. It's a sign of a really bad culture if you have to placate people in this way.
If your senior leadership is clearly communicating priorities, you should be able to say, "Look, this is an interesting idea, but as you know this quarter we're very focused on X, and this just doesn't align with that. The best route to get this done is to give your feedback in the next planning process and see if you can push Y to be a priority, then we can definitely talk about getting this on the roadmap."
A huge part of the job of a PM is to say no. If people aren't able to take a no on feature requests, there's a problem somewhere. Maybe it's with the way you're delivering it, maybe it's with the overall culture or maybe it's with the person making the request. Whatever the issue is, though, it's better to deal with it and create an environment where people understand that sometimes their requests will get declined for valid reasons.