As you move forward with your own Plan of Record, I encourage you to think of it as an operating system—not just for your R&D team, but potentially for your entire business.

If you’re familiar with Thinking in Systems by Donella Meadows, the idea here is conceptually similar. The PoR prioritization process acts as a system for aligning the resources of your R&D team—subject to all of the usual constraints—in service of your company’s goals. It relies on clarity of goals and a culture of trust, where people feel safe enough to engage in constructive conflict. This conflict is essential: there will always be tough calls about which initiatives to prioritize, especially when multiple paths could lead to success and none is obviously correct.

The PoR works at scale because it enables people to make better decisions, together. These decisions are not formulaic—they require judgment about how best to apply resources to achieve goals, using the best information available at the time. That information is often imperfect, and that’s OK. The PoR is built to be “persistent but not permanent.” It’s designed to evolve as new information becomes available, while continuing to move forward even in the absence of perfect clarity.

In a well-functioning PoR system, most decisions are made as low in the organization as possible—ideally at the team level in weekly PoR meetings. Managers at all levels are expected to use good judgment about what should be prioritized or deprioritized—and to know when a decision needs to be escalated. That escalation may be necessary when goals are unclear, trade-offs are murky, or resource implications are significant.

None of this works without a trust-based culture. Leaders need psychological safety in order to make prioritization decisions in the face of ambiguity. Without it, too many decisions get pushed up the chain, slowing momentum and creating bottlenecks. Engineers, in particular, hate to be idle. In the absence of a decision, they’ll often keep moving based on assumptions—which leads to wasted effort and missed opportunities.

The price that must be paid for this autonomy comes in the form of more and better communication. Good communication builds trust and enables feedback loops to ensure that decisions are on track. It takes time, energy, and attention to detail—but it’s critical for transparency. If your communication is frequent enough and clear enough (without being overwhelming), then stakeholders at all levels—from team leads to the executive suite—can see how resources are being applied toward company goals. That visibility also helps uncover when goals themselves are misaligned, unclear, or misunderstood.

The entire PoR Series can be found on Substack for anyone who finds it useful and wants to use it as a resource. The table of contents can be found at the Start Here page. Thank you for your support and good luck.

If your PoR process is gaining traction, your team is performing at a high level, and your communications are crisp and reliable, you may find that some of your peers begin to view the PoR through the lens of corporate power and politics.

Some executives may view the PoR as a tool you’re using to centralize authority over resources. Others may feel frustrated that their initiatives are not being prioritized, and they worry that they’re losing influence. In dysfunctional organizations, people might even accuse you of using the PoR to rationalize decisions you wanted to make anyway — even when your process is transparent, participatory, and sound.

What Should You Do?

If you’re not the CEO, you don’t control the entire company culture — and you won’t be able to prevent ego and politics from creeping into the process. But there’s a lot you can do:

1. Let Results Speak.
   The most effective way to overcome skepticism is to deliver meaningful results. If your PoR leads to better planning, faster execution, and more reliable delivery, others will notice. Let performance be your proof.

2. Be Transparent — Relentlessly.
   Share your process widely. Show how decisions are made. Explain who is involved and how input is gathered. Make it obvious that this is a system for the company’s benefit, not your personal control.

3. Avoid Being a Human Shield.
   It’s tempting to protect your team from organizational dysfunction by absorbing all the friction yourself — but this isn’t sustainable. Instead, engage your senior leaders and bring them into the process. Ask them to help present the PoR, align on decisions, and communicate outcomes.

4. Use the PoR to Escalate, Not Shield.
   When prioritization decisions reach an impasse or require cross-functional agreement, escalate them via the PoR process, and do it openly. This demonstrates that the process isn’t about asserting control — it’s about creating clarity and alignment.

5. Be a Cultural Role Model.
   Even if you don’t control the entire culture, you can lead by example. Create a trust-based culture within your own team. Reinforce the importance of clarity, transparency, and constructive conflict. Over time, others may follow suit — especially if your methods are delivering better results than theirs.

Up Next: In the next and final post, we’ll wrap up with some final thoughts about the benefits of using your PoR as the operating system for your business.

This is often easier said than done.

It’s not reasonable to expect Board members or executive leaders to understand trade-offs at the same level of detail as cross-functional R&D teams. But some level of technical understanding is essential for making sound prioritization decisions.

This is where the unique strengths of founding CEOs become especially valuable. Founders often have intimate knowledge of the technical platform, the team’s strengths and weaknesses, and the implications of various choices. They’re able to reason about prioritization across technical and business domains — and adjust rapidly when new constraints emerge.

Unfortunately, these kinds of leaders are rare — and they become even rarer as companies scale.

What Should You Do?

The good news is that the PoR itself is your best tool for bridging this gap. Here’s how to use it effectively:

1. Translate, Translate, Translate.
   Use the PoR as a translation layer between corporate goals and technical decisions. If you’re talking to your executive team or Board, keep the conversation focused on trade-offs between goals — and present the technical work in terms of business outcomes. If you’re talking to your technical team, emphasize how specific decisions align with broader business priorities and OKRs.

