Well-intentioned prioritization exercises can quickly go from pointless to delusional and actually harm the business your team is trying to nurture. It can happen early in budget or release planning or it can happen late in the development cycle when overly optimistic product plans meet the reality of what engineering can actually deliver.

“Product managers: we need to review your prioritized feature list. Let’s get one list from 1 to N and we’ll draw the cutline based on our budget.”

Clearly this is a call for help, but the answer isn’t to comply literally. Prioritized lists set false expectations that an arbitrary cutline will preserve meaningful business outcomes amidst the items remaining above that line. This holds true across the hierarchy of portfolio, products, goals, use cases, and features.

A single use case may be realized via several features in a product release. Arbitrarily removing one of those features that falls below the cutline breaks that use case. Other use cases may be preserved, but we won’t know simply by looking at individual features in a prioritized list. Each use case is an atomic entity that either works or doesn’t.

Similarly, I may have a business goal for my product such as increasing sales by supporting a new end-user process. Meeting that goal requires a set of use cases. Once we agree on the set of minimum viable use cases to fulfill the goal, they become an atomic entity. Breaking one of these use cases via a cutline will substantially degrade or outright deny our ability to meet the goal.

I’ve seen cutline prioritization and budgeting exercises occupy teams with busywork that fails to generate useful outcomes and merely consumes time generating 1-to-N lists that everyone knows are useless. Stack ranking products at the portfolio level is a great way to divert productive teams into manufacturing prioritization logic merely for its own sake and encourages political posturing versus substantive portfolio analysis.

Meaningful prioritization

Of course, prioritization is critical to the product management role. Beyond the reality that we can’t fund every ask, product managers have a fundamental responsibility to prune activities that are adding insufficient value so those resources may yield greater outcomes. Be clear on the minimum viable outcome (MVO) for your portfolio or product, rather than creating a simplistic stack ranking.

Apart from my MVO, of course, I may develop lower priority desired outcomes where a budgetary analysis can be used to establish a cutline. This prioritization must operate on atomic entities, preserving whole outcomes and enabling conversations about what varying funding levels can achieve for the business.

My CEO once tasked me with the goal of delivering a wholly new patch management capability that would allow my product to double its penetration within our largest customer and simultaneously address a resurgent competitive threat in our market. The goal was part of my company’s MVO and received substantial funding. However, we couldn’t satisfy every use case in the first release given time-to-market requirements and finite resources – nothing unique about that.

While identifying the minimum viable use cases required to meet the goal, we documented opportunities to deliver more value that would go beyond parity with other products and give our product a clear competitive advantage. Many of those use cases had to be deferred to subsequent releases. Yet, we succeeded in building use cases beyond the MVO that tied the new patching capability into existing product capabilities including compliance auditing, creating more compelling user experience and competitive differentiation than a standalone patch manager.

Though our prioritization analysis occurred at the atomic MVO and use case levels, we inevitably came across difficult trade-offs upon learning that certain features would take longer to build than expected. In one situation, we made the hard choice to delay the release rather than ship a compromised product with partial use cases that failed to meet our MVO. In another situation, we introduced a second release to phase in highly desirable use cases that were beyond the MVO, but which we knew would improve customer satisfaction and competitiveness.

Making the cut

There’s no way to avoid making tough priority calls, but the product manager must prioritize in a way that recognizes minimum viable outcomes rather than inadvertently undermining them with arbitrary cutlines. Don’t let an impromptu request for a prioritized list create a delusion at odds with your responsibility in guiding the organization towards viable business outcomes.