Product Plans

Product-Focused Planning

Each planning cycle (currently quarterly), the overall goals come from the exec team to make sure we’re driving towards the destination we’ve set for ourselves as a company in our strategy and roadmap.

It’s the product teams – engineering and product together – that have the expertise, context and pride of ownership to be best suited to propose the highest impact work that fits those goals. And they’re the team that can do the correct eng scoping.

Per-team planning reviews are where we come together to ensure we’re happy with where we’re headed at each planning cycle. TPMs will pull together reviews for each team each planning cycle to include interested members of the exec team, the leads of the product team (at least the EPD triad) and other interested stakeholders. A planning review will consist of content to cover at least the following topics:

  • Retrospective: How well did we do in accomplishing our goals from last Q? What data do you have to support those conclusions?
  • Status: How well is the product serving the needs of our customers and the business? How well have you hit your metrics targets?
  • Plans: What work is being proposed for this planning cycle, how does it meet the business goals and how does it serve the needs of our customers? What data are you using to drive your planning? Have you done the high-level eng scoping to give you confidence that your team will be able to get the P0 work done in the time?
  • Success Metrics: what KPIs and targets have you set to measure the success of this work?
  • Risks/Open Questions/Needs: What are the biggests risks? What are the mitigations? What guidance would you like from the exec team? Do you have everything you need to be successful?
  • Excluded: What alternatives have you rejected for this Q and why? Will they be on the team’s roadmap for the future?

The purpose of the planning review is for each product team to present their proposed work for that cycle and to hear feedback from the exec team as to whether there is agreement about the direction and tasks that the product team’s proposals or whether adjustments need to be made. At the end of a review, the execs and the product team will either be in alignment about the work to do done that cycle or another review meeting will be scheduled to follow up until there is alignment.

Note, not every team will have work to do that applies to every goal every quarter. Likewise, not every work item is expected to meet a strategic goal.

Review Effectiveness

Some tips for having an effective review:

  • Make sure the priorities for your work is clear – what’s Must Have (P0), Want To Have (P1) and Nice To Have (P2)? What could get cut?
  • Make sure the customer (internal and/or external) impact is clear – if we do this work, what’s going to be the value to the customer?
  • Make sure the business impact is clear – if we do this work, how does that help us achieve our strategic goals?
  • In addition to ensuring that the EPD team is aligned before heading into the review, try to get as much alignment with execs ahead of time as possible.

I’ve noticed that the teams the follow this tips have a smoother review process.

Engineer Scoping

For any launch, we have a finite amount of time and a finite number of engineers. Before the PFP review, EPD should have done a high level assessment to ensure a high level of confidence in the P0 items in the work plan.

After the team’s plan has been approved, EPD’s detailed planning should include an “eng scoping” exercise, i.e.

  1. What is the eng effort associated with each of the P0 and P1 items, e.g. 2 days or 3 weeks or …? Here’s an example of one such exercise.
  2. Given the priorities and the eng effort required for each item, where do we draw the line of what we can accomplish for our launch? Ideally it includes all of the P0s. If it doesn’t, we have to mitigate.
  3. Mitigate the implications of the where the line between what we need (P0s), what we want (P1s) and our actual eng effort. Can we get all of the P0s in? If not, then what do we do? Continue cutting scope? Slip the release?

The eng scoping work is the difference between eyeballing a list of requirements and hoping we can get them all done and actually having some confidence that we can accomplish what we want. And if we can’t, we want to know that ASAP so we can cut scope for our release.


To make sure we’re talking about the same thing as we assign priorities to the items in our plans, we’ve adopted the following convention:

  • P0: Committed
  • P1: Stretch
  • P2: Uncommitted