2. Adapt to Your Audience.
   Meet each audience “where they are.” Executives don’t need to understand the nitty-gritty of service orchestration — but they do need to understand the business risk of delaying an infrastructure migration. Engineers don’t need to know the details of financial operations — but they should understand why an initiative maps to improved customer retention or gross margin.

3. Use Objectives and Key Results (OKRs) as a Bridge.
   If you’ve done the work to cascade company goals into clear OKRs for the R&D organization, then your team should already see how their work maps to outcomes. But even with OKRs in place, you’ll need ongoing communication and reinforcement to maintain clarity — especially as things change.

4. Train Your Technical Leaders.
   One of your key responsibilities is to help product and engineering leaders become better at navigating the intersection of detail and strategy. Help them understand how technical choices connect to company goals. Teach them how to simplify complex trade-offs when communicating with executives — and how to bring business context into team-level prioritization discussions.

Up Next: In our final tricky situation, we’ll tackle the human element — how ego, power, and organizational politics can potentially create resistance to the PoR prioritization process, and what you can do about it.

In this kind of environment, the prior executive leader made most — or all — of the big decisions about what to prioritize. They may have relied heavily on their own instincts and personal knowledge of the team’s capacity, but didn’t actively involve other R&D leaders or cross-functional partners in the decision-making process.

At first glance, it might seem like this was a rudimentary version of a Plan of Record. But in practice, it often left the team with no real sense of ownership — just a list of mandates to execute. The result? A pervasive “best efforts” mindset where teams aim to do their best but don’t feel accountable for outcomes.

What Should You Do?

This is a situation where you can’t start with the PoR right away — at least not successfully. Here’s where to begin instead:

1. Start with the Pre-Requisites.
   The first job is not to implement the PoR. It’s to build the foundation that will allow it to work. That means:

   • Building a trust-based culture where people feel psychologically safe to speak up.

   • Creating clear goals that everyone can align around.

   • Re-establishing a customer-centric framework that connects day-to-day work to customer outcomes.

   • Structuring your teams so they are cross-functional and empowered to deliver on their objectives.

2. These four pre-requisites must be in place before you ask your team to embrace the mindset shift required by a PoR.

3. Share your vision of the PoR early — but don’t rush it.
   Be transparent about where you’re going and why the PoR will help. But make it clear that you’re not imposing a new process from above — you’re building the right culture and structure so the process can thrive. Invite input and discussion.

4. Demonstrate shared decision-making.
   The best way to break a top-down culture is to model a different way of operating. Engage your product and engineering leads in shaping the roadmap. Make it safe for them to disagree and raise concerns. Over time, shift prioritization authority to the teams, supported by the PoR framework.

5. Expect progress to be slow — and celebrate milestones.
   Change management in this kind of culture won’t happen overnight. Look for signs of increasing engagement, stronger collaboration, and growing confidence. Celebrate those moments. They’re evidence that your team is taking ownership and moving to more of a commitment mindset.

Up Next: Sometimes the challenge isn’t the culture — it’s the complexity. In the next post, we’ll look at what to do when leaders or stakeholders struggle to engage with the level of detail the PoR requires.

Here’s a typical version of the scenario:
You need to choose between (option a) developing a new product feature to open a new market segment, or (option b) modernizing your underlying technical platform to reduce infrastructure costs, improve stability, and accelerate future development. Resources are constrained, so you can’t do both.

In these moments, ROI can seem like an obvious decision-making tool. But for SaaS businesses, ROI is often a poor fit for evaluating all types of work — and relying on it too heavily can lead to damaging long-term decisions.

Here’s why:

• New product features (like option a) often lend themselves to a clean ROI analysis. You can estimate development costs, go-to-market investments, and the potential upside in revenue.

• Platform modernization (like option b), on the other hand, is far murkier. The benefit may be stability, long-term cost efficiency, or developer productivity. The “ROI” is often existential: it’s about survival, not upside. And it’s nearly impossible to quantify in a traditional model.

Unfortunately, if the board or executive team only sees ROI on a spreadsheet, the “shiny” new feature almost always wins. Over time, this leads to technical debt, poor performance, fragile infrastructure, and an erosion of long-term business value.

What Can You Do?

You don’t need to reject ROI — but you do need to broaden the conversation and bring better tools to the table. Here are five concrete actions:

1. Categorize work into three investment types:

   • Maintenance: Keeping the platform stable and functional, which includes everything from bug fixes to platform modernization and pay down of technical debt

   • Sustaining Innovation: Enhancing existing products

   • New Innovation: Creating new revenue-generating features or products

Maintenance and sustaining innovation don’t generate new revenue streams, but they’re essential to avoid churn and protect pricing power. Only new innovation lends itself to classic ROI models.

2. Track how your R&D budget is allocated across the three buckets.
   Underinvestment in maintenance often leads to costly failures and customer churn. If 40–50% of your R&D budget is going to maintenance, you’re in the right ballpark. Be ready to show this data to the board.

