Product Planning

The project planning documents I tend to use

High-level goals

Beyond covering the bases necessary to have a solid top-to-bottom plan, here are the key goals I want product planning to deliver on.

1. Long-term vision

You need to know what you’re trying to do and why before you can decide how to do it. Every business/product needs a long-term vision.

  • Purpose: Lays out a durable, unifying thesis about the future of the space, why this product/business exists and how it fits in, and how it will be successful.
  • Level: Company + distinct business/product area. Anything that has a standalone 10+ year thesis. Google needs one, and the Assistant needs one, but the Assistant partner ecosystem doesn’t need its own.
  • Time frame: 10+ years. Needs to be durable, forcing your head out of the fog of short-term moves and immediate competitors.
  • Helps avoid: Doing a bunch of incidental stuff, playing to the wrong trend, falling into reactionary thinking, having no way to evaluate large-scale (multiyear) strategies.
  • My preferred format: 3–5 page narrative document. Tell the story, make it concrete, but keep it high level.
  • Common error: Using too short a timeframe, or not having a long-term view at all.

2. Strategic pillars

While these documents can seem to resemble the long-term vision, they perform an entirely different function and are an important — and often forgotten — component of product planning.

  • Purpose: Defines the pillar’s purpose (related back to the overarching vision) and the path to achieve it, including assumptions, challenges, example projects, and what the product will look like in success (including north star metrics).
  • Level: Major strategy (exists over multiple years and projects). For example, how to build the Google Assistant partner ecosystem. At a certain level of complexity these can be nested.
  • Time frame: 3–5 years. There generally aren’t more than a few of these pillars at the same time, and each should cover many projects.
  • Helps avoid: Difficulty prioritizing projects (many things look like equally good choices to work on next), staying ahead of the curve on investments (unclear what comes after this bucket of work), deciding what project success looks like (since the context providing the purpose & strategic impact of each project is underdefined).
  • My preferred format: 3–5 page narrative document. Inherits the long-term view and context from the top-level vision doc, but needs to flesh out this specific area. In my opinion, this is the most critical level to use long-form writing, since it forces you to be explicit about assumptions and assertions.
  • Common error: Omitting this level of planning entirely and jumping straight from 10 year vision to what projects to work on tomorrow.

3. Projects

People typically talk about PRDs (product requirements documents), but I avoid the term since to many it connotes an overly-specific product definition handed to engineering in a waterfall process. I consider the actual product specs far less important than the explanation of why the project is necessary and how we’ll know if it’s successful.

  • Purpose: Define the project, contextualize it within the strategy, explain why it’s happening & what success looks like, sketch out what the project actually entails, and act as the source of truth for the project.
  • Level: Single project. For example, the Google Assistant Local Home SDK or Sonos integration. At a certain level of complexity these can be nested.
  • Time frame: Weeks to quarters
  • Helps avoid: Doing a bunch of work without making progress towards your strategic goals, misalignment of people pulling in different directions with different ideas of why the project exists and what success looks like.
  • My preferred format: ½–3 page document. These documents tend to sprawl over time as details are added, supporting documents are produced, etc. Try to keep the core document clean & concise and then add appendices and links.
  • Common error: Focusing too much on concrete project details and not enough on why the project is important and how to know if it’s successful.

4. Roadmap

A roadmap takes all your projects and prioritizes them on a timeline, with some organization by strategic pillar. Without a roadmap, you’re skipping the work of deciding what needs to happen now and what comes next.

  • Purpose: Tells you what happens now, next, and later. Allows projects to be both important and deferred, enabling teams to focus. Ensures you are building towards something, and not just hill climbing.
  • Level: You can do a roadmap at any level, but you should at least have one for each distinct business/product area. Usually each sizable team within that area will have its own roadmap representing in more detail their subset of the overall roadmap.
  • Timeframe: 1 year into the future, continually updated. As a rule, you should be able to know pretty concretely what you’re doing for the next 2–3 months (this quarter), you’ll have a pretty good idea of what comes next (next quarter), which is often the stuff you wish you were doing this quarter but had to push out, and you’ll have only a fuzzy idea of exactly what you’ll be working on in 9 months.
  • Helps avoid: Doing too much at once. Hill climbing — making tiny spurts of progress in many different directions, but not durable progress. Misaligning product development and operations.
  • My preferred format: A single page with a grid, where the columns are quarters (this quarter, next quarter, the following two quarters) and the rows are your major strategic initiatives. Each cell summarizes the top priorities for that initiative in that time period. Here’s what that looks like.
  • Common error: Trying to cram too much detail in, causing people to miss the forest for the trees. Trying to overspecify 3 quarters from now rather than just setting down some landmarks and recognizing that things change.

5. OKRs

OKRs (objectives and key results) are a mechanism to refocus from activities (projects) to goals (objectives) and concrete assessments of progress towards those goals (key results).

  • Purpose: Ensures that all the work you’re doing actually has the intended impact and is driving results.
  • Level: You can do OKRs at any level (I do personal OKRs), but you should at least have one for each distinct business/product area. Usually each sizable team within that area will have its own OKRs representing in more detail their subset of the overall OKRs.
  • Timeframe: Typically I’ll do annual OKRs + quarterly OKRs.
  • Helps avoid: Doing lots of stuff without moving the needle, being misaligned about what the goals are and what success looks like.
  • My preferred format: A single page document with bullet points. (If you need more than a page, you’re doing it wrong.)
  • Common error: Specifying activities (“launch X”) rather than outcomes (“increase daily users by Y”), choosing ambiguous outcomes (“improve onboarding” rather than concrete ones “increase day 7 retention by Z”), treating goal setting as capacity planning, going into too much detail about how rather than what, creating a laundry list rather than organizing against your major strategic initiatives and focusing on the top priorities.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Michael Siliski

Michael Siliski

products, software, data, cities, housing, mobility, San Francisco, Boston sports, minds, music, coffee, spirits, funny stuff, beautiful stuff, amazing stuff