Writing · 3 min read

What do the best PRD templates have in common?

The problem, who it’s for, and the metric come before any feature. The document grows a little at each review, keeps a log of every call with the options turned down, and stays short enough that the team opens it. After launch, it asks whether the number moved.

The problem goes on page one, and the feature doesn’t

A long cream sheet of paper on a sage field, seen from straight above, ruled with thin black lines and running off the top and bottom edges, cut clean across the middle with its lower half slid a little apart, and a pair of solid black scissors open across the gap.

This fall I read the PRD templates teams have shared: Amazon’s, Linear’s, Intercom’s, Figma’s, Asana’s, Square’s, and Lenny Rachitsky’s. I expected a dozen formats. I found the same few habits, written down by different people.

The first is order. Intercom allows no solution on page one. Lenny writes the success metric before the feature. Asana asks for the non-goals, the section most teams skip. Amazon writes the press release first.

What goes on page one, and what waits

Page one

  • The problem, in the customer’s words
  • Who it’s for: a segment, not “users”
  • The metric that moves if it works
  • What it won’t do

Later

  • The solution
  • The options turned down
  • The launch plan
  • Whether it worked

I learned why the hard way. At Midwest Couriers I was sure the dispatch tool needed a map, and a morning on the floor ended that: the dispatchers knew every location code by heart.

A template can’t pick the problem for you. If nobody has agreed on it yet, you don’t need a PRD. You need discovery.

It’s written a little at each review, not in one sitting

The good templates start the document the day the idea reaches the backlog. Each product review fills in the next part, and the page stays at one until the problem is agreed.

One document, filled in at four reviews
  1. Problemagreed on one page
  2. Solutionthe call, and what it beat
  3. Launchsupport, legal, and marketing ready
  4. Impactdid the number move?

Nan Yu at Linear orders the sections from least likely to change to most. The problem sits at the top because it should hold still. The details underneath will move every week.

The detail matches the risk. A two-day fix gets a paragraph. A two-month project gets the whole page.

Its real job is to make decisions stick

The part I’d copy first is the decision log. Adam Waxman’s at SeatGeek records the question, the call, who made it, and when. Linear adds the options turned down, so nobody reopens them a month later.

I did a version of this on the Shortlist. Each of its five decisions sits beside the guess it rests on. No interviews were run, so the page says which guess to test first.

The rest is plain: name the risks and how you’ll reduce them, give the document one owner, and link everything to it. One link should answer any question about the project.

The team reads the short version, and the last section is the one that counts

Product Hunt’s warning is the one I think about most: every section you add, fewer people read it. If the engineers and designers building the thing aren’t opening the page, it has stopped working.

So every edit should also cut. When the project has changed beyond recognition, start a new document instead of stacking a second plan on the first.

Before launch, readiness belongs to everyone: support, legal, marketing, and the FAQ, as Figma and Kevin Yien at Square both lay out. Then have someone red-team it before stakeholders see it.

That reader can be an AI. One playing an engineering lead found claims in my Agent Review case study that I couldn’t support, on a page I’d read a dozen times.

The last habit is the one almost no template has: an Impact section. Did the launch move the metric you wrote down on page one?

A PRD that never asks whether it worked was only ever a plan.