Plan and prioritise · Core
Prioritise the work and build a roadmap
You will always have more ideas than time. A simple, shared way of scoring them helps you choose, explain your choices and turn them into a roadmap the team and stakeholders can follow.
About 1-2 daysEvergreenLast reviewed 4 November 2026
Who this applies to
- Skills it builds
- Prioritisation and roadmappingStrategy and vision
- PM types
- All
- Product types
- All
- Starting points
- All
- Ways of working
- All
- Experience
- All
- Size of organisation
- All
Steps, by experience
Beginner (under 1 year)
- List every candidate piece of work in one place: features, fixes, research and technical work. Write each one as an outcome where you can.
- Pick one scoring method and explain it to the team. RICE is a good start: Reach (how many people), Impact (how much it helps each), Confidence (how sure you are) and Effort (how much work).
- Score each item with the team. Ask engineers for effort, and use your research and data for reach and impact. Lower the confidence score where you are guessing.
- Sort by score, then sense-check the order. Move items for real reasons, such as deadlines, dependencies or legal duties, and write down why.
- Group the top items into a roadmap with three columns: Now, Next and Later. Avoid exact dates beyond the next few weeks.
- Share the roadmap with stakeholders, explain how you scored it, and agree how often you will revisit it (for example monthly).
Intermediate (1 to 4 years)
- Gather all candidate work as outcomes, including technical and research work.
- Score it with a shared method (RICE or similar), using real effort estimates and confidence levels.
- Adjust for dependencies and fixed deadlines, and record each reason.
- Publish a Now / Next / Later roadmap and set a review rhythm.
Experienced (5+ years)
- Keep one backlog of outcomes, with an agreed, visible scoring method.
- Get effort estimates from engineering, and let confidence reflect the evidence.
- Justify overrides in writing, and map dependencies.
- Publish a Now / Next / Later roadmap, with a review date set.
Who can do this
Owner: Product manager
Can be delegated to
- Delivery Manager: Map dependencies and run the scoring session
- Tech Lead or Architect or Backend Engineer or Frontend Engineer: Provide effort estimates and flag technical risks
- Business Analyst or Product Owner: Keep the backlog tidy and write each item as an outcome
- Data Analyst or Performance Analyst: Estimate reach from usage data
Reviewed by: Delivery Manager, Tech Lead
Tool examples
- Jira
- Add Reach, Impact, Confidence and Effort as custom number fields on epics, so you can sort and filter by score. Use Jira's timeline view for the Now / Next / Later roadmap.
- Azure DevOps
- Use the Effort and Value fields on features, and show the roadmap on a delivery plan.
- Linear
- Use projects for roadmap items and priority labels for the scored order.
- Google Docs
- If you have no tracker, a shared spreadsheet with one row per item and a RICE formula column works well.
- Miro
- Run the scoring session live on a 2x2 grid (impact against effort) before you put numbers on it.
- Claude
- Paste your scored list and ask which scores look inconsistent with each other, and what questions a sceptical stakeholder would ask.
Definition of done
- All candidate work scored with a method the team understands
- Every change to the scored order has a written reason
- Now / Next / Later roadmap shared with stakeholders
- Date set to review priorities
Common pitfalls
- Scoring alone, so the team does not trust the result
- Treating the score as the final answer rather than a starting point
- Putting firm dates on items months away
If you lead the team
What good looks like: Teams prioritise with a shared, visible method, record why they override it, and publish a Now / Next / Later roadmap.
Ask your PM
- How did we decide this order, and what did we say no to?
- When do we next review priorities?
Warning signs
- Priorities change with whoever spoke last.
- The roadmap is a list of dates no one believes.