When Priorities Collide: Diagnosing the Real Problem

How to be aware of the symptoms and look deeper for the roots of the problems

Before you can fix prioritization, you have to understand what’s broken. In this post, I’ll walk through the telltale symptoms that reveal when your business is out of alignment — and the root causes behind them.

The Symptoms of the Problem

After spending the first 20+ years of my career building startups or launching new ventures within large companies, I’ve spent the past decade working with SaaS R&D teams that strive to operate a strong, cross-functional product management lifecycle but struggle to make sound decisions about how to prioritize resources to meet business goals.

At three different SaaS companies, ranging in size from $10 million to over $200 million in annual recurring revenue, I’ve implemented the Plan of Record (PoR) prioritization process to address these issues. In each case, I was responsible for most of the technical resources of the business — including product management, engineering, software development, DevOps, InfoSec, data science, research, and user experience. Increasingly, this set of responsibilities falls under the title of Chief Product and Technology Officer (CPTO).

From these experiences, I’ve found that a Plan of Record process is especially helpful for SaaS companies suffering from one or more of the following symptoms. (How many of these have you seen in your own organization?)

• Dependency on the Installed Base.
  When retention is a top priority, the business constantly allocates resources to reduce churn. These efforts often include fixing stability issues, delivering long-promised features, or addressing support escalations — all of which compete with growth-focused initiatives.

• Technical Debt in the Platform.
  In businesses with aging platforms or monolithic architectures, modernization is essential, yet difficult to prioritize. Migrating to modern frameworks, updating old components, and retiring bespoke builds for legacy customers all require long-term investment, often at the expense of short-term wins.

• Juggling Multiple Product Offerings.
  Companies serving multiple markets or personas must constantly decide how to divide resources across distinct product lines, a challenge that spans R&D, marketing, and sales.

• Incomplete Transition to SaaS.
  Businesses mid-way through a SaaS transformation must choose how much to continue investing in legacy offerings that are not cloud-native.

• Engineering Dependence for Support Escalations.
  High support volumes and varying SLAs create tension between engineering’s focus on new work and its responsibility to fix broken functionality.

• Pressure to Build for Individual Customers.
  In competitive markets, building incremental features to win or retain deals can feel like the safest bet, but often comes at the cost of deeper platform investments or strategic bets for future growth.

• Operating in “Best Efforts” Mode.
  When overloaded teams can’t deliver on all priorities, they default to trying their best, without a realistic view of capacity. I refer to this as the difference between “best efforts mode” and “commitment mode.”

• Unclear Business Goals and Priorities.
  When corporate priorities are vague or frequently shifting, engineering teams often default to solving for the loudest customer, not the most impactful opportunity.

• Too Much Heroic Work.
  Companies relying on a few heroic product managers or developers are usually failing to prioritize effectively. These individuals burn out, engagement drops, and turnover rises.

• R&D Functions Like a Black Box.
  When product and engineering teams operate with little transparency, other teams outside of R&D struggle to understand how work is allocated or why delivery feels slow. In response, customer-facing teams start making promises on their behalf, compounding the problem.

The Roots of the Problem

As we developed the PoR prioritization process, we realized these symptoms often tie back to a core set of underlying issues, which we’ve seen across multiple organizations:

1. Corporate Goals vs. R&D Capacity.
   Even when top-level goals are clear, they may not reflect what the business can actually accomplish with its available resources, cash, and time. In SaaS, the “big three” goals — renewals, new business, and upsell — are all priorities, but not all can be weighted equally.

2. Lack of Clarity Around Capacity.
   Business leaders often see a large R&D spend and assume capacity is not a constraint. But the real capacity — especially across skill sets — is rarely visible, creating a disconnect in expectations.

3. Hidden Work.
   Shadow projects, untracked dependencies, and “quick favors” for sales or execs consume significant bandwidth. This hidden work often lands on the same engineers who already operate heroically — accelerating burnout.

4. Priority vs. Prioritization.
   Many business leaders interpret deprioritization as a declaration that something is not important. But even when all initiatives are valuable, resource constraints require them to be ordered — and some must be left out entirely.

5. Roadmaps Without Commitment.
   When teams aren’t aligned on capacity or scope, they fall into best-efforts mode. The roadmap becomes aspirational rather than reliable, and the business builds a habit of missing its own public commitments. This erodes trust and impairs planning. A PoR process restores clarity by tying realistic capacity to strategic priorities — and grounding the roadmap in commitment.

Up Next: I’ll review my favorite operational frameworks for high performance product development teams, and why they are so helpful for fixing what’s broken. I’ll explain why we needed to create the PoR Prioritization Framework to fill a critical gap.