编辑导语：本文作者和大家分享了做创业团队中的产品经理的一些感悟和产品工作流程，包括市场调研、需求分析、产品规划设计、需求评审、协调跟进、产品测试和上线后反馈改进，希望对大家有所帮助。

宇宙的尽头是考编，那产品经理的尽头是什么？

本篇文章是创业记录的产品篇，本来想要写的内容很多，最终还是决定聚焦在创业团队产品经理的一些事儿。

我大学毕业的第一份工作是程序员，但相较于需要遵循既定规则的编码工作，我更喜欢做有创造属性的产品工作。从程序员转行产品经理，是有加分项，但由于没有系统性的学习产品相关知识，同时也面临不具备产品技能、缺乏产品方法论、无项目经验等困境，所以经历了很长一段海投简历却鲜有回复或面试一轮便不了了之的“至暗时刻”。

我没有大厂的工作经历，所以我这里分享的也是基于自己在中小企业、创业团队中的经历。

在正式进入产品工作之前，往往是从老板、业务团队、竞品、用户处获取新想法或者行业新的发展趋势，从而形成新需求。

一个完整的产品工作流程包括：市场调研、需求分析、产品规划设计、需求评审、协调跟进、产品测试、正式上线、产品培训、收集反馈、持续改进。这里面也包含了产品经理的工作职责和基本能力，下面我结合自己的亲身经历，和大家分享一下这些流程中的一些事儿。

一、市场调研

市场调研一般包括用户调研和竞品调研。

1. 用户调研

用户调研是指通过包括但不限于问卷、现场访谈等方式获取受访者的痛点、建议、意见等，并针对用户调研获取的信息进行统计分析，从而具象为用户具体需求或解决方案。

我们的用户以政府、公安、企事业单位为主，他们对于问卷调查这类调研方式往往不太关注，也不会认真对待。经过两次问卷调查发现调研结果不太理想后，我们也减少了问卷调查。当我们在产品方向上有新的想法或改动后，就通过即时通讯工具或者现场调研会的方式，与用户中的特定人群进行正式或非正式的沟通。

不管是TO G还是TO B类型的产品，往往业务链路长、业务流程复杂、涉及角色多。每次调研之前我们都需要明确本次调研的目标，在调研过程中也要一直紧扣主题，严格控制讨论的边界，防止出现会议主题跑偏的情况。

不管是我们自身还是用户的时间、精力都是非常有限的，如果我们每次的调研会没有达到想要的效果，从而出现多次反复谈论的情况，用户也会表现出不耐烦、甚至质疑能力的情况。

2. 竞品分析

竞品调研主要包括竞品定位调研、功能分析、商业模式分析。

要知道在TO B或者TO G领域，一般来说没有哪一款产品能够解决某个业务场景的所有问题。

比如我们行业内的一家竞品公司的产品，更多地聚焦在业务前期的委托受理和特定业务进行中常规状态下的业务过程处理，另一家则更多地聚焦在通用场景的标准化处理过程。两家公司的产品定位有重合，也有不同之处。而我们希望在这条赛道上能杀出一条路来，产品就必须有其他的亮点，毕竟打败微信的一定不是另外一个微信。

经过与用户沟通，我们得知由于近几年司法行业的整顿，用户对业务处理过程中的操作行为留痕、文书归档、问题规避有非常强烈的需求，所以我们产品的定位就聚焦在司法行业业务处理过程规范化以及司法文书线上归档，致力于为用户规避业务操作中的问题，完善问责制度。

相信很多产品经理都做过功能分析，特别是在产品功能设计的时候。毕竟友商之间“互相借鉴”都是司空见惯的事情。但我们借鉴的时候，要知其然也要知其所以然。

最开始我使用竞品的产品时，发现有很多莫名其妙的操作，明明可以非常简便的完成某个流程，但竞品却设计得异常复杂，但当我认真梳理业务流程、政策文件时，才发现是出于业务流程需要和政策要求。

作为产品经理，我们在使用任何一款产品的时候，其实都可以养成有意识地去理解产品设计背后逻辑的习惯，这也有利于我们在后续的工作中明确思路和参考“复用”。

在我最开始做竞品分析的时候，最容易忽略的就是商业模式的分析，上周在“人人都是产品经理”上，看到一位作者详细地讲了讲商业模式与盈利模式的区别，获益匪浅。文章里面提到，“商业模式=推广模式+用户模式+产品模式+盈利模式”。

