What is Product Planning?

Product Management Guide

Product planning is the process of determining the right things to work on, to make the best use of available resources, in achieving the stated goals of the product strategy.  A lot of the magic of determining the right items to work on comes down to clearly defined goals and an objectified approach to scoring opportunities in terms of how well they help us to achieve our goals. Once we’re clear on our priorities, putting a roadmap together becomes a more straight-forward process, based upon available resources, market, and internal timing, etc. 

The Planning Hierarchy

To align our efforts and resources toward the achievement of our product vision (a key output of our product strategy), it is helpful to think in terms of hierarchical layers that planning that connect our vision to every incremental task that a team works on during product development.  

For purposes of product planning, we assume the Product Strategy is already complete and the Product Vision is available as a starting point for our planning activities.  We also assume that the more tactical details of Requirements Definition is a separate step in the process.   For Product Planning, we’re specifically interested in defining the Objectives, Themes, and Projects that will be shown on our roadmap.  Just like the Product Vision was the output of our product strategy, the roadmap is the output of our product planning efforts.

Objectives

Whereas Business strategy sets broad goals and metrics, Functional strategies (like Product Strategy) use more specific Objectives that follow SMART principles (Specific, Measurable, Actionable, Relevant, Time-Based) as well as more specific metrics (KPIs) that can be directly attributed to the efforts of our functional strategy.   

It is important that Product develop its own functional strategy and not simply work from the business strategy directly.  One reason is that the broad business goals are often contributed to by multiple functional groups – the Marketing and Product functions may both contribute to increased conversion rate for example, and so we need to develop more specific objectives and isolated metrics/results that we can isolate and measure.   Another reason is that Business strategy is inherently focused on value capture and their goals/metrics will reflect that. Product strategy is rooted in created value for customers though (not capturing), and so we must balance these two perspectives. 

Themes

Similar to a composition, there may be a handful of broader themes that a number of the features we identify, will coalesce around, as threads through the fabric of our roadmap.  It can be helpful to identify these themes in order to think about how much we want to emphasize one theme over another, and balance our allocation of resources across these themes.   

In larger scaled Product Mgmt teams, we may have several Scrum teams working on the same product, in which case those themes become the basis of forming those teams.  For example, you might have a Scrum team with a Product Owner working on features for checkout whereas another team is responsible for signup. Teams setup in this way are sometimes called “feature teams” and Product Owners responsible for feature definition for these teams are said to own a feature, a “problem space” or a “focus area”.   There might also be a temporary “initiative team” setup when intensive support for an initiative is required for a period of time. All of these terms are essentially referring to the same thing however – thematic clustering of related features, in the overall product plan.

Projects

Projects are the units of work that are typically 1-3 months in duration, similar to an Epic in Scrum.  In Product Development, these are usually feature projects which create a new ability of our product that is valuable to our customers, but it can also be an effort to refine an existing feature, optimize a conversion funnel, or to perform infrastructural work that may not be visible to the customer. These projects are a reflection of the opportunities that are identified during Opportunity Discovery, as incremental actions we take to achieve our objectives.  

A Project is a container that describes the complete increment of value and all of the activities required to achieve it, such as UI discovery/design, development, and data modelling.  For the purposes of planning, we just need to identify what those projects would be.  

Prioritization & Alignment

Now that we have our Themes and Objectives in place, we can begin to score the projects that we’ve identified as candidates for our roadmap.  The best way to do this is to line up those projects on a matrix and start scoring each project for how well they’ll impact the stated objectives.  You can also weight these objectives, if you want to bias toward work that supports one objective/outcome over another.

This will provide a clear view as to which projects will impact the stated objectives most.  We’re not done yet though – we also need to consider the effort/cost aspect, in order to get the full picture of ROI (impact – effort = value).  To achieve this, we’ll need to normalize our Impact scores down to a 0-5 score and then work with our teams to estimate-level of effort with a 0-5 score.  Once we have both of these values for each project, we can do simple arithmetic to see the Net Value score for each project and stack-rank them accordingly. 

