Product management is hard

Product management is the hardest part of software development. And I don’t mean the practical aspect of routinely adding user stories to the product backlog for the development team to complete.

Rather I mean the act of judiciously deciding from amongst the universe of all possible things the team could work on, what exactly they will work on, and in what order. To realise stakeholder value at the right time and in the right way. Otherwise known as ‘doing the right thing’.

Clearly defined product increments, sprint goals, and a prioritised product backlog are all ways to document product decisions and describe to the development team what needs to be done.

However, delivery frameworks do not describe how to fill up your backlog because determining “value” is context-dependent, technically hard, complex and prone to error. Did you ever wonder why so many software products are poor to use and so many projects go on to fail?

Understanding stakeholder needs and wants is the foundation for building any product, and should be a continuous and ongoing activity within agile projects. The product owner is accountable for deciding which new product features or changes will best satisfy stakeholder needs and wants, and makes the call when exactly to deliver them (aka. realising “value”).

Planning poker is an important part of this, allowing the development team to provide the product owner with cost/effort/complexity estimates, informing milestones and potential delivery dates. However, estimates are not the full story and shouldn’t be used to entirely decide what the backlog looks like and which stories get done.

The product owner should look beyond the cost/effort/complexity of each product backlog item, taking a wider view and considering things like the overall product road map, how the composition of a given product increment combines to form collective value, key business drivers and market trends, the impact of technical debt over the short/medium/long term, outstanding bugs and user feedback etc.

None of this is deterministic and can be predicted with 100% accuracy either; confidence levels should be considered. Alternative solutions and workarounds are good to have for worst-case scenarios as well.

Holding all of this in mind when making product decisions that are often highly visible, long-lasting and which impact real users is the hardest part of being a product owner. However, it also makes product ownership and management so incredibly fulfilling and rewarding.