How I organise my PRDs

Below is a simple, complete, and straightforward PRD template. It is very adaptable, whether you're using classic product management, a Shape Up approach, or some hybrid version.

It's also easy to use, communicate, and understand for all stakeholders.

Grab the PRD template here (make a local copy): https://docs.google.com/document/d/1i4Vc-B99zTc6EbqbX-vT9hA2puD-yv7M4zJd_lbBmDo

---

Structure

I split my PRDs into six sections:

1. A summary

2. The opportunity/challenge/pitch

3. The solution

4. The scopes/user stories

5. The release plan

6. The retro

Let's go through each one by one.

The PRD summary

I like to provide a few key bits of information at the top of the document, namely:

• Resource(s). I write PRDs in Confluence but the developers work in Jira. I connect the two through this link. I also link from the Jira epic to the Confluence doc.

• Business drivers. Why are we doing this? Generally, this will be revenue growth, innovation, operational efficiency, etc.

• Status. A project's status is either Backlog, In progress, Complete, or Cancelled.

• Target release. I'll roughly list a timeline for this project as reflected in my product roadmap.

Opportunity, challenge, or pitch

Most projects fall into one of these categories:

1. Opportunity. There's an opportunity the business can seize which, if successful, will produce a beneficial outcome.

2. Challenge. There's a challenge we (the business, the product team, the sales team, or the customers) face which, if resolved, will move the needle towards our business goals.

3. Pitch. We have an idea. We don't if there's a real opportunity there. There's no real challenge to solve. We'd still like to pitch it and potentially work on it.

Once I've clarified which type of project this is, it's time to drill down into five sub-sections.

Statement. In the statement section, I provide more details about the project. Anything goes here. I tend to favour a good narrative in a few bullet points, backed by data.

Audience. In the audience section, I list who will benefit from this work and in which way. This will often be a segment of your target customer.

Rationale. In the rationale section, I explain why this is something we should prioritise. There are always things to do. Why this one? Why now?

Use cases. In the use cases section, I select a few real-life examples from our target audience section and drill down into their specific uses. This section should contain real customers, real use cases, and real data.

Competitive research. In this section, I summarise the competitor research performed around this project. This section may be empty (e.g. if you're pitching an internal feature).

Solution

We've identified a problem, challenge, or idea. We've done well defining why we think this is worth working on.

Now it's time to lay out an approach to solving this. I do this in six sub-sections.

Proposed solution. In the proposed solution section, I write a narrative of the approach we expect to take to solve this project. This is a proposed solution. It's not fleshed out. It's not final. It's actually quite likely to be wrong by the time the project finishes. It's a starting point.

Key features. In the key features section, I list the key 'bits' that need to happen as part of this project. Regardless of how we end up solving this project, these 'bits' need to exist.

Complexity. In the complexity section, I attempt to identify how difficult this project is going to complete. I will usually refer to the resources we'll need, any unknowns that could slow us down, and more.

Assumptions. In the assumptions section, I list all the assumptions I've made while crafting this project. Again, we don't exactly know how this is going to play out. The assumptions help us spot inconsistencies early on or simply identify parts of the complexity we may have to face.

Budget. In the budget section, I enter the size of the budget for this project. This could be monetary but most of the time this is a time-based budget such as Shape Up's appetite.

Out-of-scope. In the out-of-scope section, I list what we're not going to touch. This clarifies the scope and puts boundaries on the project (again, see Shape Up).

Scopes (user stories)

Now, we start to drill further into the requirements of this project.

As per my penchant for Shape Up, I like to organise my projects into scopes. As a reminder:

"The scopes reflect the meaningful parts of the problem that can be completed independently and in a short period of time—a few days or less. They are bigger than tasks but much smaller than the overall project." (source)

If you're using the more classic user stories approach, this works fine too.

I create a table where each row is a single scope. The scope is named in column one, described in column two (with a few acceptance criteria if you have any), and a link to the corresponding scope ticket on Jira.

Release plan

Most PRDs stop at the previous step. Define the problem, frame the solution, and roughly execute it. Then? shrug.

I believe a PM's involvement in a project carries on well beyond the delivery. At this stage, I like to draft a release plan. I use the following three sub-sections.

Timeframe. I don't like deadlines but I do like timeframes. I break down the expected timeframe by week.

Milestones. In the milestones section, I identify the significant steps that need to happen for this project to be completed. The framing of this section is that each milestone depends on the previous one; a slight difference from the Scopes above (which are independent from each other).

Communication. In the communication section, I lay out the tasks between the product release and customers/stakeholders knowing about it. This can be 10s of smallish marketing tasks, internal emails, creation of documentation, and so on.

Retro

The retro section is, of course, only filled out after the project is finished.

For this section, I'll usually write a few prompting questions and organise a call with the project team. We go over these questions and try to identify learnings and failures from this project. We also identify action points for things we can do better next time.

Once the project is finished and the retro is filled out, we can file the PRD.