Writing Product Strategy One-Pagers
Product managers are responsible for product strategy - in other words, we need to set the direction of our products, and that involves choosing one out of many viable options.
When we make these strategic product decisions, we need to get executive alignment for our proposal, or else we may run into troubles down the road. That then leads us to write up product strategy documents.
But, from what I’ve observed, product managers can wind up struggling with writing effective product strategy documents. Many times, they wind up having to reinvent the wheel, or they get criticized for writing a document that is too unstructured.
That’s why I’ve written this in-depth guide on crafting powerful and concise product strategy documents. Specifically, I’m going to focus on product strategy one-pagers.
First, we’ll cover what the purpose of the product strategy document is, and what it isn’t. Then, we’ll take a look at the pains of the executive audience, and how to solve these pains.
Afterwards, we’ll dive into the prep work we need to do to write a product strategy document. We’ll then discuss the actual creation process of the product strategy one-pager, and we’ll conclude with how to tighten your document for maximum clarity and conciseness.
So, what’s the point of a product strategy document?
What is the purpose of the product strategy document?
I’ve seen product managers attempt to use product strategy documents for many different purposes, such as:
Informing others about a decision
Asking people for input into an upcoming decision
Bringing people up to speed on context (e.g. competitors, industry trends)
Identifying the key levers to a problem
Breaking down the various approaches that were considered
Signaling to others that you’ve put in significant thought
But, a product strategy document shouldn’t serve all of these purposes simultaneously.
The more “focus areas” you chase, the less focused you’ll be, and the less coherent your document is. In other words, we should choose only one specific purpose when we write up a product strategy document.
Let’s take a step back and consider what strategy documents are good at doing. They mainly do two things well:
They record context and decisions at a single point in time
They broadcast information asynchronously, from the writer to the reader
Therefore, product strategy documents are typically not the right place to hold debates, or to serve as living repositories of ever-changing information.
If you need to hold a debate, set up a live discussion rather than writing up a product strategy document. It’s far better to get all of the voices into a room together to talk through the various angles, rather than bouncing a document asynchronously back and forth.
If you need to share live information, use meetings or status reports rather than keeping a product strategy document up-to-date.
So, we know what we shouldn’t do with the product strategy document. Well, what should the purpose be then?
I’ve found that product strategy documents are most effective when they’re focused on sharing information with executives and leaders. That is, the purpose of your product strategy document should be to “inform C-suite executives on a key decision we’ve made.”
The purpose of a product strategy one-pager isn’t to weigh the pros and cons in depth, or to kick off a non-actionable conversation about the far-flung future.
Rather, it’s to get an executive’s eyes on a particular problem, to let them know what you’re doing about it, and to give them the opportunity to object or to provide feedback.
Let’s hone in on this point a bit. Why are we targeting executives (e.g. C-suite leaders, VPs, etc.) rather than fellow product managers or peer stakeholders?
Who is the audience for the product strategy document?
To better understand why we don’t recommend including non-executives as “potential readers” for your strategy document, let’s consider our typical interactions with other kinds of stakeholders.
There are three kinds of non-executive audiences where we may want to inform them about a product decision:
Our direct managers
Our fellow individual contributor product managers (IC PMs)
Our peer stakeholders (e.g. product marketers, designers, account managers, etc.)
In all three of these cases, our existing interactions are far more effective than any strategy document would be.
When we craft and refine our product decisions, we should already be regularly syncing with our direct managers, e.g. during 1:1 meetings, status reports, or team meetings.
Typically, we want our managers to provide guidance before the decision has been made, whereas product strategy documents are used only after the decision is made.
So, it’s not helpful for us to write product strategy documents for our managers, because we should already have organically co-created the strategy with them.
Similarly, let’s consider peer IC PMs. We should already be having informal conversations about product strategy, such as during 1:1 meetings or lunch breaks.
Writing a product strategy document for their sake is unhelpful, because we already have easy access to our peer product managers. It’s more useful to debate the merits live, rather than to ask them to read a document.
And, let’s consider cross-functional stakeholders. We should already have a set of ongoing processes to keep them up to speed on the product, such as status reports, release notes, and roadmaps.
On top of that, we should already have a cadence of one-on-one conversations to get their feedback on potential problems or objections with our decisions.
Therefore, the product strategy document should only be for people who you don’t regularly have live access to: in other words, your executive team.
Leaders at the executive level have lots of different priorities to juggle, and so they don’t have free time to let every product manager book a slot to talk through a decision.
Executive leaders will assume that everything is running smoothly unless you push information to them. They don’t have the time to try to pull information from you, nor do they have the mental bandwidth to consume that information on an ongoing basis.
Therefore, we need to push information to our executives, and we should send that information their way when it’s urgent and relevant.
Let’s talk a bit more about the pains that our executives have, to emphasize why we need to be thoughtful about using their time and energy.
What pain points do executives have?
Executives are busy leading their respective departments, so they don’t have the time to dive deep into every problem or status update that comes across their desk.
But, while they can’t possibly look at every decision, they absolutely need to know about the direction that the product team is headed in, especially if that direction impacts their department.
After all, software companies live and die by their products. Product decisions are inherently company strategy decisions, and C-suite executives need to make sure that the product and the company are aligned.
I generally see the following two failure modes of engaging with executives:
Executives are engaged too early in the process
Executives are never engaged at all
The first failure mode is problematic, because in this case, the product manager is expecting the executive to put in way too much time.
Executives don’t have the time to brainstorm with you, to share all of their context with you, and to consider alternatives through multiple iterations. They have business lines and departments to run, and they need you to make the decisions.
So, when we “ask executives for input” before we’ve made a decision, we’re setting ourselves up for failure. It’s our job as PMs to decide what happens to the product.
When product managers get burned by the first failure mode, they wind up doing the entire opposite. They never engage the executive team again, with the mistaken assumption that that’s what executives want.
But, actually, this causes a second failure mode. When you never surface key product decisions to your executives, they wind up discovering painful problems later on, many of which were avoidable.
Executives typically have valuable context related to the decision that you’ve made. If you had engaged them as soon as you made the decision, they could have intervened earlier.
But, now that you’ve committed to this decision without their knowledge or their blessing, you’ve created lots of problems for the company.
Therefore, the best way to avoid both modes of failure is to write a product strategy one-pager. It should be a short, lightweight document that crisply summarizes the problem and the solution, and gives executives enough information to approve or to intervene.
This one-pager should be written from the perspective of “I’ve already made the decision” and “I have your approval for my proposed next steps.”
But, you shouldn’t actually implement the decision until you get the all-clear from your executive (typically within 2-5 business days after you’ve sent them the document).
Otherwise, if you were going to implement it without their feedback anyways, you never needed to send them this document in the first place!
To be clear, a product strategy one-pager makes the explicit tradeoff of “making the PM do X hours of work, to save the executive Y hours of work”.
From my own experience, product strategy one-pagers typically take me about three calendar days’s worth of prep work (about 4-8 dedicated work hours to analyze the problem), and then an additional two calendar days of writing and editing (about 3-6 dedicated work hours).
That means that product strategy one-pagers take me one calendar week’s worth of dedicated work. In other words, product strategy one-pagers are definitely not lightweight investments!
While the burden may seem quite high on the PM, it’s still favorable to the company because the PM is not running an entire department, whereas an executive is doing exactly that.
The goal of the product strategy one-pager is to condense our knowledge so that we minimize the time that executives need to spend in vetting our decisions.
I’m aware that executives at Amazon use six-page strategy documents, but I believe this level of rigor is inappropriate for most startups or for companies that have not yet IPO’d.
At smaller organizations, we need to focus on speed over rigor. Therefore, a single page is enough to get the core information across, without being so long that the executive loses focus.
Also, Amazon’s six-page strategy documents are typically targeted at a dozen stakeholders to read synchronously during a meeting. On the flip side, your one-pager product strategy document will typically be limited to 1 executive reading it asynchronously.
So, let’s talk about the prep work you need to do to set your strategy document up for success.
Prep work before writing a product strategy document
Too frequently, I see product managers attempt to write a product strategy document as the first (or only) deliverable.
But actually, product strategy documents should be the last deliverable that you tackle.
When you’re asked to write a product strategy doc, you’ll have to conduct lots of analysis and critical thinking. Many times, it’s tempting to put that entire body of work into the document directly. But, as we mentioned before, executives don’t have that much time.
To use an analogy: when we ship features, we give our customers easy-to-digest release notes.
But, we don’t give them the full behind-the-scenes data analyses, nor do we give them meeting notes from our backlog grooming sessions. We don’t give them the play-by-play on how we decided to ship a given feature.
Since we’re already used to shielding our customers from all of this information overload, we should feel comfortable doing the same for our executive team.
What kinds of prep work should we do? Here are the four key deliverables we need to complete before we begin writing our product strategy one-pager:
Problem analysis
What is the problem?
What’s the root cause of the problem?
How impactful is it?
How urgent is it? Why do we need to solve it now rather than later?
Inventory of potential options
Evaluation of potential options
Selected path
Only after you’ve completed this homework can you actually write out a product strategy one-pager.
As a reminder, we don’t want this prep work to be an actual part of the strategy doc itself. Feel free to link from your one-pager to your prep work, but make sure to keep your product strategy one-pager to just a single page.
So, we’ve done our homework, and we’re ready to tackle our one-pager. What does the structure of an effective one-pager look like?
The structure of a product strategy one-pager
The structure of a product strategy one-pager should look like this:
Executive summary
Problem
Solution
Next steps
(optional) Appendix
Let’s dive into what each of these sections looks like. I’ll cover them starting from “which one you should write first”, rather than “which one appears first in the document.” And, here’s a template that you can copy as a starting point.
Problem statement best practices
The first thing we write out in the product strategy one-pager is the problem statement. We shouldn’t start with the executive summary, even though it comes first in the document, because we don’t yet have enough information to write it up.
For the problem statement, make sure you cover the following information.
What is the problem?
How did we get to this state?
Why does the problem matter to the reader?
Why do we need to solve it now instead of later?
By providing background context, we bring the executive up to speed on the key components that matter. And, by stating the impact of the problem and the urgency of the problem, we can help them prioritize their time.
Don’t worry about trimming down your one-pager yet. Just get all of your thoughts down onto the page. Once you’ve completed all of the sections, we’ll then revise the document to cut it down to a single page.
Proposed solution best practices
Next up, we need to provide the proposed solution.
In other words, our goal should not be to ask the executive to solve the problem for us. Rather, we’re giving them the direction that we want to take.
Why is this valuable for our executives?
It’s because we’ve boiled down the problem from infinite options to two options. When you’ve selected a decision and present it to an executive, they only need to make one of two choices:
I approve, therefore I won’t intervene
I disapprove, therefore I need to intervene
We shouldn’t try to provide the entire set of potential paths, nor should we provide an in-depth analysis of how our proposed solution is better than other potential alternatives.
Many times, executives don’t have the time or bandwidth to consider other alternatives. They’re going to assume that you selected the best one available to you, and that you have good reasons for why you think it’s the best.
So, there’s no need to talk about solutions that aren’t as good, because that’s not a valuable use of their time.
Next steps best practices
The last standard section of the one-pager is next steps. In other words, how are you acting on the solution that you’ve proposed? What is it that you’re doing next?
This section provides value to the executive because it sets their expectations on the direction that you’re headed and the resources that you plan on using.
And, if you don’t cover a particular next step that they think is high-leverage, they can propose that step to you.
As an example, say that you’ve decided to drive viral word-of-mouth to acquire more users for your product. Therefore, you propose creating features within your product to offer in-app referral bonuses.
Your executive may agree with your next step, but may also let you know that you should consider buying national direct-response TV ads to also drive virality. That’s because that’s a cheap way to increase awareness for people who aren’t yet using your product.
So, it’s valuable to share your most important next steps in a single paragraph, so that they can intervene if they see a missing next step or they disagree with your prioritization of which next steps are the highest-leverage.
Appendix best practices
Optionally, you can also include a one-page appendix with your product strategy document. The goal of the appendix is to preemptively answer your executive’s questions, but only if they actually have questions.
The two most valuable components of the appendix are:
An assessment of alternative approaches
Risks and mitigations
For these, try not to use prose. In other words, don’t use paragraphs to write out your thoughts.
Instead, if you do decide to include either of these components, use a table format such as the following:
Assessment of alternative approaches
Risks and Mitigations
Executive summary best practices
Now that you’ve written up the key pieces of the product strategy one-pager, you can now come back to the executive summary.
Your executive summary should only consist of 3 sentences.
The first sentence should cover the problem statement.
The second sentence should identify your proposed solution.
The final sentence should highlight the most critical next steps you plan on taking.
Why do we need an executive summary at the top of our product strategy one-pager? It’s because this enables the executive reader to see your decision up front, which then helps frame their understanding as they read through the remainder of the document.
In other words, we want to share information in “concentric circles.”
The very first paragraph they read should be the quick hits of what matters.
Then, the rest of the one-pager fleshes out the product strategy decision in more detail.
And optionally, they can then dive into the appendix to get more detail if they have the time or they have concerns.
Tightening up your product strategy one-pager
Now that we have all of the pieces we need, it’s time to go back and tighten up the entire one-pager, so that it actually fits in one page.
It’s highly unlikely that your first draft fits in a single page. In fact, it’s probably taking up 2-4 pages right now!
First, make sure that you’ve labeled each section with a header, so that it’s clear to the reader where they are in the document. While section headers take up valuable space, not using section headers will cost valuable time.
You shouldn’t need to do anything to tighten up the executive summary. It should only be one paragraph long, consisting of only 3 sentences.
Next, work on tightening up your problem statement. Keep it between 1-2 paragraphs long, with each paragraph being between 2-5 sentences long.
Remember, your executive doesn’t need to know everything about everything. They’re just trying to understand:
What is the problem?
Why does the problem matter to me?
If you can’t summarize the problem within 1 paragraph, you probably don’t have a clear understanding of what problem you’re trying to solve.
And, if you can’t identify why the problem should matter to the executive within 1 paragraph, it probably doesn’t actually matter to them in the first place.
Now that our problem statement is concise, we can tackle the proposed solution section.
Similarly, keep this section between 1-2 paragraphs long, and make sure that each paragraph only takes up 2-5 sentences.
Feel free to replace one of the paragraphs with a table or a diagram instead. After all, a picture is worth a thousand words, so if a graphic helps get your point across, then use the graphic instead of text.
As a reminder, we shouldn’t use this section to break down every alternative that we considered. If we want to provide that information, we should move it into the appendix instead.
Finally, our next steps section should only be one paragraph long, and this paragraph should only contain 2-3 sentences.
Any more than that, and you’re sharing too much detail about your next steps.
Remember to prioritize the next steps that matter the most to the executive. There’s no need to share the entire project plan in this document.
With this structure, everything should fit into a single one page document. We shouldn’t need to resort to any formatting shenanigans such as margins, paragraph spacing, or font sizes.
With that, you now have a compelling product strategy one-pager to share with executives!
If you’d like to dive deeper on how exactly to establish product vision and product strategy for your organization, Product Teacher provides live group workshops. We’ve served both Fortune 500 companies and fast-growing startups in standardizing and refining their product processes (case study here).
Closing thoughts
Product strategy one-pagers are a great way to condense information into a deliverable that executives can swiftly act on.
Work with your manager to practice this format of sharing information with executives. Your manager likely has more exposure to executives, so she will have helpful perspectives to share with you on what to include or what to cut.
Focus on “what open questions weren’t answered” and on “what are the executive’s unsolved pains,” rather than trying to find even more information to cram into the document.
After all, we need to balance trade-offs! While there’s infinitely more information that we could have added, we need to prioritize the most relevant information for our executives to consume.
As you iterate on product strategy one-pagers, your executives will appreciate that you’re using their time wisely.
They’ll naturally prioritize reading your one-pagers because they know that your product strategy one-pagers are relevant and timely.
And in turn, that enables you to ship more impactful products!
Thank you to Pauli Bielewicz, Siamak Khorrami, Goutham Budati, Markus Seebauer, Alina Ha, Juliet Chuang, and Shanthan Gangupantula for making this guide possible.
