详解产品经理必懂的10套文档

​

​

一个反直觉的观点：模板不是用来填的，是用来逼你思考的​

模板的本质是把一个复杂问题拆解成一系列必须回答的子问题。你填不出来某个章节，不是因为你懒，是因为你对这个问题的思考还没到那个深度。​

举个例子。需求文档里有一个章节叫需求优先级。大部分人怎么填？重要、紧急、一般，完事了。​

但如果你真的理解这个章节存在的意义，你会发现它在逼你回答三个问题：​

这个需求不做会死吗？​

这个需求做了能显著改变核心指标吗？​

这个需求的投入产出比是多少？​

填不出来这三个问题的答案，说明你对这个需求的理解还停留在表面。模板在这个时候的作用，不是让你快速产出一份文档，而是暴露你思考的盲区。​

​

🧠

竞品分析不是为了证明别人也在做这个功能，所以我们也要做。它的真正作用是回答两个问题：​

竞品是怎么解决这个问题的？他们的方案有什么优缺点？​

我们能不能做得更好？如果不能，为什么还要做？​

​

想明白这两个问题，竞品分析这一章自然就写出来了。写不出来，说明你还没想清楚这个需求到底该不该做。​

10 套模板的底层逻辑：它们在解决什么问题​

我把产品经理最常用的 10 套文档模板按照产品生命周期排了个序。不是按照你写文档的顺序，而是按照这些文档在解决什么问题的逻辑顺序。​

市场分析文档​

市场分析解决的核心问题是：这个市场值不值得进入，以及进入之后的打法是什么。​

一个团队花了半年时间做了一个 SaaS产品，功能做得很完善，结果上线之后发现目标客户根本不愿意为这个功能付费。不是产品不好，是他们选错了市场。​

市场分析文档的核心：​

•

市场规模：这个市场有多大？增长趋势如何？​

•

目标用户：谁会为这个产品付费？他们的痛点是什么？​

•

竞争格局：这个市场里有哪些玩家？他们占据了什么位置？​

•

切入点：我们从哪个角度切入？为什么是这个角度？​

​

​

用户画像文档​

用户画像不是写一个虚拟人物的简历。​

用户画像的本质是回答三个问题：​

用户的核心诉求是什么？（不是需求，是诉求）​

用户在什么场景下会产生这个诉求？​

用户现在是怎么解决这个诉求的？为什么不满意？​

一个电商团队做用户画像，他们一开始写的是：目标用户是 25-35 岁的女性，喜欢网购，追求性价比。​

这不是用户画像，这是用户标签。​

后来我们重新做了一次用户访谈，发现真正的用户画像是这样的：​

​

🖌️

她们不是追求性价比，她们是害怕买贵了被老公说浪费钱。她们不是喜欢网购，她们是没时间逛街。她们真正的诉求是：在有限的预算内，买到不会出错的东西。这才是用户画像。​

它告诉你的不是用户是谁，而是用户为什么会用你的产品。​

​

​

​

竞品分析文档​

竞品分析最大的误区是把它当成功能清单对比。​

A 产品有 20 个功能，B 产品有 18 个功能，所以 A 产品更好。这是小学生思维。​

竞品分析的核心是理解竞品的产品策略。​

从三个维度拆解竞品：​

核心功能：竞品用什么功能留住用户？这个功能解决了什么核心问题？​

增长策略：竞品怎么获取新用户？付费还是免费？病毒传播还是广告投放？​

商业模式：竞品怎么赚钱？为什么选择这种赚钱方式？​

​

🔨

之前拆解一个竞品，表面上看它是一个工具类产品，免费使用，没有广告。我们一开始以为它是在烧钱做用户量，准备后期收费。​

后来发现不对。它的核心用户是企业，个人用户只是流量入口。它真正的商业模式是 to B，个人用户用得越多，企业就越愿意付费买企业版。​

​

这才是竞品分析的价值。它让你看清楚对手的底牌，而不是表面的功能列表。​

​

​

​

需求文档PRD文档​

需求文档是产品经理的基本功，但大部分人写得像功能说明书。​

需求文档的核心结构应该是这样的：​

需求背景：用户遇到了什么问题？这个问题有多严重？​

解决方案：我们用什么方案解决这个问题？为什么选择这个方案？​

功能设计：具体怎么实现？交互流程是什么？​

数据指标：怎么衡量这个需求做成功了？​

很多人写需求文档，直接从第 3 步开始写。这就是为什么技术同学看完需求文档之后，第一句话永远是：为什么要做这个功能？​

有个产品经理写了一个需求，要在首页加一个推荐位。我问他为什么，他说因为运营要推广新功能。这不是需求背景，这是需求来源。​

​

🏷️

真正的需求背景是：新功能上线一个月，使用率只有 3%，远低于预期的 15%。我们分析了用户路径，发现 80% 的用户根本不知道这个功能在哪里。所以我们需要在首页增加一个推荐位，提高功能的曝光率。​

