Prioritizing features is the last thing you should do
Jeff Lash has a good post (Product Management is More Than Prioritizing Features) that focuses on probably one of the key deficiencies of poor product managers. I actually agree with most of his post, but don’t think he takes it quite far enough.
He describes the trap of PMs who think that their job is to simply compile and prioritize a list of requests from others – customers, sales people, support, execs, etc. I’ll call this type of PM a listmaker. I have found listmakers to be widespread in junior PMs and in dysfunctional PM organizations. Listmakers are doing much more Project Management than Product Management (all you quality project managers out there, please don’t beat me up for shortchanging your discipline, I’m trying to make a point).
Hearing this set of feature requests and paying attention to them to create ‘the list’ is, in fact important (particularly when it is your Agile Backlog). However, you can’t possibly do it right if you start (or finish) there. The key is how do you prioritize what really should be done?
Listmakers will sort the list by some sort of seemingly justifiable algorithm. Perhaps based on the number of references to an item, perhaps based on how long it’s been there, perhaps based on who’s yelled the loudest. All of these make sense to a point. Many of these even make sense for that bucket of ‘sucks less‘ features that I think should be part of every traditional (i.e. big release, not an agile sprint) project.
However, it does not make sense for really taking your product and your company to success. For that, you have to be able to see the bigger picture. You have to ask and answer questions like:
- Where is the industry going?
- What is going to matter in 1, 2 or 3 years?
- What is the innovation that will change the business?
- What is the competition going to be doing when this launches (yep, get out that crystal ball)?
It is really about strategic thinking and planning. That has to drive the product. Looking at the individual feature lists first will lead to the fabled problem of not seeing the forest for the trees block the view. The right sequence is:
- Plan your roadmap. This is a 1-3 yr rough plan of what you need to do based on the kinds of questions asked above. It may very well be wrong by the time you get to years 2 and 3. That’s ok. It still provides a foundation of consistent thought for the team to work from
- Plan your releases. Figure out what should be packaged together into each release opportunity. Maybe it is driven off of a marketable theme (see “Write the press release before the code” Maybe it is based on what bits of effort make sense to do together. But either way, start with the big and/or important parts first.
- Once you have that framework in place, the Listmakers can come to the fore and help to make sure that the requested features that tie to the theme are prioritized into the project (or not). After laying the strategic groundwork, it is safe and appropriate to be tactical.
Related Posts:
- Pick one thing (Well maybe 3)
- Do I need a business case
- System for prioritization of features
- Sucks Less features