Objective-Based Product Planning
Product planning is the process of translating strategy into a concrete, actionable plan. While strategy defines direction and intent, planning focuses on sequencing work, allocating resources, and making trade-offs across competing initiatives. A strong product plan ensures that day-to-day execution remains aligned with strategic goals.
Product planning is often confused with roadmapping or backlog management. In reality, it sits above both. Planning provides the structure that informs what ultimately appears on a roadmap and what work is prioritized for delivery.
Planning Hierarchy
Product planning typically follows a hierarchical structure that connects strategy to execution. At the highest level are objectives, which articulate the outcomes the organization is trying to achieve. These objectives are supported by themes, which represent areas of focus or investment. Themes are then broken down into projects (aka initiatives) that teams can execute.
This hierarchy helps ensure that work at the execution level can be traced back to strategic intent. While the details of requirements definition and delivery planning are separate activities, they should all flow from this shared structure.
Note – I prefer not to use the term “initiative” here, and reserve that for uber projects that are cross-team and last 6 months or more, encompassing mulitple projects (aka Epics).
Objectives
Objectives define the outcomes that product planning is meant to achieve. They are the starting point for defining the strategy and typically define an outcome that is desired for a given period of time. A metric and sometimes a target can be used to define these in a crisp and measurable way. OKRs is a popular framework and can work well in, both in terms of how goals/objectives are defined, but how to the cascading of those goals works within an organization to ensure alignment.
Product objectives are typically framed in terms of customer value, business impact, or both. They’re optimally expressed as outcomes (not outputs) for the product in terms of acquisition, engagement, retention, or monetization.
Themes
Themes represent the major areas of focus that support one or more objectives. They help organize work into coherent lanes and provide context for why certain initiatives are being pursued.
Themes are intentionally broader than projects. They allow teams to explore multiple approaches to achieving an objective without committing prematurely to a specific solution. In this way, themes act as a bridge between strategic intent and execution.
Projects
Projects (Aka “Epics” in Agile speak, or “Initiatives” in others) are the concrete deliverables that teams plan and execute. They are typically scoped pieces of work that contribute to one or more themes and ultimately support higher-level objectives. We’re typically looking to plan at this level for the roadmap, and this could realistically be something that lasts anywhere from a 6 weeks to 6 months. Items smaller than this typically are stories (not Epics/projects) and would just go into the backlog directly, not requiring the same planning or definition rigor (eg PRD). The process I’m describing here is really for the items that are Project/Epic in scope or large.
Prioritization
As we think about prioritization, an approach that I really like is to use a rubric-based scoring model, whereby projects are evaluated for their impact (1-5) on objectives, to inform impact. This assumes we have already defined our Objectives/Goals and aligned them with the organization, as described above. If that’s not already done, go back to that step before proceeding.
In this example, I’ll use a weighted impact scoring model, which gives a different “weight” (aka importance) to the objectives we’re tracking. Each project is the scored against objectives and then a weighted score for each project can be calculated. This impact score is then ultimately compared to an effort score (1-5). Once you have the impact and the effort scores, you can determin the relative net value of a project (value = impact – effort).
This approach creates a more objective and transparent method for comparing initiatives and understanding trade-offs. While no scoring system is perfect, this approach anchors prioritization to the outcomes you have already aligned, which helps reduce bias and ensures that decisions are anchored in strategy rather than opinion.
There are of course many popular prioritization models (eg ICE, RICE, MSCW, etc). What’s nice about the weighted impact matrix shown above, is that you can distill the score into a value which you can compare against an effort estimate — and this can be visualized on a 2×2 grid (impact vs effort). This makes it very easy to see which projects are going to drive the greatest value (Value = impact – effort).
Regardless of the model used, the most important factor is consistency, which enables the relative comparison of opportunities. Whatever approach is chosen should be applied uniformly and grounded in clear objectives. Without this discipline, prioritization frameworks quickly lose credibility.
The Product Roadmap
The product roadmap is an output of the planning process, not the plan itself. It reflects prioritized work over time and communicates intent to stakeholders. And roadmapping is the act of ‘orchestrating priorities against available resources, in order to paint a picture of what you plan to build in order to drive the outcomes that are expressed by your objectives.
Roadmaps should be flexible and outcome-oriented. Rather than serving as rigid commitments, they should communicate direction, sequencing, and rationale. When planning is done well, the roadmap becomes a natural expression of strategic priorities.
Socializing the Plan
Once a product plan is created, it must be communicated and validated. To ensure alignment and minimize confusion, start with your team and calibrate as needed. Once your team is aligned, you can go out layer out to your closest stakeholders that are advocates for items on the roadmap.
Finally, once you have aligned with stakeholders and reconciled any exceptions, now you can finally begin socializing the plan with leadership and any important customers that you need to share with. It its important to go in this order, to minimize confusion or perceived misalignment along the way.
Wrapping Up
Product planning is the mechanism that turns strategy into action. By defining objectives, organizing work into themes, prioritizing projects, and communicating intent through a roadmap, teams create alignment and focus. When done well, product planning provides clarity without rigidity. It enables teams to make informed decisions, adapt to change, and deliver meaningful outcomes for customers and the business.