prd-writing

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Write PRDs that are evidence-first, concise, and scannable. A PRD is a thinking tool — if it's longer than 1200 words, the author hasn't thought hard enough. Brief specs are more likely to be read, more likely to be followed, and more likely to ship on time.

撰写以证据为核心、简洁易读的PRD。PRD是一种思考工具——如果篇幅超过1200字，说明作者还没有想透彻。简短的规格文档更有可能被阅读、被遵循，也更有可能按时交付。

Structure

结构

Follow this structure. Every section is mandatory unless marked optional.

遵循以下结构。除非标记为可选，否则每个部分都是必填项。

1. Problem

1. 问题

Lead with customer evidence. Quotes, data, support tickets, observed behavior. If you have no evidence, say so explicitly — that's an opinion-driven PRD and should be flagged.

Example:

"3 of 5 interviewed customers abandon onboarding at the team invite step. Average time spent: 47 seconds before closing the tab."

NOT: "Users find onboarding confusing."

以客户证据开篇。比如用户引用、数据、支持工单、观察到的行为。如果没有证据，请明确说明——这属于基于主观意见的PRD，需要标记出来。

示例：

"5位受访客户中有3位在团队邀请步骤放弃入职流程。平均耗时：47秒后关闭标签页。"

错误示例："用户觉得入职流程令人困惑。"

2. Goals

2. 目标

Measurable outcomes, not outputs. Each goal has a number attached.

"Reduce onboarding drop-off from 60% to under 30%"
NOT "Improve the onboarding experience"

可衡量的结果，而非产出。每个目标都要有对应的数值。

"将入职流程流失率从60%降低至30%以下"
错误示例："优化入职体验"

3. Target Users

3. 目标用户

Who specifically benefits. Be narrow. "Series A startup founders doing PM work before their first PM hire" — not "product managers."

具体的受益人群。范围要精准。比如“A轮创业公司创始人，在招聘首位PM前兼任产品工作”——而非“产品经理”。

4. Requirements

4. 需求

Use P0/P1/P2 with clear definitions:

P0 — Does not ship without it. The feature is broken or useless without this.
P1 — Ships without it, but significantly degraded. Do in same cycle if possible.
P2 — Nice to have. Candidate for fast follow.

Each requirement is one sentence. If a requirement needs a paragraph to explain, it's too big — break it down.

使用P0/P1/P2分级，并明确定义：

P0 — 没有它就无法上线。缺少此项，功能会失效或毫无用处。
P1 — 没有它也能上线，但体验会大打折扣。尽可能在同一周期完成。
P2 — 锦上添花的功能。可作为后续快速迭代的候选项。

每条需求只用一句话描述。如果某条需求需要一段文字来解释，说明它太宽泛了——拆分它。

5. Success Metrics

5. 成功指标

Numbers. Always numbers. "Reduce X from Y to Z within W weeks."

ALWAYS pair each metric with a counter-metric to prevent gaming:

Metric: "Increase activation rate to 70%"
Counter-metric: "Without decreasing 30-day retention below 45%"

用数值说话。永远要有数值。“在W周内将X从Y降低至Z。”

务必为每个指标搭配一个反向指标，防止数据造假：

指标：“将激活率提升至70%”
反向指标：“同时确保30天留存率不低于45%”

6. Out of Scope

6. 超出范围

What you are deliberately NOT building and why. This section prevents scope creep and signals that you've thought about boundaries.

明确说明你刻意不做的内容及原因。此部分可防止范围蔓延，也能体现你已经考虑过边界问题。

7. Open Questions (optional)

7. 待解决问题（可选）

Unresolved decisions that need input. Each question names who should answer it and by when.

尚未解决、需要输入的决策事项。每个问题要注明应由谁回答以及截止时间。

Guidelines

指南

CRITICAL: 800-1200 words maximum. Longer PRDs mean the thinking isn't done.
NEVER start from a solution. Start from a problem with evidence.
NEVER include implementation details — architecture, APIs, database schemas. That's spec territory, not PRD territory.
ALWAYS include Out of Scope. A PRD without boundaries invites scope creep.
ALWAYS trace requirements to customer evidence. No evidence = opinion.
NEVER use weasel metrics: "improve performance," "enhance experience," "increase engagement." Put a number on it or don't include it.
P0 requirements should number 3-5. If you have more than 5 P0s, you haven't prioritized.

关键要求：篇幅控制在800-1200字以内。过长的PRD说明思考还未到位。
绝对不要从解决方案入手。要从有证据支撑的问题开始。
绝对不要包含实现细节——架构、API、数据库模式。这些属于技术规格范畴，而非PRD范畴。
务必包含“超出范围”部分。没有边界的PRD会引发范围蔓延。
务必确保每条需求都能追溯到客户证据。没有证据=主观臆断。
绝对不要使用模糊指标：“提升性能”、“优化体验”、“增加参与度”。要么给出数值，要么不要写。
P0需求数量应控制在3-5个。如果超过5个，说明你还没有做好优先级排序。

Example: Good vs Bad

示例：优劣对比

Bad P0 requirement:

"The system should handle authentication in a secure and user-friendly manner, supporting multiple providers and edge cases."

Good P0 requirement:

"P0: User can sign up and log in with email + password. Google OAuth is P1."

One sentence. Clear scope. Priority forces a decision.

Built on Linear's "short specs > exhaustive docs" philosophy. Skills from productskills.

糟糕的P0需求：

"系统应以安全且用户友好的方式处理身份验证，支持多种提供商和边缘情况。"

优秀的P0需求：

"P0：用户可通过邮箱+密码注册和登录。Google OAuth为P1级别。"

一句话描述，范围清晰。优先级强制做出决策。

基于Linear的“简短规格优于详尽文档”理念。技能源自productskills。",