3. Reframe the ROI conversation around prioritization of goals.
   ROI analysis can help clarify which strategic goals might yield the biggest return. But once the goals are clear, the PoR should be used to align resources accordingly. The PoR is a goal execution tool, not a financial analysis framework.

4. Use the RICE framework to score and compare work across categories.

   • RICE = Reach, Impact, Confidence, Effort

   • RICE works well even for projects where ROI doesn’t apply, helping you compare feature development, maintenance, and tech investments on a more even footing.

5. Educate your R&D leaders and executive team.
   Help them understand that different types of work require different evaluation lenses — and that decision-making should be grounded in prioritized goals, not one-size-fits-all formulas.

Up Next: One tricky situation arises when the team has historically operated under a top-down culture, with little real ownership of plans or outcomes. In the next post, we’ll explore how that history can complicate adoption of the PoR — and how to turn it around.

But sometimes, the goals on paper aren’t the ones driving decisions in reality.

A common scenario goes like this: The company’s goals focus on driving new business, expanding the market, launching new products, and achieving long-term growth. The PoR is structured to support these initiatives. Yet, time and time again, your team is asked to stop what they’re doing and respond to large customer escalations, often with a directive that these must take priority — even when doing so derails your roadmap.

What’s going on?

In many cases, there is a hidden assumption operating behind the scenes. The most common one is a fear that new business growth isn’t going to be strong enough, and therefore the business cannot afford to lose any large renewals. So while the stated goals are all about expansion, the real behavior suggests that customer retention is the silent top priority. That misalignment creates friction — and chaos.

Sometimes, this fear is entirely rational based on market dynamics. In that case, the hidden assumption should be surfaced and made explicit so that everyone — from R&D to GTM — is clear that large customer retention takes precedence over new business development when trade-offs must be made.

But other times, this misalignment is cultural. In sales-driven cultures, there may be a deeply embedded bias to prioritize whatever it takes to “win the big deal” — whether it’s a competitive bid or a renewal — regardless of its alignment with long-term strategy.

What Can You Do?

Use your PoR to escalate the decision to the executive team in a constructive and non-emotional way. The act of mapping visible work against stated goals — and showing where they don’t align — creates space for important conversations.

In the best case, this process surfaces and resolves the hidden assumptions, allowing the team to move forward with shared clarity.

In the harder case, it reveals a lack of trust-based culture at the executive level, where no one feels safe enough to challenge the assumptions or open the conversation. If that’s the case, you’ll need to view this as a long game. The PoR still helps — by exposing misalignment without blame. Over time, that clarity builds pressure for deeper conversations about strategy and focus.

Up Next: Another common derailment happens when executive teams lean too hard on ROI calculations to make prioritization decisions — often at the expense of foundational platform investments. Let’s take a closer look at that next.

I’m an optimist, and I believe that the Plan of Record (PoR) prioritization process can help resolve most of these challenges. But it doesn’t happen automatically. It takes a concerted effort, persistence, and a willingness to work through short-term setbacks and frustrations. These moments often become the crucibles in which your leadership is tested — and strengthened. Sometimes, they even lead to the kinds of wins that put a smile on your face and make you remember why you love the job.

In the next five posts of the PoR series, we’ll go through the most common tricky situations that I’ve encountered — and offer concrete guidance on what you can do about them.

The Tricky Situations We’ll Cover:

• Hidden Assumptions about the Goals
  When the stated company goals aren’t the real drivers of executive behavior, prioritization becomes reactive and confusing.

• Pitfalls of ROI Analysis
  When decision-makers over-rely on ROI to evaluate technical investments, critical long-term needs like platform modernization get shortchanged.

• History of Top-Down Engineering or Product Management
  When your predecessor made all the calls, it takes work to rebuild a culture of trust, ownership, and distributed decision-making.

• Struggling with the Detail
  When executive stakeholders don’t understand — or don’t want to understand — the trade-offs, your PoR must become the translation layer.

• Ego and Power: Why the PoR May Seem Threatening
  When your PoR gains traction, not everyone may be happy about it. Some may view it as a power grab. This is where transparency and humility matter.

Up Next - We’ll help you identify situations where hidden assumptions might create conflicting priorities. If you can diagnose the problem, you’ll be in a better position to manage the conflict.

That was certainly my experience. In my early startups, we never felt the need to build a formal Plan of Record. The CEO, CTO, and Sales leader all had deep shared context. We operated with a tight feedback loop, knew our customers intimately, and made prioritization decisions on the fly. The communication was constant, and the decisions were grounded in direct knowledge of capacity and market needs. It worked—because we could hold the entire PoR in our heads.

But that approach only works until it doesn’t.

Growth Requires Strong Decision Making at All Levels of the Org

Some startups scale for years without needing a formal PoR. But in every case I’ve seen, the ones that succeed long-term have either (a) an extraordinarily strong founding CEO with a tight group of leaders who all stay in sync, or (b) they adopt a prioritization framework at the first signs of breakdown.

