TL;DR

In this post, I am sharing with you my playbook for running a planning process that you, as a VP or Head of Product, can use to empower your engineering teams through the art of inception. Empowered teams identify and prioritize the most critical problems to solve. By empowering your engineering teams in this way, you can help them take ownership of the problems they are solving and drive meaningful progress. This is the process I have been using as a Product Manager at Meta (pka Facebook) over the years.

As product managers, it is our responsibility to empower engineering teams to have ownership over their work rather than convince them to work on predetermined specific tasks. In my view, when engineers have all the necessary context and information about a set of problems, they are better able to prioritize, come up with solutions, and most important – be motivated. A great way to motivate people is by encouraging them to come up with their own ideas on how to solve the most important problems! 

The real question is how give engineers the freedom to feel creative and engaged while focusing on business impact?! The answer is – Inception. In this section below, I will provide a step by step process to help provide the teams all the needed context to have them come up on their own with the right problems to solve -> and from there find the most impactful solutions. 

Let’s get started.

The Process

The strategic planning process is typically done on a quarterly or half-yearly basis.

The process should take between 2-4 weeks depending on the number of teams/stakeholders involved.  While the duration of planning lasts 2-4 weeks, it doesn’t mean everybody stops working, most of the planning work is on the product, cross functional (data, design,…) and engineering managers. 

The planning process can be broken down into 5 stages

1. Pre Planning Kickoff
2. Planning Kickoff
   1. Logistics
   2. Retrospective
3. Initial Roadmap Review
4. Final Roadmap Review
5. Detailed Work plan Review

Let’s deep dive into each phase.

1. Pre Planning Kickoff

The pre-planning kickoff is a meeting to “plan the planning”. The meeting goal is to strategize and coordinate the logistics of the planning process: determining key dates, locations, and deliverables, as well as establishing relevant messaging and document templates. The steering committee typically consists of the head of product, a senior project manager, the head of engineering, and cross-functional leads such as design, data, research, and customer support.

The main action items of the pre-planning meeting are to:

1. Schedule Planning sessions

Meetings are scheduled in the calendars with the attendees lists, meeting rooms, virtual call links. I recommend allotting a 2-4 weeks duration from beginning to end of the planning period.   Try to avoid scheduling just before holidays, re-orgs, and any other major event that can interrupt the planning flow.

2. Start preparing content for your kickoff presentation

 Ensure each member of the steering committee understands what content they will need to present in the planning kickoff session with the entire team to provide the broader eng team with context for the planning and brainstorms. 

The head of product should prioritize the content and presentations that will provide the team with the context they need to understand the top problems to solve . The content can vary depending on the type of industry/vertical/company. Some examples for content that could be useful for the engineering teams/pods to understand in order to prioritize their work independently:

1. Company Priorities – The CEO/other leadership roles can present what are the top/key objectives priorities for the company as a whole (beat competition/introduce new product line/be more efficient/…) 
2. Data Narrative – A data scientist/analyst would need to start working on a presentation to be presented in the planning kickoff to the engineering/company. 
3. Competitive Landscape – A PM/Tech Lead to prepare a competitive landscape analysis (what others are doing)
4. Design Vision/Audit –  Designer can prepare a design vision/design audit of areas with opportunities for improvement
5. Customer support insights – A product/customer support can present top feature requests, top bugs reported, top FAQ
6. UX Research Insights – A product/UX researcher can share insights from surveys, user testing, user recording sessions (fullstory/hotjar/…),  user interviews
7. Customer Story – A customer can be invited to give a talk about a day in the life
8. …

3. Communicate a clear timeline

 to explain where we are in the planning process. See example:

The purpose of the review days is to streamline the process of identifying and addressing areas that need further alignment and review by providing a dedicated time for leadership and attendees to focus on these issues. This helps to reduce the number of ad hoc meetings and miscommunications, and allows for more thorough review of these issues at a later, more mature touchpoint.

2. Kickoff

The kickoff day is a crucial part of the planning process and is meant to identify the most pressing issues to focus on. The kickoff day includes the entire team/company. The kickoff day should begin with a session outlining the logistics of the planning process, including timelines, roles, and responsibilities. After the logistics, different members (who were assigned in the pre-planning session) will present on contextual topics. A sample schedule for the kickoff day might look like the following:

Ideally each session is live streamed, recorded and slides are shared publicly on the calendar invite and on Slack/Microsoft Teams or any other work platform you might use.

3. Initial Roadmap Reviews

About a week after the kickoff day, the initial focus areas review day should take place. During this day, representatives from  different engineering pods/squads/virtual teams (usually a tech lead and product manager – depending if this is a cross team objective or not)  will present a retrospective for the previous quarter/half as well as an early outlook on the main areas of focus the team is considering tackling.

After getting all the context, understanding the users and their top problems, this is the point in which each team can start their own planning cycle.  Before jumping into what’s next, it’s always good to stop for a moment and conduct a high level retrospective look at what worked well last half/quarter vs what could be improved. I usually like to collect some wins/highlights to celebrate and also include lowlights we can learn from. A good retrospective helps the team to not make the same mistakes again and in the context of planning, a retrospective could also mean where we didn’t go a good enough job and we need to double down or where we should probably not invest anymore given the investment didn’t yield the results we expected.

