MVP for Product Requirements
It's been awhile since I've posted here, but I wanted to focus on a topic that quite a few folks have reached out on: how do I write a PRD?
For those unfamiliar with the term, PRD stands for product requirements document. It's purpose is also pretty straightforward; PMs understand the user pains and translate this into requirements of what engineering teams need to build. Easy right? NOT SO FAST! (I had to include at least once Lee Corso tribute, thanks for the memories). There's a million PRD templates, guides, opinionated CPOs who will ALL tell you a different story about what needs to be in a PRD.
Over my career, even I have seen slimmed down templates that include one section and large 40 page PRDs that cover endless edge cases. How do we find a balance here? We can debate if one page is probably too short for large projects, but nobody is going to read a 40 page document when ChatGPT is around.
The key principle I try to keep in mind when writing is product managers are trying to do their job and engineers need to be enabled to do theirs. As a product manager you should set the boundaries for what the product/feature should do but don't prescribe the solution, that's what the engineering team will define. This rule-of-thumb helps us thread the needle on a right-sized PRD.
The Outline
So what makes up a PRD? There's really three crucial sections:
- The Problem Statement
- The Success Criteria
- The Requirements
The Problem Statement
The start of any PRD should begin with "the W(s)". Why are doing this project? What pain point is it solving? Who is the affected user? Great problem statements take the form of some initial context, if needed, and a crisply defined problem that the net-new work is aiming to solve. This maximum should be a paragraph or two, if you're struggling to fit it into this the problem likely isn't clear. Step back and spend some time refining the problem.
The Success Criteria
In some cases this section could be optional, but overall it is helpful to tell your audience what success looks like. What product metrics are we hoping to drive? What does a good vs a bad outcome look like? What is the ideal end result for the business.
Here is where a product manager can make it clear that they are working on a solution that is expected to drive X amount of revenue or Y increase in users. This isn't enough detail though, often those are derivative metrics for the core change being made. We should also include on-page engagement metrics, in-experience satisfaction, and metrics that get us as close to measuring the new solution experinece and pain point as is reasonable.
The Requirements
Funny enough the Google template for a PRD actually misses one key thing... THE REQUIREMENTS. Now there's a lot of ways people write these (e.g. function vs non-functiion, wireframes, etc.). Keep it simple, explain what you want to happen. I like to do this by writing a user story with a couple of bullet points below describing what needs to be done in a successful product experience.
"As a <user>, I must to be able to <do X> so that I can <do Y>"
User stories are great here because it includes the persona, the experience that is changing, and what it enables the persona to do. Who, What, and Why!
To support this you can add some detials below the user story:
- Send a notification every 24 hours
- Target high value profiles
- ...
Between all of these requirements it should be clear to the engineering team what the scope of the problem space. For example, it doesn't need to define a schema, but it needs to make clear what type of data needs to be kept and how it will be used. AVOID solution-ing here because that's what the engineers are best at.
But What About AI? Aren't PRDs old-school?
While a picture is worth a thousand words, I'm not sure a quick vibe mock supplants a PRD (yet). The PRD is about defining the problem and scope of a solution. I think it's natural to have a MVP or mock as a quick next step to a PRD but handing off a mock doesn't deliver the full context on what we are solving, why we are solving this, and who this will be for.
In my own experience I like to keep the PRDs short, 1-2 pages, and then using AI tools help mock out or create a simplified MVP to provide further context if needed. Otherwise this gets too far down the solution-ing path.