And the breakdown always comes:

• The team expands to the point where persistent alignment requires more work.

• New product lines introduce tradeoffs.

• Acquisitions bring in unfamiliar systems and cultures.

• Customer requests become more diverse.

• Engineers start asking, “When are we going to invest in the work to retire some of this technical debt? It’s building up.”

Even with a brilliant founder, the scale of the decisions will become large enough that it cannot be effectively handled by a single person. That person will become a blocker and things will slow down. The way to maintain velocity is to enable good decision making at all levels of a growing organization. This is when a PoR framework can help.

The Plan of Record Scales When the Founders Can’t

Founders often resist structure because they worry it will slow things down. But the right kind of structure actually enables speed—by eliminating the chaos that comes with constant reprioritization and invisible constraints.

The PoR process doesn’t replace the founder’s decision making process. It scales it. It gives new leaders the tools to make decisions with context. It clarifies when things need to be escalated, and when they don’t. It forces the organization to wrestle with tradeoffs instead of hiding behind “best efforts.”

Even if you’re still in the early stages, it’s worth learning the mindset. Because eventually—whether through scale, turnover, or success—you’ll need a way to make difficult prioritization decisions in a world where everything feels important.

Up Next - In the next section, we’ll take a hard look at five challenging human dynamics that can derail even the best-laid prioritization frameworks — and how you can navigate through them.

I recommend the DACI framework. While its origins trace back to Intuit, a helpful reference is Atlassian’s DACI guide. DACI stands for Driver, Approver, Contributors, and Informed. It’s a powerful tool to clarify who’s responsible for what.

For every project or ticket, assign these roles:

• Driver: Defines the decision to be made and drives the process to reach that decision by a set deadline. (Only one Driver.)

• Approver: The single decision-maker with authority to make the final call.

• Contributors: Team members who provide input to shape the decision.

• Informed: Stakeholders who need to be updated on the outcome.

In R&D teams, there will be many situations where an engineering lead is both the Driver and Approver—especially for urgent decisions like outages or bug prioritization. For roadmap work and feature refinement, the product manager often plays the Driver role, with engineering and UX leads as Contributors. The Approver may be a more senior product leader, such as a director or VP.

When goals are clear and relatively stable, most prioritization decisions can be made by the product and engineering leaders within the teams. A typical example: the product manager drives, engineering and UX contribute, and a senior product leader approves.

But when goals shift—or the trade-offs are too large—decisions need to escalate.

Here are common examples where Approvers and Drivers need to be at a higher level, potentially including the CPTO, CPO, CTO, CEO, or even the board:

• Reprioritizing in response to a competitive threat

• Responding to reductions in team size or budgets

• Integrating teams and roadmaps following an acquisition

• Kicking off a major modernization effort

In these cases, the PoR itself becomes the operating system that Drivers use to bring decisions to the right people. Once those decisions are made, they cascade down with renewed clarity—allowing the PoR to resume functioning effectively at the team level. This is what enables your process to scale: low-level autonomy combined with high-level alignment.

Up Next: Many startups don’t think they need a PoR – until they do. In the next post, we’ll explore the question of whether start-ups need a PoR.

No matter how clearly you define your process or how rigorously you run your PoR meetings, long-term success depends on your ability to manage change. If your business already operates with a healthy trust-based culture and strong strategic alignment, your job will be easier. But most organizations don’t start there.

If you’re walking into a team that’s operating in “best efforts” mode—with chronic overcommitment and missed deadlines—you can’t just declare a shift to a commitment-based mindset and expect it to work. You need to earn it.

Start Small and Build from What You Can Control

You may not have the authority to fix everything at once. That’s okay.

Start within your span of control—perhaps one team or product line where you can shield the group from organizational noise and build a working PoR. Create a buffer, implement the prioritization process, and deliver results. As that team succeeds, you’ll have a living proof point that prioritization works.

As credibility grows, bring others into the fold: invite contributors from neighboring teams, inform other functions, and explain how the PoR is delivering value. If your team delivers consistent results and communicates clearly about capacity and tradeoffs, others will take notice.

Communicate the Why—Over and Over Again

Most organizations aren’t resistant to change because they’re lazy. They’re resistant because they’ve been burned before. Vague goals, unrealistic timelines, and shifting priorities can leave scars.

So be clear about why the PoR is worth the effort:

• It creates alignment between goals and resources.

• It builds a system for accountability and commitment.

• It helps the business scale without spinning out of control.

Reinforce this message in meetings, 1-on-1s, team reviews, and executive updates. Celebrate successes that come from clear prioritization. Highlight the problems you’ve avoided thanks to PoR discipline. This is the ongoing teaching and reinforcement that makes a PoR process durable.

Be Patient with Culture—But Not with Chaos

It takes time to shift an organization’s culture toward trust, transparency, and prioritization. But that doesn’t mean you wait passively. You can still drive forward with the PoR at whatever level is feasible.

