Войти сейчас 一年前写过一篇用 Axure 输出 PRD 的文章，发出来之后，陆续收到不少反馈。大家提得比较多的，集中在几个问题上：需求分析不够透彻，产品设计不够严谨，异常流程考虑不周全，逻辑规则容易遗漏。还有一些刚入行的朋友，对产品从零到一到底要做哪些事、需要产出哪些文档，也特别好奇。
其实产品经理的日常工作，本来就没有统一的标准定义，不同公司、不同阶段的做法差别很大。所以我把这些年踩过的坑、反复验证过的做法梳理了一下，整理成了上下两篇《产品经理工作指南》。这篇内容只聚焦在“产品功能和设计”这条线上，日常沟通、项目管理、资源协调这些先不展开。上篇从产品评估、产品需求、产品结构和流程三个方面来讲，下篇再单独聊原型设计和逻辑规则。
先做一份靠谱的产品评估
产品从零到一，很多人第一反应就是赶紧画原型、写需求文档，恨不得第二天就扔给开发。但真正该做的第一件事，其实是先冷静地做一次产品评估，把“我们到底要做什么”“值不值得做”这些问题想清楚。这件事如果没做透，后面所有的努力都可能白费。
我习惯把产品评估拆成十四个维度，每次启动新项目，都会逼着自己一条一条过一遍。
首先要搞清楚用户到底有什么忍受不了、反复出现的问题，也就是背景和痛点。接着要回答：产品究竟要解决什么，核心价值在哪里。目标用户是谁，市场大致规模有多大，这些决定了天花板。解决方案必须落到产品的核心功能上，不能飘在空中。
产品目标一定要用数据说话，没有数据的目标在我看来就是不合格的。而且这个目标要能拆解到每一条子项目线上，并据此制定策略，否则就没有抓手。衡量指标也得提前想清楚，将来怎么判断这个产品算成功了，是留存率、转化率还是别的什么。
市场时机同样容易被忽视。太早切入，用户教育成本太高；太晚，红海一片，很难出头。结合竞争格局来看会更清晰：同类产品和竞品有哪些，它们的功能和体验怎么样，用户还有哪些痛点没有被满足。尤其要想清楚，为什么我们来做这件事更合适，竞争对手满足不了的地方，可能就是我们的护城河。在这个模仿成本极低的时代，没有护城河的产品很容易被替代，这一点怎么强调都不过分。
渠道和营销策略也不能等产品做完再想。有没有现成的合作伙伴，怎么把产品推向客户，这些都需要提前盘算。必要条件是指那些缺了就没法落地的硬性条件，比如某类资质、某种技术能力，必须列出来。成本分析要覆盖开发成本、获客成本、销售成本、人力成本等方面，收入分析则要算清楚利润模式、预期收入和毛利。
全部评估完，如果结论是确实值得做，那再进入下一步。如果评估下来发现风险远大于收益，及时止损反而是更明智的选择。当然，现实里经常是老板或领导拍板要做，这时候我们能做的最有价值的事，就是把这份评估报告交上去。领导可能确实有更深层的考虑，也可能之前没想得那么细，但有了这份报告，至少能提前避开一些明显的大坑。
把需求捋清楚，别急着动手
产品评估完之后，直接进入设计还是太早，中间还隔着一道关键的工序，就是自查产品需求。这块我把它分成需求收集、需求分析和需求管理三个步骤。
需求收集的门路其实很多，用户访谈、问卷、实地调研、数据分析、业务部门提过来的要求，都是常见来源。线上产品的 bug 修复、性能优化、体验改善，也属于广义的需求收集。关键是找到适合当前公司和产品阶段的方式，不要为了做而做。
拿到需求之后，最重要的一步是需求分析。这里有一个原则我很早就听前辈说过，后来自己反复验证过：千万不要直接听用户的，尤其是用户自以为是的解决方案。这里的“用户”是广义的，不光指终端用户，也包括老板、领导、运营、客服同事。他们经常会说“给我加一个按钮”“做个这样的功能”，但背后的真实诉求往往需要往下挖一两层。
我会用 KANO 模型和四象限法则，把那些无用的需求、反向需求筛掉，挖掘深层含义，找到真正的需求，再把它表达成产品解决方案。也就是说，用户的问题要转化成产品需求，并且排好优先级，这时候才真正进入设计环节。
需求管理也不能只靠脑子记。我会把收集到的所有需求先放进一个需求问题池，注明需求描述、来源、提出时间、状态、解决方案、分析人和处理时间。需求描述要说清楚用户的问题、需求和目标；来源要标清楚，后面如果需要沟通，马上能找到人。状态里特别要区分“未分析”“未解决”和“已确认为产品需求”。对于决定不解决的需求，一定要写清楚原因：是伪需求、重复需求，还是可以通过其他方式实现，否则以后翻出来容易反复扯皮。
需求分析之后，那些被确认的产品需求，我会汇总到需求跟踪矩阵里，记录下从确认到规划、开发、测试的每一个状态。矩阵里通常包括需求功能名称、概述、类型、属性、优先级、来源、状态、对应的原型和文档、完成时间、责任人等。这里我想特别强调一下“需求属性”这一栏，我会把需求标成原始需求、修改需求、增加需求、删除需求。每次版本迭代结束后复盘，如果发现原始需求的比例偏低，那就说明在需求分析阶段可能思考得不够全面、不够严谨，这就是一个很好的自我提醒。
想清楚结构再动手，避免边做边改
当真实的产品需求梳理清楚之后，终于可以进入具体设计阶段了。如果是新产品或者大功能模块，我一定不会跳过产品结构设计这一步。
产品功能结构图是首先要画的。它解决的问题是：模块划分合不合理，功能层次清不清晰，分类有没有逻辑，每个模块下面到底包含哪些功能。很多人容易把功能结构图和信息结构图搞混，两者重点不同，这里就不展开了。但有一点很重要：通过功能结构图，你能提前发现有没有遗漏某个功能分支，或者有没有把不同层次的东西硬塞到一起。
如果涉及前后端、客户端、服务端或者多个系统之间的数据交互，就必须画系统交互图，也就是时序图。它描述的是对象之间怎么交互，信息怎么发送和接收，能把复杂的数据流转说清楚，开发看了也会觉得踏实很多。
业务流程图更贴近用户视角。它描述的是操作顺序和管理信息的流向，画的时候基本按照业务的实际处理步骤来。不管是 APP 还是管理后台，你都可以简单理解成：用户怎么做，系统就怎么反馈。这里需要花足够多的时间去推演，流程设计合不合理，异常流程有没有设计，逆向流程是不是考虑全面了，操作的容错性够不够。很多线上问题，回头一看，其实都是在业务流程某个转角处没考虑到。
这篇是《产品经理工作指南》的上半部分，下篇我会专门聊原型设计和逻辑规则，那也是很多同学容易踩坑的地方。我们下篇见。