Objective-Based Prioritization

“Plans are nothing; planning is everything.”  – Dwight Eisenhower

Planning and prioritization can be political.  Implicit in creating a plan is that some endeavors are more important than others and thus some projects & initiatives are prioritized ahead of others.  When that happens, passions can flare and internal maneuvering begins.  But this doesn’t need to happen – when the process is objectified and properly aligned, the plan becomes a rational response to business and customers needs, which fundamentally changes the conversation to something much more constructive.  Below I’ll share the approach that I’ve developed, which has helped immensely in this regard:

An abstraction of the Product prioritization process looks something like this (above):  ideas come in from many directions, including our research, stakeholders, competitive analysis, broader business and corporate initiatives etc.  We collect these ideas perform some sort of cost/benefit analysis, determine priority and then put them on the roadmap.  I think the majority of this flow is common to most organizations.  The part I’d like to focus on that I think a lot of teams miss, is the prioritization segment (steps 3 & 4).

Roadmap vs Backlog

The first thing we need to do, is look at all those inbound ideas and determine which are roadmap candidates versus backlog items.  I’ve heard some teams cleverly refer to this as “pebbles & stones”, meaning some items are small pebbles, whereas others are larger stones (that will eventually be broken down into requirement ‘pebbles’).  Because there are so many pebbles in our backlog, I don’t think what I’m going to share here will scale well for every single backlog item.  So, the first thing I do filter out the items that seem to be X-Small and put those directly into the backlog, exempting them from this prioritization process (we’ll handle those differently a little later when managing the backlog).

In terms of where I draw that metaphoric line between pebble and stone, I prefer to roadmap in ½ quarter increments, meaning that anything requiring more than ½ a quarter of “person time” should be accounted for on the roadmap.  That is large enough to require more explicit cost/benefit analysis and communication about how those team resources are being applied.

Objective-Based Planning

Next, if we haven’t already, we need to define our strategic objectives for the period of time we are planning for.  Ideally you’ll already a clear mandate from Business in terms of what this product is intending to achieve and a defined Product Vision that responds to that and the needs/desires of customers.   From that you can begin to infer the appropriate objectives you should be trying to achieve, and begin that conversation.

The beautiful thing about defining Objectives at the outset is that it becomes the basis of alignment with Business and empowers Product to drive prioritization, knowing what will be aligned and supported.  When this step is skipped, Product will often make assumptions and develop a plan accordingly that is out of step with expectations, which undermines confidence in Product’s ability to drive strategic planning, and will lead to dissension amongst stakeholders or worse, the CEO mandating the priorities to Product. Getting aligned on the underlying objectives from the outset fixes this.

There are a couple other benefits to this approach as well – not only are you clear and aligned on the strategic ‘North Star’ that you are chartered to achieve with your product, you also now have a built-in defense against attacks from contributing Stakeholders who want their special feature prioritized.  By taking this approach, you re-position yourself from being an opinionated equal stakeholder in those conversations to an objective ‘steward’ of what’s best for the business and customers.  You shift from being an adversary defending a plan, to an advocate who sincerely wants to help every stakeholder who has the interest of the business and customers at heart.  When this is done well, the conversation changes from subjective opinions to objective alignment with the objectives.  Instead of “no” or “not right now”, the conversation shifts to “these are our aligned objectives for the year – can you help me to understand how your feature is more strongly aligned with one of these objectives than perhaps I’m seeing?”.

There’s one other really important aspect of objective-based planning worth mentioning:  it shifts the team away from a delivery orientation and more toward outcome orientation.  This enables Product team to take more of a leadership role in defining what to actually deliver, to achieve those objectives.

Also implicit in using objectives, is that we should have corresponding Key Results (eg OKRs).  Key results are essentially Key Performance Indicators (KPIs) that are just metrics by which we can measure our success in achieving the stated objective. You may have more granular KPIs for specific endeavors but they ultimately role up to the high-level KPIs we define for these objectives.  This extends the alignment we’ve put into place for planning purposes, to the teams doing solution design and implementation – they know exactly what a successful outcome should look like.

Defining Objectives

Hopefully, I’ve convinced you that objective-based planning is the way to go!  If so, the next step is to define your own objectives.   First let me lay a little foundation of what an objective actually is:  an objective is a more specific and actionable response (ideally following SMART principles) to a high-level goal.  It’s important to keep in mind that there are different layers of strategy within an organization and Product Management is a business function (just like Marketing, or Engineering) that support the higher-level Business strategy.  To that end, Business hopefully provides us with some sense of the mission of the business and 3-5 high-level goals for the business each year.

These become the inputs then for each department to respond with their own functional strategy.  For Product that means we take those inputs along with our own understanding of customer needs and desires, and synthesize a ‘vision’ for what we want to build, typically with a 3-5 year horizon in mind.  On that basis, objectives are more specific and actionable responses to those business goals and customer needs/desires, that help us to move toward our longer-term vision.

Our goal here should be to define 3-5 objectives that are specific to our product and align with the Business goals and customer needs/desires.  Whereas Business may define a high-level goal like “Increase Revenue” or “Customer Retention”, we might define objectives more like this:

• Conversion Funnel Optimization  ← in response to goal of increasing revenue
• Introduce Monthly Subscriptions  ← in response to goal of increasing LTV
• Introduce new capability ← satisfies customer need and addresses revenue and LTV goals
• etc

Prioritization Scorecard