Keep your expectations practical. If you’re managing a team inside a broader organization that still “prioritizes everything,” then your job is to lead by example. Build your team’s muscle for estimation, planning, and delivery. Translate that confidence into proactive communications that build credibility with adjacent teams. Let the results speak first—and then tell the story of how and why it worked.

Up next – In the next post, we’ll look at the role of clear decision-making frameworks in running your PoR, especially the importance of assigning roles using DACI and knowing when to escalate.

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.

You’re introducing a new way to prioritize and commit to work. This shift requires people to think differently — not just about what’s important, but about how decisions get made, how work is tracked, and how teams are held accountable.

Start With the Fundamentals

Early on, you’ll need to teach and reinforce some key principles:

• A Plan of Record is persistent but not permanent

• A PoR is designed to change when new information emerges

• If something is added, something else must be removed (assuming constraints remain constant)

• The PoR represents the best current alignment of resources with corporate goals

That last point is critical. The PoR is a mechanism for alignment — not just a list of projects. It helps the business make informed trade-offs in the face of constraints.

If Everything Is a Priority…

If your team has been working in best efforts mode, your initial communications need to break that pattern.

In best efforts mode, the R&D team is usually overwhelmed and demoralized. They’re working hard, but they’re not hitting expectations. The customer-facing teams are frustrated, because deliverables are late or unclear. The result is a cycle of burnout, mistrust, and missed goals.

Your first communication goal is to define what “commitment” means in the context of the PoR — and to build trust around that definition.

A Plan of Record enables commitment by clearly identifying:

• What work is prioritized

• What capacity is available

• What timelines are realistic

The Engineering Team’s Perspective

Your engineers will be wary of the word “commitment.” They know that things change. Priorities shift. Estimates go wrong. Bugs appear out of nowhere. Promises made in good faith get derailed by new information.

That’s why you need to reinforce the idea that the PoR is designed to adapt. It’s not rigid. It’s not a promise that nothing will change. It’s a framework for communicating what’s most important — and for making intentional changes when the situation demands it.

But — and this is key — if a new item is added to the PoR, something else must be removed or delayed. Otherwise, it’s not a real prioritization.

The Executive Team’s Perspective

Executives and customer-facing teams want confidence in the roadmap. They’re managing external stakeholders — customers, investors, and the Board — and they need to be able to explain what’s coming and when.

To build that confidence, make a simple commitment: If something in the PoR is at risk of delay, communicate it early.

For example, if a feature scheduled for Q1 looks like it might slip, alert your go-to-market team 30 or 45 days in advance. That gives them time to reset expectations with customers and plan accordingly.

This kind of transparency builds trust.

Change Will Happen

You’ll also need to prepare everyone for change — not just slippage, but shifting priorities. New competitors emerge. Technology changes. Acquisitions happen. All of these things may require realignment.

The PoR helps you manage those changes, but it only works if the entire organization understands how the process works — and buys into it.

When evaluating a new initiative, the executive team will want to understand the “cost” — usually in terms of capacity. This is why your PoR team needs to get good at doing “quick take” estimates: rough calculations of the people and time needed to deliver on something new.

Communication Is the Work

You can’t over-communicate when rolling out a PoR. As Patrick Lencioni wrote in The Advantage, you need to repeat key messages until people groan. Then repeat them again.

The PoR is only useful if people understand what it is, how it works, and how to engage with it. When you reach that point, you’ve shifted your company from best efforts to commitment mode — with shared accountability and a much greater chance of delivering on what matters most.

Up next - In the next section, we’ll shift to the day-to-day operations of your PoR—including how to triage new, incoming work, hold effective PoR meetings, and manage the human side of change.

Where to Begin

If you’re new to your leadership role, your long-term goal is to align prioritization decisions with corporate goals through cascading objectives and key results (OKRs) that reach every team. But early on, the reality is likely to be very different.

Start by understanding how prioritization is happening today — what’s being prioritized, by whom, and why. Then use the PoR process to chart a path from that starting point to where you want to go.

In the worst cases, you may find that everything is considered a priority — perhaps even explicitly stated by the CEO. This typically means the team is in best efforts mode, reacting to the latest crisis or perceived urgency, rather than making deliberate choices about trade-offs.

Even in less chaotic environments, it’s almost inevitable that the team’s capacity is insufficient to deliver all the visible work within the existing roadmap timeline.

So, the first step is to make the existing prioritization explicit in the PoR. From there, you can evaluate what’s consuming capacity and decide what the team can realistically commit to.

The Two Categories to Look For

When you examine what’s already being prioritized, you’ll usually find two categories:

1. Real or Perceived “Must Do’s”

Without a visible PoR, teams often prioritize work they think is non-negotiable: fixing platform outages, addressing severe bugs, or resolving escalations from large customers.

Sometimes they’re right. Other times, these priorities may reflect assumptions — not deliberate decisions.

This is where the PoR process creates clarity. You can validate which “must do’s” align with corporate goals and commit to those. The rest can be explicitly deprioritized or moved to a later time horizon.

2. Promises Made to Customers or Prospects

