Build

Building PRD

14 min read

**

[Project Title]

Description: What is it?

…

Problem: What problem is this solving?

…

Why: How do we know this is a real problem and worth solving?

…

Success: How do we know if we’ve solved this problem?

…

Audience: Who are we building for?

…

What: Roughly, what does this look like in the product?

…

How: What is the experiment plan?

…

When: When does it ship and what are the milestones?

…

**

**

[Project Name]

[one-line description]

Team: [Awesome]

Contributors: [PM], [Designer], [Engineer], [Analyst]

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

Status: Draft / Problem Review / Solution Review / Launch Review / Launched

Last Updated: Thursday, May 21, 2020

Problem Alignment 

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?

High Level Approach

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”.

Narrative

Optional: 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.

Goals

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

  2. Include measurable (metrics) and immeasurable (feelings) goals

  3. Keep it short and sweet

Non-goals

  1. List explicit areas we do not plan to address

  2. Explain why they are not goals

  3. 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.
REVIEWERTEAM/ROLESTATUS

Solution Alignment 

✅  Draw the perimeter🚫  Do not force others to identify scope

Key Features

Plan of record

  1. List the features that shape the solution

  2. Ideally in priority order

  3. Think of this like drawing the perimeter of the solution space

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

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

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

Future considerations

  1. Optionally list features you are saving for later

  2. These might inform how you build now

Key Flows

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.

Key Logic

  1. List rules to guide design and development

  2. Address common scenarios and edge cases

  3. 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.
REVIEWERTEAM/ROLESTATUS

Launch Plan

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.

Key Milestones

TARGET DATEMILESTONEDESCRIPTIONEXIT CRITERIA
YYYY-MM-DD✅ PilotInternal testing with employees onlyNo P0 or P1 bugs on a rolling 7-day basis
YYYY-MM-DD🛑 BetaEarly cohort of 20 customersAt least 10 customers would be disappointed if we took it away
YYYY-MM-DD🛑 Early AccessInvite-only customers from salesAt least 1 win from every major competitor
YYYY-MM-DD🛑 LaunchAll customers in current marketsMeasure and monitor

Operational Checklist

