Two types of artifacts that PMs regularly produce are strategic memos and Product Requirement Documents (PRDs). Novice (and even experienced) PMs often conflate these artifacts, resulting in documents that are less useful, unclear, and longer than necessary. In this post, I’ll talk about these two types of artifacts, their purposes, and best practices.
Product Strategy Memos
There are two types of Product Strategy Memos. The first type analyzes a set of strategic decisions for a product and makes a recommendation as to the best decision(s). The second type makes assertions or provides descriptions of the product strategy that the team will follow. In this post, I’ll only talk about the former. The latter is usually a summary artifact that is constructed after a set of strategic decisions have been made.
Product Strategy Memos do not have to be about big, multi-year, corporate-level decisions. Something as “simple” as deciding which set of features that a product will have (and which features will not be supported) merits a Product Strategy Memo (and associated review).
The audience for Product Strategy Memos are executives and leaders on the team, as well as the engineering, PM, and design teams themselves. Reviews for Strategy Memos will usually involve the executive stakeholders.
My preferred approach to writing Product Strategic Memos is to start with the facts (or “framing”), assumptions, goals, and non-goals. A leader I tremendously respect taught me this framework. People often debate and argue specific features and directions for a product, when they are actually not aligned on the goals, do not share the same set of assumptions, or may not even be working from the same set of facts. By aligning on these up front, you avoid debating these topics by proxy. A productive strategy discussion will often stress test these items. Does the recommendation change if the assumptions are inverted? Are the goals the right set of goals? Are there any implicit assumptions being made, for example about resourcing or technical feasibility?
After the framing, assumptions, goals, non-goals, the next section should lay out the principles or criteria by which the decision will be made. This is only necessary if the criteria are an expansion of the goals. For smaller decisions, the goals themselves can directly serve as the criteria. For larger decisions, the goals often expand out into multiple criteria for each goal. Another useful point of discussion during a strategy review is to stress test the criteria. Are these the right set of criteria? How should they be weighted against each other? Is a criteria missing? How would the recommendation change if a criterion were removed or added?
After the criteria, the next section should succinctly lay out the options being considered. Each option should be described in a few sentences at most. This is not the place to describe the options in detail.
Next, the PM should draw up a cross-product table with the criteria along one axis and the options along another. Then each cell in the table is evaluated one by one. Some criteria and options may simply involve qualitative assessments such as “High risk”, “Medium risk”, “Low risk”. Others may have more detailed quantitative metrics and considerations. Color coding is helpful!
Finally, the recommendation should synthesize the analysis done in the table. The recommendation can call out next steps, alternative considerations etc. The recommendation should then also be summarized at the top of the document, so that the busy reader does not need to read the whole document to get the key take-away.
This approach to Product Strategy Memos shows the reader that you considered a wide set of options, evaluated them with a rigorous criteria framework, and made a recommendation based on this analysis. It forces you to be objective in your analysis, rather than basing a recommendation on your intuition or gut, which as I’ve mentioned before, is often wrong for inexperienced PMs. Finally, it shows the reader that you are not trying to lead them down a garden path, but rather, being intellectually rigorous and honest and laying out your thinking process for the reader to see.
Product Requirement Documents
Product Requirement Documents (PRDs) for a product are written after the strategic direction has been determined. This means that the PRD is downstream of the Product Strategy Memo. PRDs should contain a brief strategic rationale for the product and reference back to the Product Strategy Memo for details of the strategic direction. PRDs detail out the user-facing use cases, features, and requirements for the product. Some PRDs may also contain a section on who the user/customer for the product is expected to be. PRDs should not contain a roadmap for the product. Future versions of the product either merit revs to the PRD or entirely new PRDs in themselves.
The audience for the PRD is the PM, design, engineering, and other cross-functional team members. I’ve rarely seen executives above the director level review PRDs (and even directors will usually just skim it). This is because good PRDs are sufficiently detailed to unblock the engineering, design, and TPM teams, and executives usually do not have time to review this level of detail.
Some PMs like one-pager PRDs that just describe the rationale for the product and then leave the use case and requirements unspecified. A well-written detailed PRD enables the PM to scale. If engineering and design teams cannot find the answer to a product question in the PRD, then the PM needs to bolster the PRD by adding the answer / requirement / use case. This way, the next time another engineer or designer asks that question, the PM can just point them to the relevant section in the PRD. This is not to say that well-written PRDs are dozens of pages long. A PRD could be as simple as a sketch on a whiteboard that is captured in a persistent document somewhere. As long as it unblocks the engineering and design teams, the PRD is serving its purpose. Indeed, in fast-moving teams or startups, the PRD might very well be photographs of whiteboard sketches outlining the product requirements.
That being said, I prefer more detail than less detail in my PRDs. I find that the upfront time spent saves me more time later. Additionally, having worked in consumer software, operating systems, and hardware, I’ve seen that hardware PRDs tend to be the most thorough and detailed. This level of rigor appeals to my style of PMing, and I tend to apply the same rigor when PMing software products.
Use cases and requirements
Use cases should be descriptions of the user-facing needs that the product meets. For example, use cases for a smartphone might be (1) Enables the user to make phone calls (2) Enables the user to listen to music (3) Enables the user to access the internet with a desktop-class browser.
The use cases in the PRD should be enumerated in numbered lists or presented in a table format. This enables consumers of the PRD to refer to specific use cases by reference. E.g. “Use case #3 in the Acme Toolkit PRD needs more detail”.
Following the use case section are the requirements. Each use case will likely unpack into a set of requirements. Some requirements will be common across all use cases and intrinsic to the entire product. Depending on the organization and team, the requirements might be articulated only in “user facing” terms or might be more technically oriented. For example, in the smartphone example above, a user facing articulation of a requirement might be “Has enough computation to render any website at smoothly without any user noticeable stuttering or pauses”. A more technical articulation might be “Has an Acme 495 mobile System-on-Chip that can render any website at 60 frames per second”. I personally prefer the latter approach but the former is common as well. The former will push some technical specifications of the product to the engineering teams and these specs must still be documented somewhere.
Requirements should also be enumerated or presented in a table. My requirements tables tend to have a few columns: ID, Priority, Requirement, KPI, Notes. The ID is the enumeration. The priority is either P0 (required to ship), P1 (can ship without it, but is painful to cut), and P2 (great to have, but can cut if necessary). The requirement is a sentence or two description. The Key Performance Indicator (KPI) is a quantitative metric that the requirement needs to hit. Notes are comments, links to UX or ID decks, etc.
PRDs describing user-facing software features will sometimes have screen flows that show how the UI work across different use cases. In other cases, the PRD will link to artifacts from the UX or Design teams, which will have these UI flows in them.
Finally, some PRDs should contain sections on security, privacy, accessibility, localization, etc. Not all PRDs merit sections on these topics, but having them in a template forces the PM to at least think about these important topics and whether they are relevant to the PRD being written.
Hopefully you find these tips and templates helpful as you write your next Product Strategy Memo and Product Requirements Document!