If you’re in a sales-driven culture, it’s likely that commitments have been made — with or without your team’s input. These promises may be driving work that hasn’t been vetted for alignment with goals, technical feasibility, or timeline.

Again, your PoR gives you the ability to triage: Which promises support your goals? Which can be renegotiated or pushed out? Which need to be walked back?

Expect the “Oh Sh*t” Moment

When you total up the work already underway — outages, bugs, support escalations, perceived “must do’s,” and promises made — you may discover that there’s little or no capacity left for strategic roadmap items.

This is your “oh sh*t” moment.

Use it as an opportunity to bring the executive team into the prioritization process. The ability to have an open, trust-based conversation about trade-offs is the signal that your PoR process is working.

If that conversation isn’t possible yet, that’s a sign you need to invest in building trust (see “Prerequisite 1 – Trust-Based Culture”).

Use the Time Dimension

To prioritize effectively, you need to manage when work gets done — not just whether it gets done.

Many companies struggle to create forward visibility. Often, their roadmaps stop at the fiscal year boundary, and visibility decreases the closer you get to year-end.

The PoR solves this. Because it’s a living process, you can create a rolling, forward-looking roadmap.

Start small:

• Use quarters as your unit of time.

• Build a PoR for the next two quarters, with the highest confidence in near-term delivery dates.

• Then extend to four quarters, with solid estimates further out.

As you mature the process, your roadmap becomes both more credible and more transparent — internally and externally.

Up next – With work prioritized and timelines set, the final piece is communication — building trust by explaining what’s being done, why, and how it may change.

What You’re Aiming For

You want to estimate the effort required (in person-weeks or an equivalent unit) for each item in your PoR. Then, you compare the total effort to the actual capacity of the teams.

At a startup, this is relatively simple. You can probably fit the entire development team into one room, and communications are fast and informal.

But if you’re operating at any real scale, it gets more complicated:

• You likely have multiple product lines

• You’re managing multiple cross-functional teams

• Some engineers are interchangeable across teams, while others have specialized skills

• DevOps, infrastructure, and infosec are shared services with limited capacity

Your PoR must account for all of this complexity — and still be usable.

Two Capacity Challenges

You’ll need to overcome two big challenges:

1. Gaining trust from the executive team that your capacity estimates are reliable

2. Building the skills within product and engineering leadership to estimate capacity well

Both take time. But you can start by tackling the easier parts first.

Start with Recurring Work

Recurring work categories — like outages, bug fixing, DevOps, infrastructure, and security — are a good starting point for estimates. For recurring work, you don’t want to prioritize individual tickets but you need to estimate and reserve enough team bandwidth to handle the work. If you have decent historical data, your estimates will be fairly reliable.

Of course, many teams don’t have great data to begin with. That’s okay. Make your best estimates and iterate. Over time, track estimated vs. actual to refine the model and build trust.

Also: don’t forget to factor in time for meetings, 1:1s, performance reviews, and unexpected strategic work like M&A due diligence. This kind of overhead is real and needs to be visible.

Estimating Roadmap Work

The harder part is estimating capacity for non-recurring work — especially new features and product improvements.

This depends heavily on:

• The quality of your product requirements

• The level of engineering experience

• The presence of external dependencies (design, data science, research, DevOps, etc.)

This is where your team structure matters. If your teams aren’t cross-functional or don’t have stable ownership of products or features, your estimates will be less accurate — and your ability to deliver will suffer.

You’ll also likely uncover resource contention problems. For example, several teams may depend on the same data science resource or infosec expert. These contentions must be surfaced and planned for in your PoR.

And here’s where trust-based culture comes into play again: if engineers don’t feel safe raising concerns or exposing risks, your estimates won’t be honest — and your roadmap will be fantasy.

What If the Estimates Aren’t Great?

They probably won’t be — at least not at first.

So start with what you have, declare your intent to improve, and create transparency about how you’re measuring actual vs. estimated. This builds trust and improves accuracy over time.

And don’t make the mistake of trying to sandbag. If you’re always hitting your targets, your executive team will start to assume you’re padding the numbers. That undermines trust too.

The goal isn’t perfection. The goal is to build a habit of informed estimation, transparent communication, and continuous learning.

Up next – With a clear view of the work and your capacity to deliver it, you’re finally ready for the core step: making prioritization decisions.

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.

1. Collect all the work

2. Estimate capacity across teams

3. Prioritize work and build the PoR

4. Communicate with discipline and clarity

The purpose of the PoR is to help your business make better decisions about how to align your resources in order to achieve your goals and deliver on customer jobs. That’s why I believe every person who is hired into, or promoted into, a leadership role within an R&D organization at a SaaS company should invest time and energy upfront to build a PoR prioritization process. This includes product managers, engineering managers, and other technical leaders working in close collaboration as “drivers” — and ideally, it’s done with buy-in from the CEO and executive team.

Even if collaboration across functions is difficult or the R&D team is siloed, the important thing is to start — and to build your PoR with whatever scope is feasible. While it’s ideal for the PoR to operate across the entire organization, it can still dramatically improve focus and effectiveness even at smaller scopes. As we’ll discuss in later posts, the PoR is an operating system for leadership and decision-making.

