Product management principles

Prioritisation

Prioritisation involves using evidence for strategic and tactical decision making.

You should prioritise work in order to deliver value and meet user needs as early as possible.

We prioritise so that we:

• ensure a shared understanding of the work that is required
• consider and balance risks and dependencies
• confirm deliverables are worth the effort
• make sure our work aligns to organisational dependencies

How to approach prioritisation

Listen to users. Engage with all stakeholders to understand the value and aims. You should also ensure you have access to the relevant subject matter experts. Consider business benefits and value alongside user needs.

You should use all available evidence to understand the full picture, and make evidence based decisions.

Use an appropriate prioritisation framework so you can justify the priority order.

The work required for sizing or estimation of tasks must be proportional to the task itself.

Prioritisation can be collaborative, and you should work towards the team being aligned in prioritisation decisions. As product manager, you have full responsibility for final decisions.

Make sure that you consider the bigger picture, and avoid using prioritisation to further your personal agenda.

Roadmapping

A roadmap is a prioritised sequence of outcomes that deliver the product strategy, realising value in the most effective way. It's part of your storytelling about what you're doing and why. You can use it to have conversations with stakeholders about what work you're doing and when.

As a product manager, you own your roadmap. A roadmap is a collaborative document. Avoid creating it in isolation. You should involve your team and stakeholders in creating it. They should be aware of the roadmap and bought into it. The roadmap should be understandable on it's own. It should be relevant and accurate.

Outcomes not features

Your roadmap should be made up of measurable outcomes. It should not be a list of features. Features can change, but the outcome rarely changes. You should have an idea of how you will measure that you have achieved each outcome.

Times and dates

Your roadmap should cover:

• now (0 to 3 months)
• next (3 to 6 months)
• later (6 months plus)

Your roadmap should not include delivery dates. These should be on your delivery plan. You should only include milestones on your roadmap where absolutely necessary.

Designing your roadmap

Your roadmap should be written clearly and concisely. You should avoid acronyms and specialist language. It should be in an accessible format.

Roadmaps change

You should avoid presenting your roadmap as absolute. A roadmap is reflective of the plan at one point in time. Things change, and so your roadmap will need to change. You should review your roadmap monthly and update it at least quarterly.