Managing the Day-to-Day Reality of Your PoR
Handling Incoming Work, Running Effective Meetings, and Evaluating the Role of Tools
Once your PoR is live, the real work begins.
You’ve collected all the work, assigned it to teams, estimated capacity, and prioritized projects across short- and long-term time horizons. That’s a huge accomplishment—but it’s just the beginning. Tickets don’t stop coming. New bugs, outages, customer escalations, enhancement requests, strategic initiatives, and surprises like M&A or layoffs will all show up at your door. Your PoR is designed for this: it’s persistent but not permanent. So how do you manage the day-to-day flow?
Step One: Set Up a Process for “Incoming”
Assume new work will arrive constantly. You need a mechanism to collect and assess all of it. Ideally, each item is created as a ticket in your existing system (e.g., Jira). But in reality, many requests will come from other channels—customer success, sales, leadership, or tools like ProdPad.
The solution is to funnel everything into a single, centralized “inbox”, whether that’s a dedicated Jira board, a shared spreadsheet, or another flexible system. Then manage this inbox with discipline and consistency.
Step Two: Establish a Regular PoR Meeting
In the early stages, a daily PoR meeting might be necessary. Over time, you may shift to weekly or biweekly cadences. Each cross-functional team should run its own PoR meeting with the right combination of participants, including the lead people from each function. In a later post, we’ll discuss how to use the DACI framework with the PoR. In short, the Drivers, Approvers and Contributors should be regular participants in the PoR meeting. Informed stakeholders can be updated asynchronously.
In the meeting, review each new item and make a decision—avoid letting items linger indefinitely.
Step Three: Use Clear Status Labels
To minimize confusion and enable faster decisions:
Start each item with a label like “New”
Decide at each meeting:
Will it be prioritized? → “In PoR”
Will it be dropped? → “Not in plan”
Does it need more research? → “Needs definition”
Be careful not to use “Needs definition” as a parking lot for things that are difficult to decide. One way to avoid doing this is to create a product research/discovery ticket (see Step 4 below) and prioritize the work. When you do this, you must proactively make a decision to consume some of your capacity.
Update the ticket or spreadsheet accordingly and proactively communicate the status to whoever submitted the request. For customer-facing issues, loop back with the appropriate internal contact so they can manage expectations.
Step Four: Break Work Down When Needed
Many items—especially feature enhancements or modernization efforts—will require upfront work before they can be prioritized.
Split these into discrete tickets:
Discovery or research
Requirements definition
Development
You can prioritize the discovery and planning phases in the near term, while placing the actual development into a longer-term time horizon. This helps you maintain forward progress while still keeping your PoR clean and manageable.
Step Five: Communicate Relentlessly
Every decision about prioritization, deprioritization, or delay needs to be clearly communicated. This is especially true when saying “no” or “not now.” The purpose of the PoR is to align the company’s resources toward business goals. That means explaining why something was deprioritized or deferred.
If you want to build trust, commit to transparency. Share PoR status updates regularly. Keep internal stakeholders informed. Make sure customer-facing teams have the context they need to communicate changes clearly and early.
Can Tools Help?
Once your PoR is operational, someone will eventually ask: “Isn’t there a tool that can do this for us?”
The short answer is: tools can help, but they can’t do the hard part for you.
The PoR process is primarily about decision making at scale—which is a human task that requires judgment, trade-offs, and collaboration. No tool can automate that. The tools you choose should support the workflow—not replace the thinking.
My advice is this:
Start with spreadsheets. They’re flexible, fast to set up, and accessible to almost everyone.
If your team already uses Jira (or something equivalent), you can evolve your PoR there over time—but don’t try to fully automate your PoR process before you’ve built the muscle.
Tools like ProdPad can help collect customer feedback, but they don’t replace the need for a prioritization process.
Think of your PoR system like carpentry: “measure twice, cut once.” Sometimes your team may grumble at the rigor involved in all the measuring, but that discipline is what builds a strong PoR. Once your process is stable, you can explore tooling that helps you automate repeatable steps—but don’t shortcut the judgment and collaboration that make the PoR powerful.
Up next - Running your PoR is a discipline – but sustaining it is a cultural effort. In the next post, we’ll explore the change management principles and reinforcement strategies needed to keep your PoR strong over time.