---
title: "Product spec (PRD) template – Display.dev"
description: "A lightweight PRD in plain Markdown – problem, goals, non-goals, phased plan, open questions, and measurement. Publish it to a URL in one click, no account."
---

# Product spec (PRD) template

A lightweight PRD in plain Markdown – problem, goals, non-goals, phased plan, open questions, and measurement. Publish it to a URL in one click, no account.

- Format: Markdown
- Detail page: https://display.dev/templates/product-spec
- Raw template file: https://display.dev/template-sources/product-spec.md
- One-click anonymous publish (no account): POST the file to https://api.display.dev/v1/public/artifacts as multipart/form-data (`file` field)

## Agent prompt

Write a PRD for this feature on display.dev. Fetch the structure from https://display.dev/template-sources/product-spec.md and keep its sections: one-liner, problem, goals, non-goals, proposed solution, phased plan with exit criteria, open questions, measurement. Fill it from the feature discussion and any linked research – concrete numbers where they exist, honest open questions where they don't.

Publish it with the display.dev MCP publish tool if connected. Otherwise POST the file to https://api.display.dev/v1/public/artifacts as multipart/form-data (`file` field, optional `name`) – no account needed. You'll get back `previewUrl` (the link to share) and `claimUrl` (one-shot link to take ownership). Reply with both.

## What this template is for

A spec that fits on one page and still forces the three decisions that
matter: what problem, what's out of scope, and how you'll know it worked.
Non-goals and exit criteria are the sections most PRDs skip – they're the
ones that prevent scope creep and zombie rollouts.

Plain Markdown with structured headings, so agents can navigate it,
extend it, and check implementation against it.

## How teams use it

- **Drafted by an agent from the discussion.** Point your agent at the
  thread, the support tickets, and the session data; it drafts the
  problem and measurement sections with real numbers, you make the calls
  in goals and non-goals.
- **Reviewed with inline comments.** Publish the draft, collect comments
  from engineering and design at the same URL, publish the revision as a
  new version – the link in your tracker stays current.
- **The reference during the build.** Structured headings mean an
  implementing agent can quote the exact requirement it's building
  against.

## Template source

````markdown
# PRD: saved search filters

**Owner:** Jonas T. · **Status:** In review · **Target:** v2.14 (mid-August 2026)

> **One-liner:** Let users save a set of search filters under a name and
> re-apply it in one click, so the 40% of weekly-active users who rebuild
> the same filter combination every session stop doing it by hand.

## Problem

Search supports seven filter dimensions. Session replays show power users
re-selecting the same three or four filters at the start of nearly every
session – a median of 14 clicks before the first result gets opened.
Support has logged 23 requests for "remember my filters" in the last
quarter.

## Goals

- A signed-in user can save the current filter set under a name.
- Saved filters apply in one click from the search sidebar.
- First-week adoption: 15% of weekly-active searchers save at least one
  filter set.

## Non-goals

- Sharing saved filters with teammates (follow-up if adoption lands).
- Saved filters on the mobile web view.
- Auto-suggesting filter sets from behavior.

## Proposed solution

A "Save filters" action in the search sidebar when at least one filter is
active. Saving prompts for a name (pre-filled from the filter summary,
e.g. "Open · assigned to me · this week"). Saved sets list at the top of
the sidebar, apply on click, and support rename and delete from an
overflow menu. Cap: 20 saved sets per user.

## Phases

| Phase | Scope | Exit criterion |
|---|---|---|
| 1 | Save, apply, delete | Feature-flagged to the team, dogfooded one week |
| 2 | Rename + ordering | Flag opens to 10% of users |
| 3 | Full rollout | Adoption metric ≥ 15% or a written decision to iterate |

## Open questions

- Does applying a saved set replace current filters or merge with them?
  (Leaning replace – merge makes the result unpredictable.)
- Do saved sets sync across devices at phase 1, or is per-device enough?

## Measurement

- `filter_set_saved`, `filter_set_applied` events with set size.
- Weekly cohort: % of searchers with ≥1 saved set; clicks-to-first-result
  before vs after.
````