虽然我们做任何一款产品都是为了盈利，但应该先梳理用户群体，明确提供产品的方式，做好推广，最终才能实现盈利。这些要素加起来形成了一个完整的商业模式。

我们对竞品的商业模式的调研也会反向给我们提供思路。我还是以我们的竞品为例，一家竞品仍采取以传统的项目建设收费、按年收费、按照使用数量收费等收费方式。

而另一家则免费建设，按照用户案件的涉案金额或催收还款金额比例提成收费。同时包括与其他各大司法机构合作形成数据互通。各大司法机构保证案件数量，他们通过系统建设和技术服务的方式，保证案件成功率，以此形成对赌框架。

两家公司的商业模式各有利弊，第一家更为稳定但利润率较低，第二家风险相对较高但利润率也较高。分析竞品商业模式也是为了自己产品在形成商业模式上提供思路，形成一套完善的商业模式，当然具体怎么选择商业模式也要看团队所处阶段和团队成员的秉性。

3. 政策调研

由于我们的产品和项目主要聚焦在“网络安全+司法”领域，产品的需求和改动有很大一部分来自于法律法规、政策、国家标准、行业标准的变动，所以我平时除了用户调研和竞品调研，还会关注相关法律法规、政策的变动，甚至在必要的时候也会邀请行业内专家对政策进行解读，以便我们更好地理解政策用意和明确我们的解决方案。

二、需求分析

我在《售前篇》里写售前工程师的“听说读写”，其实“读”就是用户需求分析，搞清楚用户的显性需求和隐性需求，读懂用户的真实想法。但产品经理的工作粒度更细，会涉及到每一个功能点的设计，也会影响研发同事的研发进度和排期，所以产品经理的需求分析也需要更细化。

我一般会从三个维度来分析需求：

1. 真需求or伪需求？

首先说一说真需求还是伪需求，我们接受需求的来源可能是客户、公司老板、销售团队、技术团队等，每个角色可能都是站在自己的角度提出需求。但“屁股决定脑袋”，我们不能盲目听从他人的建议，我们也没有办法满足所有用户。

比如有一次我们技术团队提出，考虑到数据的安全性，是否需要设置用户在登录情况下半个小时不操作，就自动退出登录。一开始我还非常高兴并且采纳了技术团队的建议，上线后却遭到用户强烈吐槽频繁的重新登陆。

原因是用户操作系统的环境是在一个有严格权限控制的物理环境，不会存在有其他相关人员能够随意进出和操作的情况，这就是我之前没有结合实际情况判断需求真伪。

真需求还是伪需求有几个简单的判断标准：

• 需求提出方是不是我们的真实用户；
• 是个性化需求还是通用需求；
• 需求是否和公司的利益存在冲突。

所以不光研发会砍产品经理的需求，产品经理自己也要学习砍需求。

2. 需求背后的缘由？

搞清楚需求背后的缘由是为了在产品规划设计的时候，能够达到用户希望的效果。这个时候我们需要从用户的真实使用场景、实际业务流程、操作的频率入手，深入了解，以此才能在系统设计时找到更好的解决方案，当然在设计过程中也要持续与用户保持沟通，以避免错误理解需求或设计问题。

3. 需求是否紧急？

需求是否会影响到用户的日常使用？不及时上线是否会对用户或公司带来损失？是否还有更重要的功能需求？这些都是影响需求排期的关键因素，所以需求需要区分优先级、重要性，也要充分考虑公司战略、投入产出比、团队资源等因素。

比如我们创业团队的开发资源永远是有限的，对于非紧急或并不那么重要的需求往往先放入需求池，等到后面版本再实现。

三、产品规划设计

我理解的产品规划设计其实是两个层面的事情，“规划”和“设计”其实是两个层次的工作。

产品规划是相对于需求的具象。相对产品设计的抽象，产品规划包括业务流程梳理、产品架构梳理、产品功能梳理，当明确用户需求之后需要对整个业务流程通过图表的方式进行可视化的展示（Visio、Excel等），把所有流程、角色、节点、条件都罗列出来。

