Product management is the hardest part of software development.
I don’t mean the process of routinely adding user stories to the product backlog for the development team to complete. Instead, I’m referring to selecting the right things to work on at the right time to realise stakeholder value, otherwise known as ‘doing the right thing’.
Clearly defined product increments, sprint goals, and a prioritised product backlog are ways to document product decisions and inform the development team what to do.
However, delivery frameworks do not describe how to populate your backlog because determining “value” is context-dependent, technically hard, complex and prone to error. Have you ever wondered why so many software products are poor to use and so many projects fail?
Understanding stakeholder needs is the foundation of every software product and should be a continuous and ongoing activity. The product owner decides which new product features or changes will best satisfy stakeholder needs and is responsible for making the call when precisely to deliver them (aka. realising “value”).
The development team provides cost/effort/complexity estimates to the product owner, informing milestones and potential delivery dates. However, estimates are not the whole story and shouldn’t be used to entirely decide what the backlog looks like, nor which stories get done.
The product owner should look beyond each backlog item, taking a more comprehensive view to consider things like the overall product roadmap, 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.
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.
Making product decisions that are often highly visible, long-lasting and impact real users is the hardest part of being a product owner. However, it is what makes product ownership so incredibly rewarding.
If you are unhappy with your development team, they may need more detailed guidance.
Better software requirements can help with this.
|
Frank Ray Consulting. Software requirements for agile development teams, particularly remote, outsourced and offshore development teams working in financial services. |