Whether your target scope of implementation is small or large, you should expect a significant upfront investment in time and energy. The magnitude will depend on your organization’s current state and how much change management is required to shift the team’s mindset. If the dysfunction is obvious and your team sees the need for change, it may be easier to get initial buy-in — but even then, you’ll still need to guide people through the shift.

People will need help letting go of how things were done before, even if the old approach wasn’t working. Acknowledging the good intentions behind previous efforts can help create space for the new process. You’re not blaming the past; you’re saying the company has reached a stage where it needs a new approach in order to scale, improve efficiency, and deliver on commitments.

As a leader, your job is to paint the picture of how the PoR prioritization process will help the company make better decisions — while also increasing focus, flow, and joy for the team.

This is the opposite of organizing purely by function. In a functionally siloed R&D organization, developers sit in one group, product managers in another, DevOps in a third, infrastructure and infosec elsewhere—and the only connection to business goals runs through a single R&D executive.

The result? Teams operate in isolation, can’t see all the work, and can’t estimate capacity accurately. Prioritization becomes a guessing game, and the PoR is either undercut or ignored.

Why Functional Silos Break Down at Scale

In small startups, a functional structure can sometimes work—especially if the technical founder can personally manage all prioritization decisions. But as the business grows, this model quickly breaks down.

The R&D leader becomes overwhelmed, unable to see all the work or allocate capacity accurately. Developers are frequently moved between projects, losing context and motivation. Daniel Pink’s core drivers of autonomy, mastery, and purpose start to erode, and your best people burn out.

Cross-Functional Teams Are the Foundation of Scale

In a cross-functional structure, each team includes:

• A product manager (the driver and owner of the product lifecycle)

• UX designer(s)

• Software developers with the right skills (e.g., front-end, back-end, full-stack)

• Dedicated or shared support from DevOps, infrastructure, infosec, and other specialized roles

This structure enables your teams to:

• Translate corporate goals into actionable objectives

• Take ownership of product features and services

• Prioritize their own work in alignment with broader goals

• Estimate capacity realistically across all disciplines

• Communicate and iterate faster

With cross-functional teams, the PoR process can scale—because prioritization happens closer to where the work is done.

What About Shared Functions?

Most organizations have shared R&D resources—teams like DevOps, infrastructure, infosec, data science, or research—that serve multiple product teams.

That’s not a problem. But it is something you need to plan for. These shared functions must either be embedded in cross-functional teams, or their dependencies must be explicitly tracked in the PoR.

If multiple teams are competing for the same resource pool—say, a data science team of three—you need visibility into how those resources are allocated, and what that means for delivery timelines. Otherwise, prioritization breaks down at the seams.

Start Where You Are — and Be Ready to Adapt

You may already have a partially cross-functional structure. Many companies have adopted the team models described in Marty Cagan’s Inspired, with a reasonable ratio of product managers, designers, and engineers.

That’s a great start—and it’s usually enough to launch a working PoR process. But if your PoR is going to capture all the work across R&D, including shared functions and internal dependencies, you may need to evolve your team structures further.

As always, treat the PoR process as a living system. Start where you are. Then adapt.

Up Next: If you’ve decided that a PoR prioritization process will help your business prioritize resources to achieve your goals, and you’ve started to build the necessary culture for success, it’s time to start building your PoR process. In the next section, we’ll get practical about how to get started.

This framework becomes the shared language of your product and engineering teams, and ideally your whole company. It ensures that work items entering the PoR are grounded in actual customer needs—not internal assumptions or top-down wishful thinking.

Your Framework Should Inform Requirements, Not Just ROI

Let’s clarify an important distinction: your customer-centric framework is not the same as the tools your CFO uses to evaluate return on investment (ROI).

ROI analysis helps justify investments. But it doesn’t define what the customer actually needs—or what they’ll pay for and use in their context. When product work is prioritized solely based on market size or hypothetical returns, the team often ends up building features that never get adopted.

This is especially common during major tech shifts—like the rise of generative AI—where teams rush to invest in what’s trendy, rather than what’s truly useful. The result: lots of shiny demos, very little traction.

Use a Framework That Starts with the Customer’s Job

The best way to avoid this trap is to base your prioritization on the jobs your customer is trying to get done in their world, using their language. That’s why I recommend Clay Christensen’s Theory of Jobs to Be Done.

Here’s how Christensen describes it:

“You don’t have to leave your fate to luck. Successful innovations don’t result from understanding your customers’ traits, creating jazzy new bells and whistles for your products, catching hot trends, or emulating your competitors.
To elevate innovation from hit-or-miss to predictable, you have to understand the underlying causal mechanism—the progress a consumer is trying to make in particular circumstances. Welcome to the Theory of Jobs to Be Done.”
(Competing Against Luck)

Start With the Job. Prioritize From There.

