Author: Rahul

Early in my career, I used to measure my progress by external metrics: promotions, compensation, recognition, etc. These things certainly matter. Promotions expose you to larger scope, serve as a yardstick across companies, and set upper bounds on your compensation. Compensation is important because it is a measure of the value of your time (although you should quickly try to get into a career in which you don’t rent out your time). All of these measures of career progress are lagging indicators and do not give you as much leverage as the best metric to measure your career progress: Your rate of learning.

Nowadays, the primary yardstick I use to measure my career progression is whether I am experiencing step changes in my learning every six months. Your skillsets and capabilities are what will give you your next opportunity. They will give you higher compensation because you can create more value for the company. They will give you more leverage on your time because you can scale better. Most of all, you will enjoy a more rewarding and intellectually stimulating career.

Everyone says that they want to keep learning new things in their job but in practice, it is really hard to do. There is a subtle but insidious reason for this. If you are learning at a fast pace, your job will feel a bit uncomfortable. You will feel like you are producing sub-par work. You will likely feel some imposter syndrome. You will worry about being replaced or getting bad performance reviews. After a while, you will learn the new skills needed to do your job well, but it will take more effort and time than it would take someone more experienced. For example, you might have to put in a 70 hour work-week instead of a 40 hour work-week. The final step is to be able to do the same job at the same quality level, but faster. Soon, you will be able to work a 40 hour work-week (or even less) and produce great results. The trailing indicators will reflect this. You might get a big bonus, a raise, or even a promotion. Meanwhile, you are enjoying a great work-life balance. You’re a star and you do it all effortlessly. Life is great, right?

Wrong. Congratulations, you have now stopped learning. This is why it is so hard to always stay on a steep learning curve. Your extrinsic measures of career progression are inversely correlated with your learning metric. If you are crushing it at work, getting raises and bonuses, and don’t have to put in a lot of work to get these results, it feels good. You pat yourself on the back for the career progression results. In reality though, these indicators mean that your rate of learning has slowed down or even stalled.

Now, this might be OK. You might be at a phase in your life in which you want have a healthy work-life integration, to spend more time with friends and family, to nurture hobbies outside of work, etc. There is nothing wrong with this and I am not making any judgments. However, if your goal is to rapidly rise in your career, then being a star who does it all effortlessly should be a flashing alarm klaxon that you have stopped learning.

In some industries and companies, the external environment will force you to stay on a steep learning curve. Management consulting firms like McKinsey are famous for putting their employees on the next learning curve as soon as they have mastered the skills at their existing level. Startups in the hypergrowth phase require their employees all the way to the founder-CEO to constantly be learning at a really fast pace. In a large megacorp though, it can be really easy to just enjoy the trappings of “success” and let your true measure of career progress stall. Sure, getting promoted to the next level comes with an increased set of responsibilities and skills to learn, but all these companies have “terminal levels” at which people often plateau.

This is why I set learning OKRs for myself every year. Every six months, I check-in with myself on what I learned that half and what I want to learn over the next half. I seek out opportunities that help me learn these things. Sometimes the big learning opportunities take time to find. Be patient but relentless. Set smaller learning goals for yourself in the meantime. Tell your boss what you want to learn next. Often times, your boss might already be doing that and is only too happy for you to take it off their plate. Work for someone who will constantly throw you in at the deep end of the pool, but is still willing to dive in to bail you out if you’re about to drown. And if you’re not being thrown into the deep end of the pool regularly, then consider finding a new pool.

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!