Product Planning

I get asked a lot about how I like to do product planning. While it’s a bit inside-baseball, I find having a solid planning framework reliably helps to improve outcomes. So here’s how I do it. The focus here is on what kind of plans you need and why, not the processes you’d use to develop them. While we could spend a lot of time on that, it’s a separate topic, and there are many ways of driving good outcomes.

As I wrote about in The Role of a Product Manager, PMs are responsible for ensuring there is a sound vision & strategy, creating and prioritizing product plans, and driving execution that results in meaningful progress. Delivering on those responsibilities requires operating at multiple levels in parallel — figuring out what has to happen tomorrow as well as how to set ourselves up to be in the right place in a year or five. In large part my goal with this framework is to ensure that none of those levels get neglected — that we’re not betting on the wrong strategy, doing a bunch of work on the wrong priorities, or failing to make progress in the short term.

Here are the documents I like to use. But remember, the critical thing is not the exact set of documents or their precise format, it’s ensuring the right products get built.

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.

Do the thinking
I want to do the minimum document production work necessary to ensure that the right plans get created, captured, and communicated. The five different documents here each serve a distinct purpose and help avoid common product development pitfalls. It sounds like a lot of work, but if you know what your strategy is, it doesn’t actually take very long to write it down. The heavy lifting is thought work.

I have a strong bias towards long-form writing as the best way to force high quality thinking. The written word is magic, and it’s far easier to paper over holes in your reasoning when you’re assembling a set of slides than when you have to actually write a document. As Jeff Bezos says, “There is no way to write a six-page, narratively structured memo and not have clear thinking.”

Drive better outcomes, faster
The work you put in up front will pay you back many times over in time & effort saved. That includes communicating, thrashing about trying to make decisions, coordinating teams unable to operate autonomously, working on secondary priorities, and working on the wrong thing entirely.

Stay agile
As Eisenhower said, “In preparing for battle I have always found that plans are useless, but planning is indispensable.” Your plans should be durable but also flexible enough so you can react quickly to new information without having to rework everything. Not planning at all is not the same as being agile.

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.

Netflix’s Long-Term View is one of my favorite public examples of such a document.

The long-term vision will sketch out the major strategic initiatives (sometimes called strategic pillars) needed to realize the vision. Each of those pillars needs to be fleshed out with its own document.

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.

If you know of a great (public) example of one of these, let me know so I can link it!

Strategic pillars will typically sketch out a set of projects necessary for the pillar to be successful. Each of those near-term projects should have some sort of document.

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.

I don’t have a good public paragon product document to point to (let me know if you do!), but these are pretty good takes on how to think about it: How To Write a Good PRD, On Writing Product Specs.

If you have all of those things, you have the components of a plan. You still need to put them in order and then drive progress. I like to use a simple roadmap plus an OKR process for that.

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.

There’s one last piece, which is ensuring that the work you’re doing is actually driving the results you want. While a roadmap tells you what projects you’re working on, it doesn’t tell you how to know if they’re successful. OKRs fill that gap.

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.

You can read more about the benefits and process of creating good OKRs here and here.

And with that, hopefully you know where you’re going, how you expect to get there, what needs to be done in what order, and how to assess your progress. It all sounds very orderly, but don’t worry, in practice you’ll always still feel like you’re stumbling around in the dark a bit.