Documentation

Mermaid JS

Model Cards for Model Reporting

Product Requirements Doc

How to write a Product Requirements Doc (PRD)?

A “Good” PRD usually contains the following sections:

  • Problem & Opportunity Statement
  • Goals & Success Metrics
  • Users
  • User Story
  • Concept mocks
  • Roadmap & Go-to-market plan
  • Open Questions

A “Great” PRD adds more thoughts and depth:

  • Where should we play in this problem space?
  • Why are we uniquely positioned to “win” this?
  • Why now? What drives the urgency?
  • What user insights give us the conviction?
  • What are some product principles we follow?
  • What are the key trade-offs & decisions?
  • What are the risks & their mitigation plan?
  • What are the riskiest assumptions? What must be true for this idea to work?

Here are additional tips to ensure the PRD lives to its fullest potential:

  1. Use the writing process to clarify your thinking.
  2. Make it easy to read and understand, including diagrams and charts, use bullet points, move as much as possible to an appendix, and highlight the controversial bits that need feedback/alignment.
  3. Use the doc as the focal point for feedback. Writing PRD isn’t about handing your perfect plan over to the team - it’s about making the plan better! The final spec isn’t as valuable as the process you go through to write and collaborate on the doc.
  4. Judgment > template. Don’t get overly-focused on picking the right template, focus on understanding the purpose of each section of the template, and how it may help drive desired outcomes for your product.
  5. Focus on outcomes > output. Don’t overspend your time perfecting the PRD; your job isn’t to deliver a spec. You want to use it as a conduit to guide the team towards a concrete outcome.

Credit: Jackie Bavaro for some of these best practices and a spec template from her days at Asana for folks for you to reference: https://lnkd.in/gHSid-fE

The template:

Project Brief

Background

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

Problem Statements

  1. I am <\who> . I am trying to <outcome/job>. But <problem/barrier> because <\root cause> which makes me feel <\emotion>.

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.