Why We Needed a Prioritization Framework

Why existing operational frameworks are so valuable, and how we discovered a critical gap

Once we understood the symptoms and root causes, we turned our attention to the solution. But it turned out that no existing framework could solve what we were facing.

The Need for a Prioritization Framework

One of the pleasures of working in a startup is that the scale is small enough that problems are easy to spot and often relatively easy to solve through goal setting, prioritization, and strong communication.

When my startup, Rekener, was acquired in 2019, my co-founders and I were asked to take over the product development organization at Brainshark, including product management, UX design, engineering, InfoSec, and DevOps. Brainshark was a larger company with over 20 years of operating history. Within a short period of time, we observed many (if not all) of the symptoms I described in the previous post, and we began diagnosing the root problems.

At the same time, we also set out to implement the operational frameworks that we knew were essential to building a highly functional team. I’ve always believed in using frameworks to drive clarity and scale. Frameworks aren’t dogma — they’re distilled experience, captured in a way that can be shared and reused. They give everyone on the team, especially managers, a common language for making better decisions.

So, when we suddenly found ourselves leading a larger, more complex team with some very real challenges, we turned first to the frameworks that had served us well in the past. These included:

• Trust-Based Culture
  Patrick Lencioni’s model, from The Five Dysfunctions of a Team and The Advantage, provides a powerful framework for how functional teams behave. At its foundation is trust — which enables productive conflict, which in turn allows teams to commit even in the face of disagreement. That commitment then unlocks accountability and results. In The Advantage, Lencioni expands this into four “disciplines”: (1) a cohesive leadership team; (2) clarity of organizational goals and alignment; (3) consistent communication of that clarity; and (4) reinforcement through actions and decisions.

• Jobs Theory
  Jobs Theory was created by Clay Christensen and his research team at Harvard Business School. Christensen describes Jobs Theory in Competing Against Luck, which articulates the most practical framework I’ve found for identifying customer needs. It centers on the idea that customers “hire” products to make progress toward a goal in their context. If your products don’t help them succeed in that job, you don’t have a business.

• Team Structure
  Marty Cagan, in Inspired, provides clear recommendations for how modern cross-functional teams should be structured. In SaaS companies, this typically includes a product owner, an engineering lead, engineers with relevant specialties (e.g., front-end, back-end), and go-to support from DevOps, infrastructure, and InfoSec.

• Motivation
  Daniel Pink’s book Drive outlines the intrinsic motivators of autonomy, purpose, and mastery. In product development, these motivators apply directly. When teams understand how their OKRs connect to corporate goals, they develop a shared sense of purpose. When they have the autonomy to decide how to achieve those goals, they operate more effectively. And when team structures are stable, developers can build mastery — rather than being shuffled between initiatives and treated like “ticket-processing machines.”

At Brainshark, we applied these frameworks quickly to strengthen culture and improve delivery. But we also discovered that something critical was missing.

We needed a prioritization framework — and there was no existing playbook we could simply pull off the shelf.

We needed it immediately, for several reasons:

• Development teams were overwhelmed, but business leaders felt that little was actually being delivered to customers.

• We needed visibility into all the work, with rough estimates of the time required.

• We needed product and engineering to align on actual capacity for the coming quarter — and beyond.

• We needed to understand how much of that capacity was already committed: to stability, support, and customer escalations.

• And ultimately, we needed to communicate a clear and credible delivery plan to the executive team.

And we needed something that could scale.

This wasn’t a one-team problem. We were working in a complex business with a large installed base, multiple product lines, and numerous cross-functional dependencies. It wasn’t enough to prioritize informally or team-by-team. We needed a company-wide approach.

So, we created one. We built what we now call the Plan of Record, or PoR.

The PoR Prioritization Framework enables product management and engineering to jointly prioritize work and commit to a roadmap that can be communicated confidently — both internally to customer-facing teams and externally to customers and prospects.

While product management typically drives the PoR process, it’s not just a product tool. If the entire leadership team is aligned on the process and its prerequisites, the PoR becomes a unifying mechanism for planning, communication, and execution.

As we’ll discuss later, PoR depends on trust-based culture, clear customer understanding, and well-structured teams. That’s why it aligns so naturally with the frameworks from Lencioni, Christensen, Cagan, and Pink. Those frameworks — or reasonable alternatives — are prerequisites.

The PoR is the operating system that makes them all work together.

Up Next: In the next five posts, I’ll explain the five core elements of the PoR process.