Customer frameworks like Jobs Theory allow you to capture what your customer truly needs—and that’s the foundation for creating product work that matters.

Later in the PoR process, you can evaluate the impact of that work using market size and ROI frameworks. But those are downstream from the customer’s job to be done—not a substitute for it.

Up Next: In the next post, we’ll examine the fourth and final prerequisite for an effective PoR: Cross-Functional Team Structure.

For most SaaS businesses, those goals start with financial objectives: topline metrics like ARR growth (retention, upsell, and new bookings), and bottom-line metrics like profitability and cash flow. But financial metrics alone aren’t enough.

People don’t come to work motivated by ARR and EBITDA targets. They want to know why those targets matter.

Tie the Goals to the Mission

Great leadership connects the dots between the business’s mission and its financial imperatives. A cybersecurity company may aim to enable trust in an increasingly digital economy. A sustainability platform might aim to accelerate the transition to clean energy. These are missions that inspire.

When the PoR is rooted in these missions—and cascaded clearly into R&D objectives—teams feel aligned, empowered, and motivated.

Cascade the Goals into Actionable Objectives

The connecting tissue between the company’s high-level goals and the work inside your PoR is the set of R&D objectives that cascade down. These objectives must:

• Translate ARR and profitability goals into technical, product, and engineering priorities

• Exist at a level granular enough to guide specific project and resourcing decisions

• Enable R&D leaders to make prioritization calls without escalating every trade-off

Without this cascade, the PoR loses its footing. Teams can’t connect their daily work to the company’s direction, and executives can’t rely on the PoR to drive outcomes.

Spend the Time—It Pays Off

In practice, this takes real collaboration—especially if your R&D functions (product, UX, engineering, research) report separately to the CEO. But the investment in shared goal-setting pays off. Teams work better when they’re clear on what matters most—and what can wait.

It’s important to make sure that your goals cover all of the aspects of work for the R&D team. It is very easy to create goals based on the delivery of roadmap items because they are so obvious to the business. But R&D teams for SaaS businesses include many different roles that contribute to the corporate goals in ways that are not always so obvious.

Spend the time to cascade goals in a way that includes all of the functions of your R&D team. For a typical SaaS business, your R&D teams will contribute to one or more of the following three, simple high level R&D categories:

• building products and services (new products and features),

• supporting products and services (firefighting, platform modernization, maintenance, bug fixes and technical support) and

• delivering products and services (devops, infrastructure and infosec).

Then, you can help the team understand how building, supporting and delivering products and services contribute to the achievement of one or more of the three different categories of corporate goals:

• revenue goals (retention, upsell and new),

• profitability goals (cost of service and operating expense targets) and

• operational goals (communications, reporting and process).

Up Next: In the next post, we’ll cover Customer-Centric Frameworks—a vital tool for ensuring your prioritized work actually delivers value to users.

If you’re trying to implement a Plan of Record, you can’t ignore these fractures. A PoR prioritization process depends on a foundation of trust.

Here’s how lack of trust shows up in R&D organizations:

• Within Engineering: Distrust often forms at the boundaries between teams or technical functions—especially where dependencies and resource constraints exist. For example, developers may distrust how infrastructure, DevOps, or InfoSec allocate their time, leading to resentment and silos.

• Between Product and Engineering: When these two functions report to different execs or operate in silos, distrust can fester. Product may see Engineering as unresponsive to deadlines. Engineering may view Product as oblivious to technical debt and platform risk. The result? Best-efforts mode, constant firefighting, and missed commitments.

• Between R&D and the Executive Team: Even when product and engineering are fully aligned or even unified under a CPTO, a trust gap often exists between R&D and other executives. If sales and finance expect “everything is a priority” without acknowledging constraints, the R&D team may stop trying to communicate and may shift into quiet resistance.

• Between Executives and the Board: The same dynamics can play out one level up. When the executive team doesn’t feel safe being honest with the board, resource decisions aren’t surfaced. The board may default to vague mandates like “just make it happen,” and real prioritization never occurs.

Distrust breeds dysfunction. It’s the root cause of “best efforts” culture and chronic under delivery.

How to Build Trust at Every Level

There’s no silver bullet, but there is a proven framework. Patrick Lencioni’s The Five Dysfunctions of a Team and The Advantage offer a blueprint: trust enables conflict, which enables commitment, accountability, and results.

You don’t need to boil the ocean. Start where you have influence:

• If you’re a CxO: Diagnose trust across your org. Start where you can lead. Create psychological safety on your own teams. Model vulnerability and candor. Build upward to exec alignment and board conversations.

• If you’re a manager: Focus on your immediate team. Create a culture where individual contributors can speak up, say no, and trust that their constraints will be heard. Even a personal PoR—where one employee maps their own time and tasks—can foster clarity and respect.

Trust scales. A team that learns to speak truthfully about capacity and constraints is a team that can commit. And commitment is the foundation of any functioning PoR.

Up Next: In the next post, we’ll look at the second prerequisite: Clarity of Goals—the “why” that ties your PoR to your company’s mission and value.