When reviewing the work focus areas, this is the time to understand which areas of work are likely to continue over the next half vs those we should stop/finish working on. This is important to understand what would be the capacity of the team for the next half. 

3.1 Retrospective

The expected deliverable from this stage is usually a document that includes the following sections:

• Previous Half executive summary –  with paragraph per focus area (examples from the mobile world:  mobile growth – moving from mobile website to native app / app start-up time / query latency / mobile gantt view /… )
• Progres vs goals summary – usually a table format that summarizes the focus areas with (on/off track, updated metrics value vs target for the half)
• Highlights – celebrate wins (e.g “We hit our DAU metric for the half!”) 
• Lowlights – learn from things that didn’t go as planned (e.g “ Even thought we improved  our performance  metrics, when we conducted UX research – users didn’t seem to notice the difference and there was no significant change in user perception”) 
• Learnings – things we learned that didn’t necessarily come from a lowlight (for example: “Capacity became a huge problem for the company. We should understand this space better”)

Example of a progress vs goal summary for a growth team:

Focus area	Goal	Metrics	Current Status	Original Target	Status	Should we continue to Invest Next Quarter/Half?
New Users	Increase new users retention	WAU@14 – Weekly active users 14 days after registration	78%	70%	On track – Target Hit!	NO (We suggest to double down on moving existing users to mobile native app)
Move to Native App	Increase engagement of existing mobile users by moving them from mobile website to native app	% of WAU with primary interface = native	40%	Establish Baseline	On track – Baseline established	Yes
Notifications	Increase stickiness and resurrections	DAU/MAU	47%	50%	Off Track	YesWe have several more projects we believe can bring us to 56%

3.2 Outlook into next half

To determine the most impactful areas to focus on, the team should conduct a thorough due diligence process and provide evidence to support their decisions. The team should also provide answers to the following questions:

• Why is this important?
• Who is the customer?
• What is success?
• How can we measure this?
• What should be our target?
• What is our level of confidence in the problem space? 

Example:

“Moving existing users to Native app  – today our primary mobile interface is the mobile web interface with 80% of WAU of mobile users with the primary interface of ‘mobile web’.  Our data shows correlation between users who became native app primary and increased engagement and retention. Therefore we recommend a growth strategy of pushing/moving people to become native app primary. “

An example for a review day:

Ideally each engineering pod/team should send their roadmap plan document as a pre-read document 24-48 hours before the review meeting with leadership (head of engineering, head of product, relevant business lead, head of analytics/design/…). Having leadership/senior stakeholders attend both initial and final roadmap reviews help identify areas with misalignment and they have another touch point to follow-up (a week after initial roadmap review).

The review meetings will take place in the same physical/virtual room where leadership will spend the entire day. The first 5-15 minutes at the beginning of each session should be dedicated to reviewing the roadmap/pre-read document sent to make sure everyone has the context they need to make the meeting as effective as possible.

Every session will be hosted by a different speaker and the participants will vary accordingly. Participants should include at the very minimum the engineering, design and product members who are a part of the same pod or that share an objective/ goal. Cross functional members (data scientists, data analysts, business analysts, UXR, PMM, etc.) who work on the domain should be invited to the relevant review as well.

4.  Final Roadmap Review

• After following up on the action items and the feedback received in the initial Roadmap review, in the Final roadmap review the team should present the thought process and prioritization framework – this is the time to call out what the team is also NOT going to work on. 
• By the end of this stage, the team should have a list of several focus areas (usually 2-3 engineers per focus area) with clear definitions for success and metrics. Good metrics are not just ‘Ship 0->1” but should describe the outcome from the launch. (e.g If we introduced a new feature that allows to create a new type of object let’s say a project or task, we should not just measure the completion of the feature, we should measure the usage in terms of Production or % of customers who created a high quality project. A possible metric could be the number of original artifacts created / Weekly Active User) 
• At this stage the team should have a draft goals dashboard with a widget for each metric. 

5.  Detailed Work plan

Once all the focus areas are finalized and the team receives alignment from stakeholders, at this stage the team can go into detailed planning, breakdown or projects into t-shirt size, understand engineering availability and come up with timelines. 

Ideally  we should have both effort estimation (T shirt size S,M,L,XL ) and potential impact sized (e.g Project X is estimated to contribute +5 percentage point to our main metric) 

The detailed engineering plan should take into account capacity/availability and buffers including holidays, personal time off, leaves and buffers. 

During this phase what is more likely to happen is to have another round of prioritization where several items might get deprioritized as a result of the more diligent capacity. 

Summary

The adoption of the planning inception playbook significantly increased the level of engagement of the engineering team in the process of building the roadmap and setting goals and metrics. Both senior and junior engineers felt included in the process and were given the opportunity to present their areas of focus and explain why they believed they would have an impact on the company. This shift in responsibility allowed the me as a product manager to focus on long-term planning and strategy, while also ensuring that the entire team shared a common goal of success and ownership in achieving it.

Photo by Jason Goodman on Unsplash