Happy holidays everyone! I hope everyone is getting ready for their well-deserved holiday break this year. I also decided to do something different this holiday break: instead of sitting around stuffing myself with food and watching TVs, I will…” drum rolls please”... review and critique friends’ resumes for tech roles. I have a couple of requests already, and thought why not make it my holiday gifts to my subscribers?
To get in contact with me for your resume review over the holiday break, simply fill out the form below and spread the word about this newsletter to a friend or two.
Note that my resume review may be most helpful to the following roles, while not so much for the others due to my background:
Product managers
Product operations
Business operations
Data Analyst
…
I have recently gotten quite a few questions about PRDs, e.g. the structure of PRDs, the process of formulating a PRD, last but very importantly, its iterative and collaborative nature. I will spend the next 2 or 3 posts to break down my takes on the what, how, and why of PRDs.
For part 1, let’s talk about the “what”.
PRDs (Product Requirement Docs) seem to be the signature piece of PMs: it documents the problem statements and larger contexts, the purpose of this feature, the end-user stories of interfacing with the feature, all the prerequisites, and last but not least, pre-launch considerations.
When I was first introduced to PRDs, I had a ton of questions, and wrong assumptions were made. That’s also why I want to spend a separate post on “how” and “why”. Because you see, PRDs are so much more than just documentation; if done right, it could be an amazing jigsaw puzzle with your parts diligently filled in, while welcoming others to contribute for completion. A PM’s role is not to define a feature/product experience in its entirety or without others’ inputs —that pivotal mindset should start as early as writing the first draft of PRDs. But, more on this in the next posts. Stay tuned!
Below are my go-to structures of PRDs. Note that not all sections are necessary for a particular feature you are working on, and you don’t need to finalize all the parts at once.
Title of the PRD
Status: draft/in review/in development/eng complete/launched
References: JIRA & Broader wiki & Design & eng doc
DRI: @the pm
Problem Statement & Contexts
This section aligns the stakeholders on the border contexts and problem statements. Here you can enlist quantitative or qualitative data to tell what the problem is, why solving it is important, what’s been done before, and the scope of your upcoming proposal.
High-level overview
A TLDR on the scope of your solution and approach.
If this PRD is a pilot/MVP of a phased solution, you can use this section to clarify the overall phased approach and what this PRD will focus on.
Objectives & Metrics
Objective 1
Primary Success and counter metrics
Secondary success and counter metricsObjective 2
….
User Journey & Stories
This section perhaps gets the most scrutiny and eyeballs. There are several ways I would go about formulating this section to ensure its clarity, comprehensiveness, and yes, its engagement.
One way is to identify an ideal core user journey, map it out for your collaborators’ easy and quick reference. Next, break down the core user journey into user stories and features. During the break-down process, you probably will identify other user journeys, note them down somewhere so you don’t forget later. Lastly, dive into the user stories for alternative user journeys.
Let’s use the example of an app for ordering coffees, specifically you are building an app for commuters who want to skip the line at a coffee shop, order their coffee via the app and pick it up when it’s ready.
The ideal user journey is:
A user decides to order from the app for the first time → selects the coffee customizations he or she wants → buys the coffee → learns how long it will take → get notified when the coffee is ready for pick up → picks up and the app gets updated with the most recent status → rates the experience
User story 1: First-time user landing page and entry point
User story 2: coffee customization
User story 3: checkout flow
…
Now, by the time you finish the ideal FTUE (first-time user experience), you probably realize some other flows you need to design. For example, how would the landing page and entry point differ for repeat users and users who are simply browsing without deciding to buy a coffee yet? What if the coffee customer selected is no longer available by the time they check out, what would the customer experience be like then? Is it feasible or necessary to build an integrated system to trigger a notification in real-time for customer pick up?
The list can go on. As a PM, it’s not your job to design every edge case flow possible, it’s your job to identify what is important and necessary to scope out, and what can be iterated later.
Other features
I would use this section to enlist any backend logic changes that are not user-facing, API updates, and data instrumentations related to this feature.
Launch Plan
This Is the most overlooked section in a PRD, but recently I have found this increasingly important. I would use this section to list any pre-launch considerations for the team.
e.g.
Experimentation plan
Phased rollout and timeline
“Elephants in the room”: known concerns
Hope you enjoy the piece. Comment or DM me any questions you may have about PRDs, I’ll see if I can drop my comments into the next posts.