Once this is done, it is easy to see which opportunities are more impactful than others – they can even be plotted on a plane to better visualize the best opportunities.   This approach also makes your priorities easy to discuss, more defensible and facilitates more productive conversations with your sponsors, stakeholders, and customers.

Other Prioritization Models

No model is perfect and one criticism of this approach is that the 0-5 scoring is subject to personal biases as compared to more precise financial modelling as might be done with Net Present Value (NPV).   NPV is not perfect either however and is a lot more work for estimating the value of each project. This level of rigor is typically at the business portfolio level and analyzed in conjunction with Finance at that level, not for determining project priorities at the Functional strategy level.  

Other models such as RICE and ICE have gained in popularity, though neither provides the same level of alignment back to the Product strategy, as provided with the Objective-Based Scoring method. Whatever model you use however, the important thing is to have an objectified approach to scoring and prioritization, to avoid the trap of allowing opinions and politics drive your roadmap. 

Roadmap Planning

It is time to begin working on our roadmap!  At this point, we have a prioritized list of projects and we need to start figuring out how to layer those onto our roadmap. The process of roadmapping thus, is primarily about organizing and orchestrating projects, so they align with our themes, availability of resources, and any market or internal events that we need to line up to.  

We’ll generally try to plan high-priority projects first, but it’s possible there are superseding considerations that may cause us to prioritize something else ahead of it.   For example, we may need to complete a project already in flight, so that a shared resource can roll off of one team and go support another team. Or, we may need to support a business initiative with an integration of a new capability in Q1, and since that has a hard-date everyone is aligned to, we’ll put that first and then move on to the priority project.  

Themes as Lanes

Those themes that we defined earlier can we used to create streams of value/work that cluster around meaningful aspects of our product.  And, if you’re working on a scaled product team for which there is a different Product Owner and Scrum team working on each theme, this can also be a nice way to see the roadmap for that team.  A word of caution however – remember that the purpose of a roadmap is to describe feature/value creation in broad strokes, not to act as a Gantt chart, describing what everyone is working on.  If for example, you have two contributing teams working on different aspects of the same feature, it really only needs to be expressed once, according to the value theme it is associated with; it doesn’t need to be shown twice, reflecting the teams working on it. 

Socializing the Plan

Once the plan is created, it needs to be socialized with business sponsors, stakeholders and key customers, to field any feedback or ideas that might come out.  This is a process sometimes referred to as the “Product Roadshow”, since it is making multiple presentations of the roadmap to different groups.   

Product can be inherently political since it sometimes means having to make choices to prioritize one effort over another with your limited resources.  For this reason, it’s good to think defensively about how you approach it. Start with those closest to you and share the plan with them – your partners and the development team. Do they have any concerns, ideas, or feedback?   Once you’re feeling good here, you can proceed to stakeholder partners to do the same, and once that’s feeling good, you’re ready to share with your executive leaders and perhaps any key customers after that.

Planning Horizon

Context dictates how distant of a horizon to plan to – typically it will be something between 6-12 months, with a quarterly refresh cadence.   Most larger organizations find themselves locked to the annual cadence of their organizations operating and budget planning cycles and thus they need to plan 12 months ahead.  Companies building physical products may have a more sophisticated materials planning cycle and might have a roadmap that looks 2-3 years into the future. In contrast, Agile/Lean tech startups often advocate for not even having time-based roadmaps, because they’re still actively discovering market fit and making radical pivots as learnings surface.   

As a rule of thumb, try to plan as far out as you reasonably can see a clear horizon – mature products are much easier to predict and involve more complexity that benefits from the longer-term planning.  Startups in active market-fit discovery might benefit from simply using a Lean Plan instead (Now, Next, Later).

Conclusion

Product planning is the connective tissue between the product strategy and Product Development – It is the orchestration layer that translates a high-level product vision into prioritized projects for the development teams to work on.  By taking a top-down approach to identifying appropriate objectives, themes, and projects, we can ensure resources are optimally aligned to realizing our strategy. Techniques such as Objectified-Based Prioritization and inside-out roadshows meanwhile, not only keep us honest about the validity and alignment of our planning but also defensively mitigate risks of a misaligned plan.