这才是需求背景。它告诉技术同学，我们不是在做一个推荐位，我们是在解决功能曝光不足的问题。​

​

​

​

交互设计文档​

交互设计文档不是画原型图。​

原型图只是交互设计的一部分。真正的交互设计文档要回答的是：用户在什么场景下，通过什么路径，完成什么任务。​

我一般会用三个维度来设计交互：​

任务流程：用户要完成这个任务，需要经过哪些步骤？​

异常处理：如果用户操作失败了，系统怎么反馈？用户怎么恢复？​

边界条件：极端情况下（网络差、数据量大、权限不足），产品怎么表现？​

一个支付功能，产品经理画了一个很完美的原型图。用户点击支付，跳转到支付页面，输入密码，支付成功。​

如果用户支付失败了呢？如果用户支付到一半退出了呢？如果用户重复点击支付按钮呢？​

这就是交互设计文档的价值。它逼你思考所有可能出现的情况，而不是只考虑理想路径。​

​

​

数据埋点文档​

数据埋点文档是最容易被忽视的文档，但它决定了你能不能用数据驱动产品迭代。​

很多产品经理写埋点文档，就是列一个事件清单。用户点击了什么按钮，浏览了什么页面，完事了。​

真正的埋点文档要回答的是：我们要验证什么假设？需要采集什么数据？​

去年做一个功能，产品经理说要埋点统计用户点击次数。我问他，统计点击次数是为了验证什么？​

​

🔎

他说，验证用户对这个功能感兴趣。​

我说，点击次数不能验证用户感兴趣，只能验证用户看到了这个功能。真正要验证用户感兴趣，你应该埋点统计用户完成任务的比例，以及用户在这个功能上停留的时长。​

​

​

​

测试用例文档​

测试用例文档不是测试同学的事，是产品经理的事。​

很多产品经理觉得测试用例是测试同学写的，跟自己没关系。错了。​

产品经理写测试用例，不是为了找 bug，而是为了确保产品逻辑的完整性。​

我一般会从三个维度写测试用例：​

正常流程：用户按照预期路径操作，产品表现是否正确？​

异常流程：用户操作失败、网络异常、数据异常，产品是否有合理的反馈？​

边界条件：极端情况下（数据为空、数据超长、权限不足），产品是否崩溃？​

​

​

技术方案文档​

技术方案文档不是产品经理一个人写的，但产品经理必须参与。​

很多产品经理觉得技术方案是技术同学的事，跟自己没关系。错了。​

技术方案文档解决的核心问题是：有哪些技术实现方式？每种方式的成本和风险是什么？​

技术方案文档的核心章节：​

方案对比：有哪些可选方案？每个方案的优缺点是什么？​

技术可行性：这个方案技术上能实现吗？需要多少资源？​

风险评估：这个方案有什么风险？如果失败了怎么办？​

有一段时间做一个功能，有两个方案。方案 A 功能完善，但开发周期长。方案 B 功能简单，但能快速上线。​

产品经理选了方案 A，理由是功能更完善。​

我问他，你有没有评估过风险？如果方案 A 开发了三个月，上线之后发现用户根本不需要这个功能，怎么办？​

他愣了。​

后来我们选了方案 B，先快速上线验证用户需求，再根据数据反馈决定要不要做方案 A。​

这就是技术方案文档的价值。它逼你在动手之前，把所有可能的风险都想清楚。​

​

​

产品迭代文档​

产品迭代文档不是版本更新日志。​

版本更新日志是给用户看的，产品迭代文档是给团队看的。​

产品迭代文档的核心是回答三个问题：​

上一个版本做了什么？数据表现如何？​

这个版本要做什么？为什么做这些功能？​

下一个版本的方向是什么？​

要看数据，看这个功能影响了多少用户，解决了多大的问题。​

​

​

复盘文档​

复盘文档是最容易被忽视的文档，但它是产品经理成长最快的方式。​

很多团队做复盘，就是开个会，大家说说做得好的地方和做得不好的地方，然后散会。​

这不是复盘，这是吐槽大会。​

真正的复盘文档要回答四个问题：​

我们的目标是什么？实际结果是什么？​

为什么会出现偏差？是假设错了，还是执行出了问题？​

如果重新做一次，我们会怎么做？​

这次经验对未来的产品决策有什么启发？​

​

🗂️

用户不喜欢是结果，不是原因。真正的原因是什么？是我们对用户需求的理解错了？还是功能设计有问题？还是推广不到位？​

做了一次深度复盘，发现真正的原因是：我们假设用户会主动探索新功能，但实际上 90% 的用户根本不知道这个功能在哪里。​

​

​

​

最后说一句​

重要的是你理解每套模板在解决什么问题，以及为什么要解决这个问题。​

当你真正理解了这一点，你会发现，模板只是工具，真正重要的是你的产品思维。​

而产品思维，是用模板逼出来的。​