"Managing" a backlog
A tool misunderstood
The output of effective Product management is a concise backlog. Many PMs unfortunately see it the other way around, and call “Management of the backlog” as Product Management.
Management is purely a side quest, the backlog is the documented output of all your efforts of talking to consumers, looking at data and your prioritization process, and what should not be picked up.
If it gets treated as the primary job, PMs tend to start behaving like ticket managers, in extreme cases working on the backlog in a silo, rather than talking to consumers to find opportunities to add value to the product. As an extension a resume or a JD should never say “Managed/Manage the backlog”. A chef’s job is not keeping the counter clean.
Furthermore, product managers rarely have the opportunity to work strategically, as backlogs keep them focused on detailed, ground-level tasks.
Should one not use a backlog?
That is not the right perspective, the tool is not the problem. The problem is with the mindset that a backlog needs to be “managed”.
The Backlog needs to be looked at like a communication tool that shares details of what needs to be done. How you use it depends on how you work with your teams. For example, grooming can be done in living documents outside the tool where you track your product backlog, in which case the backlog is a collection of scoped and prioritized items. In other cases you can also use your backlog as an inbox which you put every possible input in, this is more true in larger orgs where the tools to be used are strictly regulated.