在梳理的时候要通盘考虑避免遗漏，这里可以自己整理一个查漏补缺表，通过查漏补缺表单和流程对应检查是否缺失。产品架构梳理到产品功能梳理也是由抽象到具象的过程，我们首先通过梳理流程将不同业务流规划成不同的系统板块，再根据不同的系统板块梳理罗列对应的功能点。

比如我曾做过的一个产品，上级用户向下级用户下达的指令有不同的类型，而不同的指令类型的业务流程不同，我们就在梳理框架的时候将不同指令作为不同的系统模块罗列。

某类指令的实效性相较于其他指令的实效性更强，这类指令就需要加上即将逾期、已逾期等功能属性，再根据不同的指令类型的流程和需求进一步明确功能点，这样就可以从粗粒度的框架细化到细粒度的功能点。这样做的好处是既可以避免功能模块的遗漏，也可以避免因业务流程繁杂而导致规划混乱的情况。

产品设计简单来说就是将罗列出来的功能点，通过可视化的方式展示（包括原型图、PRD文档）。

曾经刚入行的时候一直以画好原型图为终极目标，后来才发现画原型是基本能力，而非核心能力，前期的调研、需求分析是输入，原型图、PRD是经过梳理思考和严密逻辑推理后的输出，原型设计的意义在于节省与客户、研发、UI、测试等沟通成本和降低大家的理解成本，可以让各方人员更明了地理解产品的功能与流程。

对于是高保真还是线框图，也是根据不同公司的要求因人而异。重要地不是把原型画得多漂亮，而是能在原型设计图中将需求点讲清楚。我一般更习惯用线框+简单的交互，复杂交互我选择用文字的方式梳理。

四、需求评审

其实我们做产品就是一个重复输入、输出的过程。需求调研（输入）——>产品规划设计（输出）——>需求评审（输出&输入）——>原型调整（输出）。

需求评审是每一个产品经理都会经历的过程，产品在迭代，需求在更新，需求评审也会一直持续。

其实需求评审会最需要解决的问题就包括：

（1）向团队成员传达解释需求价值（why），为什么会有这样一个需求，我们为什么要做？

我们开需求评审会的成员可能包括：公司老板、业务部门负责人、研发、测试、UI等，需求的实现其实都是技术部门而非业务部门，他们可能对业务的理解和需求的价值并没有老板、业务负责人、产品经理深。在让技术部门实现功能之前，要做到知其然，也要知其所以然。

很多时候研发的同事认为，第一次需求确定了就不要再改了，每次让他们修改之前的需求，总是需要软磨硬泡，还会质疑需求的合理性。但是市场在变化，客户也在变，我们的产品更需要随之调整。

传达需求价值既是为了让团队成员对业务和需求的理解更清晰，也是为了让他们知道这个需求并不是拍拍脑想出来的，更容易让他们接受，也可以增强对你的信任感。

（2）向团队成员输出需求的具体规划（what），这个需求的具体流程是什么，功能是什么？

会前我都会自己过一遍具体的规划，再次梳理规划的链路，保证能在会上更够简单、直接、明了地向团队成员介绍。

会上首先通过思维导图、流程图的方式，让团队成员对系统的规划设计有一个初步的印象。然后再通过原型图的详细说明，完整表达规划思路。在这个过程中会穿插一些问题的讨论，这个时候就需要充分听取团队成员的意见和建议。

虽然大家都说我们要把自己当成用户，但由于我们作为团队内部最熟悉业务流程的人，产品设计一定会有主观元素在里面，有时候就难免会有一些设计不当考虑不周的地方，这个时候团队成员可能更容易站在用户视角看待问题。

（3）与团队成员协商需求的实现过程（how），功能如何实现，由谁实现，实现的周期？

任务分配、周期明确也是评审会的一个非常重要的环节，计划出来了得有人具体实施。这个就需要根据需求的轻重缓急、团队资源、成员排期具体协商。

还有一些事情需要注意：

1. 会前充分准备，提前将相关资料文件与团队成员共享，以避免团队成员需要现场熟悉会议资料；
2. 不要太玻璃心，有时候我们可能会出现产品规划的时候有逻辑漏洞的情况，而被研发同事批得体无完肤，这个时候应该勇敢承认自己的错误；
3. 会中注意控场，避免讨论问题边界太过发散；
4. 会议结束前就关键问题进行总结，确保大家对本次会议的议题达成共识；
5. 会后及时做会议纪要，避免未参会人员仅能得知零散信息，导致产品推进进度慢。