TEAMPROMPTY/NACTION (if yes)
AnalyticsDo you need additional tracking?Work with [person] on logging
SalesDo you need sales enablement materials?Work with [person]
MarketingDoes this impact shared KPI?Work with [person] on goal adjustment
Customer SuccessDo you need to update support content or training?Work with [person] on updates
Product MarketingDo you need a GTM plan? (e.g. pricing, packaging, positioning,Work with [person] with at least [x] weeks notice to kickoff workstreams
PartnersWill this impact any external partners?Work with [person] on communication plan
GlobalizationAre you launching in multiple countries?Work with [person]
RiskDoes this expose a risk vector?Work with [person]
LegalAre there potential legal ramifications?Work with [person]

Appendix

Changelog

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. 

DATEDESCRIPTION

Open Questions

Track open questions and answers here. 

FAQs

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. 

Impact Checklist

  • Permissions

  • Reporting

  • Pricing

  • API

  • Global

Example PRDs

TK

**

**

Project Brief

Background

Help the audience understand the context behind why we are doing this project. 

Problem Statements

  1. I am . I am trying to <outcome/job>. But <problem/barrier> because which makes me feel .

Goals

  • Goal / What success looks like

  • Goal / What success looks like

Non Goals

  • Non Goal

Hypothesis:

If we <achieve/enable X>, then leading to positive metrics Z. Include guesses for size of the win on specific metrics, using past launches as a baseline. 

Vision Narrative

Tell your use cases in story format, starting before the user encounters your feature and including their thoughts and motivations. Show how the feature fits into the users’ lives and has a big impact.

Rough Scoping & Timeline

At a high level, what’s included in V1 vs. later versions? How big of a project is this? What’s the roll out / testing plan? Consider the major pieces of functionality, Mobile, Platform, Internationalization, Entry Points, User Onboarding, Premium.

Key Trade Offs & Decisions

  • For example, were there any alternatives considered?

Concept Mocks

Include some mocks or a prototype to illustrate the concept. 

--------------------- Review Project Brief before continuing-----------------

Project Proposal

Proposal

Detailed mocks & feature requirements. You can start by expanding on the scoping section from the brief. Work with your engineers & designer to ensure you’ve gone into enough detail and covered all of the cases.

Risks & Mitigations

Brainstorm things that could go wrong with your team and partner teams. For each risk, plan appropriate mitigations.

Open Questions

Gather open questions here while the spec is in progress.

Appendix: Research

Include useful research, such as competitive analysis, metrics, or surveys.

Adapted from Asana’s spec template, with many thanks to the Asana PMs who have contributed to it over time.

**

**

Remember - THE GOAL IS ONE PAGE. Keep Cutting Until You Get There.

Abstract

For this section, you’ll need to sit and write about what you are trying to achieve, who is it for, what is it for, who is affected by the work, what success looks like, the history of the team, etc. This section is where you’ll spend most of your time. However, it’s the key to understanding what you are spending all of this effort to build.

This is the paragraph that outlines the work, and it needs to be short. Someone should be able to read it and repeat it. When writing the abstract, one technique to consider is the protostrategy method from Chris Butler — build a five-page outline, then cut that down to one page, and eventually, to a single paragraph. After completing the other four sections, you’ll come back to the abstract and finalize it. 

Objectives

How does this initiative tie into the overall product strategy? Your project should have a direct line to the company’s objectives and goals. 

To get started, you’ll need to reread the company’s product mission/vision/strategy docs and relate your project to these overarching themes. Do not try to force a connection between your abstract and the company objectives. This should serve as a check to see if this is worth doing. And if it isn’t, you should stop here and make your case as to why this is a waste of time.

Resources

How are we going to staff this? Who is going to do what?

You want to collect all of this information in one easy-to-share place. You don’t want any surprises when the actual work gets going. Begin by looking at what (and who) is available and start talking to the folks involved to make sure they have an understanding of what’s at stake and what you need to get it done. Also - make sure you are clear about who needs to make decisions, and who needs to stay aware. However, remember it is their resources that you are going to need — they can say no.

Success/Survival

What does success look like? What about failure? 

To start determining the answers to these questions, look at the abstract, and start pulling the numbers. Make sure you add qualitative constraints as well, what are the third rails of this project? Think about survival, failure, and success, and explain it in terms anyone can understand. Describe exactly when to pull the plug [think about the resources you are using], keep going[what are some near term signs of success], or double down [success metrics]. 

Time Horizon

How long will this take? Even better - when can people expect answers? Leadership will want to know how you are going to use the resources available to complete your project when they should check-in and on what timeline.

If you are at an “Agile” shop - start with an estimate of how many sprints the work will take. Try to remember Parkinson’s Law (things take as much time as you let them) and balance it with the Law of Slack (we never finish things on time.) You are never going to nail this, but an estimate will help folks make a “go, no-go” decision. 

A few notes…

  • Meeting notes and retrospective notes are great to add as the project goes on. This can function as a complete log of the project.

  • It’s fine if different disciplines take copies of this doc and use it for their own purposes, remember this is an alignment document. If teams are taking it back and using it, it’s a good thing!

  • This document is alive. Take it with you to your meetings. Lead with it. When people are sick of talking about it, you are about halfway there.

**

**

Template by @ajwaxman, Product & Design @ SeatGeek (we’re HIRING!)

[Initiative Name]

Direct questions to: [product owner] or [#project-slack-channel]

Last updated: [MMM DD YYYY]

What

Describe the initiative. Keep it high level and use plain language.

Why

Why should we work on this? Include how it aligns with business and user goals.

Success Criteria

What does success look like? Include quant and qual metrics as appropriate.

MetricBaseline (Date)Target (Date)Latest (Updated On)

[Optional] Overview

🌱 Problem Space🛠 Solution Space📊 Observing📂 Archived
DiscoverDefineExploreDeliverLearnMove On
📍We are here
1 PagerProduct SpecDesign ExplorationEpic / IssuesXP TemplateN/A
Research BriefTechnical RFCLooker Dash

Team

Product Management: TBD

Product Design: TBD

User Research: TBD

Analytics: TBD

iOS: TBD

Android: TBD

Web: TBD

Backend: TBD

Keep Informed: TBD

Stakeholder X: TBD

Stakeholder Y: TBD

OKRs

FAQs

Internal Documentation

Press Release

Loom Demo

[Optional] Upcoming Milestones

MilestoneOwnerDue DateCompletion Date

[Optional] Decision Journal

Question/TopicCurrent Path Forward
[Add question/topic here][Decider Name], [Decision Date] - [Decision Description]

[Optional] Meeting Notes

[Date] - [Description]

  • Add agenda, notes, action item

Product Spec

This section gives us a consistent way of making sure we’re working on the right problems before diving into solutions.

Alignment

How does this initiative tie to broader team or company goals and strategies?

Key Insights and Inspiration

What key insights (quant or qual) and inspiration (including competitive research) should be considered when refining the problem and exploring solutions? Please add any related links or dashboards.

Problem Statement

What’s the underlying problem we’ve observed? How do we know this is true?

Hypothesis & Impact

We believe [capability], will lead to [outcome], which will result in [metric change] by [date]. Include guesses for the size of the win.

Constraints

What are the key constraints, deadlines, or hard requirements to consider?

Non-Goals

Are there any related problems that we want to explicitly ignore for now?

Design Exploration

This section helps us ensure a collaborative and divergent design process. It also helps us document previously considered directions and rationales for large design decisions.

🔗 Figma Link

Initial Ideas

Document any initial ideas or user stories that should be considered when exploring solutions.

IdeasDescription
[Idea Name][Add brief description and any supporting links]
User StoriesImportance
As a [persona], I [want to], [so that]Must have  Nice to have  Optional

Explored Directions

Document the main directions being considered, along with links to the design artifacts.

NameDetails
[Direction Name][Short description w/ link to details]

Key Decisions

Document any key decisions that were made.

Decided Direction

Describe which direction was chosen to move forward with and why it was chosen.

Inspiration

**

**

Project Name - 1 Pager

September 04, 20XX by Steve Morin

If you like this template, join my newsletter, ProductiveGrowth, for more on Leadership, Management, Productivity, and Growth: https://productivegrowth.substack.com/

Template Purpose

You should use this 1-Pager Project Brief template for an introduction to a new project. It’s used to introduce people to why a project is being pursued and what it is about, including context, how it’s being measured, strategy for implementation, and initial design/features if they exist.

Project Introduction

Answer the question of what you will be working on:

  • Author:

  • A summary of the project.

  • This should be one paragraph at maximum.

  • Designs (Optional if they exist)

  • Milestone 1:

  • Milestone 2:

Vision / Why

1 sentence description of why you’re pursuing this project.

Context:

Provide background information about the project. Answering questions like “What’s broken?” or problems encountered. For example, the context for an onboarding experience project might be that ongoing issues and complaints make it hard for the user to onboard, so this is important to help users onboard.

Objectives (What) / Key Results (How to measure)

Objective:

  • What are we trying to accomplish?

Key result(s):

  • What is a specific time-bound measurement to indicate success?

Strategy / How

Name of the first strategy

  • How to implement the first strategy.  Details about what will and won’t be done for this strategy.

Goals

  • Operational Success Metric

  • A measurable number to determine if the project or feature of the project is succeeding.

  • Counter Metrics

  • A measurable number to determine if things aren’t regressing.  So, even if a feature or project doesn’t increase a metric, it shouldn’t cause it to go down either.  For example, adding a feature shouldn’t cause signups to go down, revenue to drop, or churn to go up.

Assumptions & Risks

Platforms

  • Web

  • iOS

  • Android

  • Backend

Assumptions

  • In-Scope:

  • Activities, behaviors, or outcomes that are assumed to be part of this project.

  • Costs, estimates, or inputs into planning that are part of the project.

  • Add questions about the assumption below in open questions and reference that here.

  • Out-of-Scope:

  • Things that are explicitly being left out of the project.

  • Outcome or non-goals of the project.

Risks

  • Call out unknowns.

  • Difficult skills

  • Known risks in the market, execution team, or parts of the project.

Risk Mitigation Strategies

  • What will be done to reduce risks?

Features and Functionality (Optional)

What features and functionality will be in the project? A list of assumed features and functionality should be added if it’s unknown.

  • Feature 1

  • Functionality 1

Features and Functionality (Optional)

What features and functionality will be in the project? A list of assumed features and functionality should be added if it’s unknown.

  • Feature 1

  • Functionality 1

Dependencies

DependencyLink to Execution TrackerOwning Team/PersonWhy it’s a dependencyWhen is it needed by?

Technical Design (Optional)

If your project is primarily technical or backend, this section should definitely be filled out. Otherwise, it’s optional for more consumer-facing or business projects.

i.e., we need X client work, Y server work, Z XFN

Reference Documents (Optional)

  • Document 1

  • Document 2

Open Questions

Identify anything unknown, unclear, undecided, and/or risky:

  • <question/statement> → to

  • <sub-question/item> → to by

  • <sub-question/item> → to by

Next Steps and Action Items

ActionStatusOwner

**

Graph View

Backlinks