I find the name “PRD” to be a little unfortunate, since the reality is that it’s not actually a requirements doc for most teams. To solve for this, the version I’ve developed indexes more heavily on flexibility: you can use the sections as each project requires, rather than placing mad libs in front of the team and telling them to fill out every single detail.

PRDs, by nature, are collaborative documents, which can cause a pair of related problems. Since they’re always going to require feedback and iteration, you don’t want to get bogged down with sinking time into them upfront trying to make something absolutely perfect, given that it’s inevitably going to change as the rest of the team starts to work with it. But it can also be challenging to get your collaborators to actually sit down and give it the full attention it deserves. Getting to a good-enough version and then doing a live walkthrough can be a useful forcing function to help avoid both of these issues.

Over time, I’ve learned that a lot of projects don’t necessarily need the amount of detail that this PRD gives the team to work with, so I’ve also created a second, more 

 that we generally use for projects that are going to take less than 6 weeks to complete.

Part of the reason that PRDs can be so controversial is that every company and team is going to have different approaches to how exactly they structure their product development process. But at the end of the day, someone is going to have to be responsible for stitching together all the steps that it’s going to take to get a product to launch. I think sometimes we’re a little too prescriptive about what exactly a PM’s role is, when the reality is that PMs are shape shifters; they’re there to fill in the blanks on whatever the team needs at a specific point in time.

PRDs are too often looked at as a deliverable, which means there's a fixed date when it needs to be done. I think it's much more useful to conceive of them as living documents that are being continually updated through the lifecycle of a project.

Getting to the right level of alignment is always a challenge. If a PM is owning every single detail, you can easily end with a situation where they're the one designing the product, rather than the actual designers. If you leave the solution too ambiguous though, you'll end with a situation where the rest of the team isn't quite sure how to proceed. Depending on the level of seniority of your collaborators, this might be ok—a senior product designer is probably going to be able to figure those things out for themselves—but you need to be really aware of the experience and skills of everyone that you're working with.

Every successful product launch is eventually going to lead to a point where the code itself becomes the source of truth and the PRD doesn't matter so much anymore. Until you get there, it's important to keep a thorough log of everything that might even be perceived as a change. As the person who's in the weeds on every conversation, it's important that the PM keeps this clearly updated across the entire development process, since most of the people you're working with are only going to have 5% or 10% of the visibility that you do.

Kevin Yien

PRDs rarely consist of actual requirements. This flexible template lets me make sure that each product gets just the right level of detail for an efficient development process.

Resources: [Designs], [Analytics], [Notes]

 / Problem Review / Solution Review / Launch Review / Launched

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Describe the problem we are trying to solve in 1-2 sentences. I should be able to read this alone and communicate the value/risks to someone else.

Why does this matter to our customers and business?

What evidence or insights do you have to support this?

Describe the rough shape of how we might tackle the problem. I should be able to squint my eyes and see the same shape. For example, if the problem was “discoverability of new features”, then this might be “a notification center for relevant features”.

: Share (hypothetical) stories to paint a picture of what life looks like for customers today. Describe common and edgy use cases to consider when designing the solution.

Describe high-level goals, ideally in priority order and not too many.

Include measurable (metrics) and immeasurable (feelings) goals

List explicit areas we do not plan to address

These are as important and clarifying as the goals

Do not continue if all contributors are not aligned on the problem

Complete the following table with “signatures” from all reviewers to    move on.

List the features that shape the solution

Think of this like drawing the perimeter of the solution space

Draw the boundaries so the team can focus on how to fill it in

Link out to sub-docs for more detail for particularly large projects

Challenge the size to see if a smaller component can be shipped independently

Optionally list features you are saving for later

Show what the end-to-end experience will be for customers. This could be written prose, a flow diagram, screenshots, or design explorations. It will vary by project and team. Do not try to do this in isolation. Work with design and engineering to complete.

It is natural for this section to become more specific over time. It might start as a few annotated screenshots or stories. It might become highly detailed requirements with acceptance criteria. Adjust to the way your team operates. If you have a strong designer who enjoys going into every edge case, lean on them. If you have detailed engineers who prefer to have each scenario documented, go deep on acceptance criteria.

This will naturally change over time — that’s okay. When changes occur, document them in the Changelog and notify all contributors.

List rules to guide design and development

It is often easier to write these out than rely on design to show every permutation

Do not continue if all contributors are not aligned on the problem.

Complete the following table with “signatures” from all reviewers to move on.

Define the various phases that will get this product to market, the purpose of each phase, and the criteria you must meet to move on to the next one. Highlight risks and dependencies that can throw a wrench in timelines or progress (and ideally contingency plans). There is a table of example phases below.

List key decisions or updates you make for future reference. Include who was involved and link to notes doc, if relevant. Recommend moving this up top once approved so changes are more visible.

Optional: Include an FAQ when helpful to answer high level questions so it is easier for people to grasp the point of the project without getting lost in the details of product definition.

PRD Template at Mutiny

PRD Template from Mutiny

[Project Name]

Problem Alignment

Sign up to see more