五、协调跟进

我们没有专职的项目经理，产品经理兼任项目经理。产品研发迭代过程中，由产品经理作为桥梁对上汇报、对下传达，同时负责把控产品开发周期与进度，跨部门的协调沟通。

需求明确后，我一般会与研发负责人一起分解任务（细化到具体功能点），最终形成任务清单和里程碑；了解目前研发同事手里任务多寡，进而进行任务的分派；同时也会让同事对分派任务进行再次确认（签字画押），以增强目标感和责任感。在整个研发过程中，我也会每天了解研发进度，以便及时发现并调整进度偏离的问题。

产品经理还有一个很重要的职责就是跨部门甚至跨公司的协调，研发同事往往更喜欢闷头自己做自己的事情，对于这类协调沟通的事情不太擅长也不太情愿。产品进入研发阶段，作为产品经理更多也是协助研发同事能够顺利推进产品研发。

对外协调我们可能需要主动“组局”，比如我们经常都会遇到与第三方公司接口联调的情况，而跨公司协作就经常会出现沟通问题、时间问题。我们需要提前把两家公司的相关人员聚集起来共同制定目标，约定调试时间，以免出现一方长时间等另一方的情况（毕竟大家的时间都很宝贵）。

对内我们也需要及时协调沟通，比如后端开发已经把所有功能接口完成了，但前端还在等UI设计图，导致项目会出现停滞的情况。这些都是我们需要去解决的。

六、产品测试

严格来说产品测试的时间和产品开发的时间应该是一半一半。

没有经过系统化的测试，大概率在正式环境中会出现很多问题。产品测试也不能仅仅QA部门，作为产品经理，你是设计产品的人也是最熟悉产品的人。

测试阶段前将测试用例写好真的非常重要，我们要把每一个需要测试的分支项详细罗列，对于需要重点测试的板块也要提醒，标注测试方法和预期结果，不管是我们自己测试还是QA测试，甚至全员测试的时候大家方便对照。

我一般会在交给QA部门前，自己进行至少2-3次的系统性测试，在测试过程中也会发现一些自己以前没有考虑周到，研发也没有发现的问题，这样做也是为后面测试的同学节省时间（因为我们的资源真的很紧张，我们几条产品线并行，但测试人员也严重不足。）

我们测试问题一般是放在禅道上，然后指派给对应的研发同事，研发同事修改完善后记录，再进行回归测试。虽然我不是专业的QA，我们的测试流程也没有大厂那么严谨，但在不断地摸索过程中也发现了一些容易出错的点，总结了一些方法。

七、上线、反馈、改进

产品做得怎么样，就需要上线后交给用户来评判了。

不管是项目还是产品都是周期的，一定会有一个开始节点和关闭节点。诺兰模型把系统的周期分为初始期、普及期、控制期、整合期、数据管理期和成熟期，周期之间都必须从一个阶段发展到下一个阶段，不能实现跳跃式发展，这些周期也对应了我们产品优化迭代的进度。

没有十全十美的产品，没有能够满足所有用户的产品。包括微信才出来的时候，同样也有很多不尽如人意的地方，他们同样也是通过建立反馈机制，搜集数据，不断地改进才有了现在的样子。

我们做产品同理，我曾经听到一句话“如果我们不能做到一鸣惊人，那就先以破烂示人”，深以为然。我们可以允许前期产品的缺陷，这些缺陷或许是我们了解用户不够、或许是我们思考不到位、或许是我们团队资源不足，但我们要以良好地心态去面对去解决，破烂是一时，改进才是常态。

面对用户的反馈，拥有良好心态也是非常重要的。无论是吐槽还是谩骂，我们都要本着做产品的初心去面对。有人吐槽说明他们是真的在用，没人反馈才是最糟糕的。我们要学会主动去过滤无用信息，主动寻找并听取有效建议。

以上是我基于一个完整的产品工作分享的一些思考感悟。

回到文章最开始的问题，产品经理的尽头是什么？在我看来产品经理没有尽头，只有无止尽的学习和思考，不断地输入再输出。

人人都可以是产品经理，但不是人人都可以做好产品经理。

本文由@蹦蹦怪 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Pixabay，基于CC0协议