Every product and value stream needs a roadmap but how do you balance all the competing priorities? What makes the cut for this sprint over the next? There are many standard approaches to prioritisation (MoSCoW, class of service, value divided by effort, weighted shortest job first etc and of course incremental funding) at its heart portfolio management is about this balancing act and the politics that surround it.
- Are you building for learnings or revenue?
- Do we build a new product or enhance an existing one?
- Do we meet the needs of new prospect or existing customers?
- Do we do the high risk high reward or the small risk small reward?
- Do we invest in quality and stability or new features and capabilities?
- Is the need urgent or important?
- Is the need high value or low
- Is the magnitude & risk of the work?
A simple tip to help you manage your backlog and stakeholders expectations is to establish a prioritisation policy and put it on the wall. As well as clearly answering the questions above, the policy might state for example; 20% of each sprint is for defect fixing, 20% for performance optimisation and refactoring, and 60% for feature development – such policies are quick and easy to draw up. They don’t replace the need for a technique to prioritise but they set the ground rules and the type of prioritisation tool to be used in each circumstance.
At its heart prioritisation is really about supply and demand – if you have too many requests and not enough resource to deliver them, then your backlog is going to get bigger… and if you have a quality challenge as well then “Err GOOD LUCK!” As each new defect will add to the backlog amplifying the pain. This is why software engineering techniques like pair programming and test-driven development (which sound crazy to most non-technical senior executives) – actually make a lot of sense in practice. However, whatever tool or mechanism you use, it can’t change the laws of physics or more precisely constraint theory. For most product managers this means having to say NO a lot and if the product managers are just order takers for sales rather than the P&L owner, this can lead to a lot of frustration especially with sales colleges. Effective partnering between sales, product and marketing is therefore vital to avoid scoring home goals that destroy value. The concept of technical debt recorded on the balance sheet is a great way of measuring questionable prioritisation decisions. It’s also a leading measure for future quality and therefore customer satisfaction. All business should consider recording technical debt on the balance sheet, especially those who capitalise software development as without it your assets value is distorted.
Because, product managers can’t magic time out of thin air, and securing extra resource is not much easier – so making things happen faster is hard, even in high performing agile teams. Balancing supply and demand, therefore, becomes a critical element of effective prioritisation and consequently, it’s about managing customer and prospect behaviours in partnership with sales and balancing resources across the whole organisation.
