Product and Engineering planning philosophy

A good strategy provides focus

Our strategy documents how we plan to make decisions and tradeoffs to achieve our goals.

A good strategy has 3 components:

1. A diagnosis. This is an explanation of the nature of the challenge. A good diagnosis simplifies the often overwhelming complexity of reality by identifying certain aspects of the situation as being the critical ones.
2. A guiding policy. This is an overall approach chosen to cope with or overcome the obstacles identified in the diagnosis.
3. Coherent actions. These are the steps that are coordinated with one another to support the accomplishment of the guiding policy.

Recommended reading:

• Short article: The perils of bad strategy
• Book: Good Strategy/Bad Strategy: The difference and why it matters by Richard Rumelt

Good plans are clear and concise

In theory, a good plan contains:

• A definition of success that:
  • Is clear and succinct (so a variety of stakeholders can quickly understand what is important)
  • Is solution agnostic (so the team has ownership and space to find and pursue the best solution)
  • Is framed as a customer and/or business problem statement (so we are always working on the right things for our business)
  • Can be unambiguously measured and evaluated (so there is no disagreement about whether we have achieved success)
• A concrete set of deliverables we believe will solve the problem (so we can detect/manage dependencies and do capacity planning)

In practice…

• The definition of success is defined first and then there is additional work that needs to be done to figure out what the delivery plan is to achieve that success. The team might need to collect customer feedback, dig in to metrics, or build prototypes as a first step. This exploration is normal, healthy, and part of planning and execution!
• We sometimes aren’t at a level of maturity where we can define the perfect definition of success, so we find the best approximation and give context to communicate intent.

This definition applies recursively at every layer of a plan (for example: company plan, product/eng department plan, org plan, team plan) for a given unit of time (year, quarter, week).

Planning is iterative

Arriving at a good plan is an iterative process that is neither exclusively top-down nor exclusively bottom-up because there is a cyclical information dependency. Company level strategy is informed by what is working and not working about our business (context our teams have), and team plans are informed by what our company level strategy is (a decision ultimately owned by the CEO). Fundmentally, everyone on our team has context and insights that are valuable inputs into the planning process.

In practice, both the top-down motion and bottoms-up motion happen concurrently, but we need to bootstrap the process to iteratively work through the information dependency. It is helpful to think about planning as having a W shape:

Source: The Secret to a Great Planning Process — Lessons from Airbnb and Eventbrite

Planning is continuous and never done

At any given point in time we should have an idea of where we want to go in the absence of any new information, but we are always discovering new information and we should be open to adjusting our plan accordingly as we learn.

Done well, this feels like an organic continuous process where we periodically review the existing plan (as opposed to a discrete planning process that starts and stops).

Plans are ambitious and feasible

We want our plans to be ambitious so that we challenge ourselves to grow. Plans should be ambitious in a focused direction, not ambitious in the number of things we want to accomplish. Doing one thing exceptionally is better than doing multiple things not exceptionally.

Plans need to be feasible. A plan is feasible only if we can achieve it accounting for realistic conditions and expectations (for example: reserve appropriate amount of time for unplanned work). If a plan requires everything to go perfectly, then it is not feasible (because that is not a realistic expectation).

The right level of capacity to plan to depends on the team (size, health, maturity of the ownership area), but a good default is to plan to 80% capacity and reserve 20% capacity for reactive work (responding to bugs, incidents, customer requests). Planned work should contain an appropriate balance of multiple kinds of work.

Everyone can contribute to planning

Good ideas and code can come from anywhere; other teams, other orgs, even other departments or from open-source contributors. Be sure you’re welcoming to contributions from outside of your team.

Plans balance multiple kinds of work

There are three different kinds of work to consider when planning work: feature work, scale work, and risk work.

A good plan achieves a healthy balance between these kinds of work. Exactly what that balance is depends on circumstances and can vary over time, but it is important to not neglect any of these categories.

To balance work across these areas, it is important to prioritize based on the outcomes and expected impact those outcomes will have on our business and customers, now and over time.