Once we have established the key objectives that we’re going to focus on for the period of time we’re planning for (typically 6-12 month timeframe), we can begin to line up all of the roadmap-sized ideas on matrix and begin scoring them accordingly to how well they align with our objectives.  This will ensure that every activity on our roadmap is prioritized according to how well it aligns with the strategic outcomes expected of business and aligned to our own Product Vision and objectives.

Not every objective is equal. We may want to weight some of these more heavily than others, to reflect what is more of a priority at the moment.  To that end, I provide a weighting (1-5) for each objective.  Each idea that we prioritize is then is then rated (1-5) according to how will it will “impact” that objective.

Note – these 1-5 scores are obviously coarse and subjective rankings in terms of alignment.  I find this to be the right balance between objective rigor and subjective simplicity.  There is a much more sophisticated (and involved) methods such as estimating Net Present Value or Estimated Commercial Value but this is more the domain of Finance and seems appropriate to me at a product portfolio level, not the Product plan for features level. 

Analyzing Impact vs Effort

Once you’ve scored the impact of each feature/project according to how it impacts your stated objectives, those scores can be tallied (total impact) and a weighted impact score derived so the highest scoring item is a 5.

Then, you can work with your team to determine a “Level of Effort” (LOE).   Agile teams often like to speak in terms of T-shirt sizes which is fine – those align nicely to a 1-5 score as well (ex:  XL T-shirt size is a 5 effort score).

Once you have a 1-5 score for both overall impact and effort, we can derive a Net Value score, which is simply Impact minus Effort (Impact – Effort = Net Value).   Note – Net Value is not the same thing as Net Present Value.  Once we have the Features/Projects properly scored, its time to analyze the impact vs effort.  Simplistically, you could just stack-rank your list according to descending Net Value, but that lacks some nuance – this is where planning becomes a bit of an art.

I find it helpful to line the scores up on a grid so I can easily see the items that are “Winners” (high impact with low effort) and the “Losers” (low impact but high effort).  The winners are the items we surely want to account for in our plan and the losers we can immediately dismiss unless there is some overriding consideration that makes one of those a mandate.   Where it gets more interesting are the gray areas between the two – the Big Bets and Incremental items.

Big Bets (high impact and high cost) can be beneficial to the business but we have to look at them in the context of the overall plan and not take on too many of them.  Ideally, we might set aside ~30% of our bandwidth for these large efforts which will propel us forward long term, but that we need to balance against delivering short and near term value.  The Incremental items (low impact, low effort) can end up having similar Net Value scores as Big Bets, which is why I prefer to not just stack-rank those, since you lose this nuance I’m describing.  I generally regard these Incremental items as ‘filler’ that we can fit in, where there are pockets of time on the roadmap between larger opportunities, or where they nicely line up thematically with another feature/project – by bundling those together you can help to pull those forward. .

Roadmap Orchestration

To me, this entire process I’ve described here is “roadmapping” and this illustrates just how much of building a great roadmap, is like an iceberg below the surface.  There is a lot of work that goes into ensuring we’re prioritizing the correct items and that effort is deeply intertwined in alignment with the interests of both the business and customers.

This last step is something I call “orchestration”.  We shift now from understanding strategic priorities to now sequencing those opportunities onto a plan.  We’ll start with the aim to approximate the stack-ranked priority list, and begin to ‘de-normalize’ that according to practical opportunities and constraints such as dependencies and concurrencies, as well thematic threads and any sort of events that we need to line up with.

Socializing The Plan

The last step is to socialize the plan.  You can have the best laid plan in the world but if stakeholders and your team are not aware of it, then the entire effort is for not.  You need to proactively share the plan, factor any feedback or details you may have forgotten, and let the world see that you have a plan to make things happen – if you don’t, others will begin to fill the perceived void.

Over time I’ve found it to be helpful to take a slow, building approach to sharing my quarterly updates (I do small iterative revisions each quarter, adding the next quarter on the horizon and adjusting for new insights and realities of progress, etc).  I like to start with those who are closest to me and share the plan quietly with them, similar to an Alpha release of a product.  The leads of my team can often see any issues first, and it’s also important that they’re on board with the plan before I go outside of the team.

Once I’ve factored any concerns here and I have their buy-in, I proceed to the leads of the other departments (my beta release).  This is often where they’ll ask me about their feature request and I’ll share the prioritization scorecard and we can have a conversation about how to score their request and make adjustments as needed.  Through this process, they should understand the plan and more important why, if their feature is not accounted for.  By having that conversation and addressing any misalignments there, I can ensure I am clear to proceed to the next step, without worrying about someone questioning the plan or calling it into question, when I reach Business leadership; one step at a time while I seek alignment and buy-in, as  I proceed up the ladder.  And finally, once everyone is internally aligned, we can begin to share as appropriate with key customers.

Conclusion

There it is in a nutshell – this how I use an objectified approach to planning, from the very beginning with ideas intake, to having a fully aligned roadmap that is ready to share with customers.  Objective-based planning is at the center of my process and simplifies the prioritization process but getting to alignment with the underlying objectives from the beginning.  By shifting one’s mindset from “ownership” to “steward” of the roadmap, it becomes clear why Objective-based prioritization makes the most since – the process doesn’t need to be a battle of wills and personalities.  If we’re truly thinking about aligning our efforts to the needs of the business and our customers, it becomes a much less contentious and much more straight-forward process.