One struggle for the new or inexperienced product manager, is the proper prioritization of the product backlog. It is a relatively simple concept, figure out a scheme to weight, or rank the features or stories on the development backlog, to ensure that the team is working on the right features that will address the needs of the customer. Yet, this can be devilishly difficult for a seasoned veteran, let alone a new practitioner of Product Management.
Why is this? A major part of the challenge is the different priorities of the people whom you ask for input. Sales will demand priority be put to features that they believe are causing them to lose deals. Engineering will have an internal bias to things that they find rewarding to work on (or, heaven forbid, want to “refactor”). Marketing will focus on a crisp positioning strategy, and the features/value that they perceive that meshes with their messaging efforts. Et cetera.
How can you possibly rank and order this, and more importantly, to ignore the features that add no value?
Of course, Lean Startup gives one approach here, and if you can directly apply the “hypothesize, test, measure” cycle, it will greatly reduce the churn. Yet, for products that have already launched, with some success, or are currently on the growth curve, this might be too slow for the stakeholders.
Yet, every day, you must juggle the priorities, evaluating merits, weighting the priority, and shuffling the pecking order. It can be exhausting, yet there is no task for product management1 that is more important. Flub this, and you can release a product that fails.
How do you make sense of a large and growing backlog? I will expand upon my learnings in this in future posts. Stay tuned.
1 – Technically, in a scrum agile process, this is the domain of the Product Owner, but everywhere I worked, the product manager either worked with the product owner on this, or was the product owner for the scrum.