Step 1 - Collect All the Work
Practical suggestions for how to get started
Before you can prioritize work, you need to know what all the work is. We talked about why this is a problem in the post called “See All the Work.” Solving this problem is where every PoR begins.
Your PoR won’t be effective unless it captures all the work. And I do mean all the work. If you’ve just taken over the leadership role for an existing team, it is likely that a large percentage of the work is not visible enough.
In most SaaS businesses, the most visible work is customer-facing: roadmap items shown in sales decks or shared with customers. Ideally, you also have an internal roadmap — likely a spreadsheet — with each item tied to Jira tickets that hold more detail about requirements, owners, and status.
If your product and engineering teams already collaborate at that level, you’re in decent shape. But even then, you likely don’t have full visibility into all the work your R&D teams are doing.
Start with a Spreadsheet
I recommend using a spreadsheet as your starting point. Yes, even if you’re a heavy Jira shop. Spreadsheets are more flexible and broadly accessible to non-technical contributors, which matters during the early stages. Tools can come later — after the process is working.
That said, you’ll likely face some resistance: “We already have everything in Jira.” But you probably don’t. Even with good tooling, some work is hidden or fragmented. Don’t let tools derail the core objective: visibility.
Also, establish a consistent naming convention for all work items. If your product and engineering teams describe the same work in different ways, you’ll end up with duplicates and confusion. Use the language of your customer-centric framework (like Jobs Theory) for naming. That language should also show up in your tickets and descriptions.
Where to Look
Beyond roadmaps, where else should you look for work that consumes your team’s capacity?
Here’s a quick checklist of common sources:
Outages or flaws in critical functionality
Bugs and defect fixes
Customer escalations
Enhancement requests (from customers, prospects, or sales)
Infrastructure work to enable development and deployment
DevOps work to support engineering velocity
Infosec work for security and compliance (SOC-2, ISO27001, etc.)
Core engineering investments: modernization, automation, cost optimization
Non-product work: meetings, reporting, 1:1s, performance reviews
Special projects: M&A, executive-led initiatives
A lot of this may already be in your issue tracking system. If it is, great — the question becomes how to make it visible in your PoR, so it can be explicitly prioritized.
What to Include (and What Not to)
For issues like outages, bugs, or recurring work, don’t try to include every individual ticket in your PoR. Instead, reserve capacity for those categories. We’ll cover that in more detail when we talk about capacity estimates.
But for most other categories — infrastructure, DevOps, infosec, etc. — you should include actual line items in the PoR so the work can be evaluated and prioritized.
The trickiest work to capture is the kind that originates outside of the product lifecycle but eventually requires engineering to deliver. Examples include:
Support escalations that can’t be resolved by Tier 1 or Tier 2 support
Enhancement requests sourced from customer success, sales, or tools like ProdPad
Engineering work for infrastructure, DevOps, InfoSec and modernization
These requests often pile up in systems that the product management and engineering teams are not actively managing. That’s why your product team must actively groom these backlogs — and be empowered to say “no.” Not everything gets in the plan. And anything that does needs a clear ticket and entry in the PoR.
If It Doesn’t Have a Ticket, It Doesn’t Exist
A simple but powerful rule: if something takes team time, it needs a ticket.
This isn’t about bureaucracy — it’s about fairness, visibility, and prioritization. Without a ticket, you can’t discuss trade-offs or allocate resources. Your job as a leader is to normalize this behavior and protect your team’s ability to say:
“If it doesn’t have a ticket, it doesn’t exist.”
Up Next: Once you’ve collected all the work, the next step is to understand how much of it your teams can actually do – and how long it will take. That’s the subject of our next post.