6000字干货！完整梳理B端产品经理的工作内容-覆巢毁卵网

对于 B 端产品经理是做什么的，在之前做体验设计相关扫盲分享的理B理时候，就已经做了一定的端产说明。

没有看过的品经同学可以略过，这次我就要更具体介绍 B 端产品经理到底是工作什么经理，它在项目中要发挥哪些作用，内容以及作为什么角色存在。字干整梳

一、货完产品经理的理B理基本认识

产品经理也叫 PM（ Product Manager ），是端产负责规划产品功能并推进功能落地与实现的 "管理岗位"，也是品经互联网行业中最具有传奇色彩的职业，以乔布斯、工作马斯克、内容张小龙、字干整梳雷军为首的商业领袖都以产品经理自居，这也让产品经理被冠以 —— 离 CEO 最近的岗位的名号。

相信大家都知道当中存在很多捧杀的成分，如果产品经理就是 CEO 预备役，那么这个岗位的工作必然是和普通人、门外汉没什么关系的，门槛也会高到难以企及。

一个从业人数并不少的主流职业，当然没有传说中的那么遥不可及。但产品经理到底在做什么，网上的描述又都很模糊，不仅新手看不懂，很多工作了几年的 UI 设计师也没搞明白。所以在这里我不打算用归纳式的语言来讲解什么是产品经理，先从一个你们都能理解的场景切入。

比如，一家新的车企，在推出一款普通家用 A 级轿车车型后，想要丰富产品线推出第二个产品。根据市场部调研和领导层的分析，在战略上决定下一款车型，做面向中产群体的 7 座 SUV。

但光做决定，就让工厂开工生产，显然是不可能的。那么直接开始车型的外型设计，或者零件的采购，系统软件的开发，合理吗？当然也不合理。在做这些具体的工作之前，还有个更核心的问题，这辆车除了是 7 座 SUV 以外，需要四个轮胎和车身外，其它的关键指标和功能呢？

比如这辆车用什么发动机，前驱还是后驱，具备什么操控辅助和影像系统，内部配置中座椅或方向盘的特色功能，不同配置车型有哪些配置差异等大量的细节都需要提前确定好。而这就是 "产品经理" 要发挥作用的地方。

领导、市场部做更宏观的产品决策，但这些决策落地需要转化成具体的 "需求" ，让后面的不同部门有清晰的执行目标和方向。所以，产品经理的主要职责，就是作为一个中转站，将商业决策转变成可执行的任务，并下发给不同的执行方。

在互联网项目中，原理是一致的，产品经理的主要作用就是制定软件本身的功能明细，确保设计师知道要设计什么页面内容，以及让前后端程序员知道要开发什么模块和对应逻辑。这是产品经理最核心的职责。

而在一些特定的行业或中小企业，产品经理的责任会进一步扩大，除了要满足需求的制定外，也同时具备更宏观的商业决策权限。

最常见的比如老板自诩产品经理……或者在大厂有很多产品经理作为一个独立项目的负责人，他实质上就是这个项目团队的老板。这种情况并不是主流，但它们吸引了大众最多的关注，所以我们往往把这种领导岗位职能作为产品经理的标准注解，实际上占绝大多数的产品经理仅仅是我们前面所说的需求中转站。

但不管权限高还是低，需求的输出过程都是必要的，很多团队的问题就来源于有产品抬头的领导并不完成产品该有的任务，只做宏观的构想，但不给细节的明目，设计师和工程师团队只能在 "这是一辆有四个轮子的 SUV" 的要求下自己凭感觉完成工作，过程和结果都是灾难。

输出需求是产品的核心工作，但是，不代表你把需求做出来了就代表完成了工作，商业团队讲究 —— 产出质量。

虽然你完成基本的工作就是给出一辆车所需的全部功能规划，确保它能被制造并正常驾驶，但这肯定不够，还必须要满足对应的商业目标。比如让用户满意评价超过友商赚吆喝扩大知名度，还是在维持现有销量下降低生产成本扩大盈利率等。

所以应该做哪些功能，具体应该做成啥样，这些决策就是产品经理面临的最大的挑战。虽然这种决策没有战略层面这么宏观，但每次决策都会对后续的生产、交付、上线、收益产生影响。

换句话说，产品经理的工作就是设计出能满足商业目标的功能，但商业目标的实现通常都是后验的，方案再怎么吹得天花乱坠和发布后有没有实现预期完全是两码事。这就延升出进一步的要求 —— 产品经理要对上线后的结果负责。

既然要对上线的结果负责，产品经理的压力自然变得更大了，同时需要关注的事情也就更多。最直接的影响，就是方案是你自己定的，你就要确保设计和开发各自交付的结果符合你的预期，而不是最终交付出来的东西和你的方案牛头不对马嘴。

为了满足这个条件，产品经理就有义务干涉产品的研发阶段，检查设计成果和开发成果，而不是把需求内容抛出以后就不闻不问。因为成果和进度的协调不做管理的话整个项目工期就会无限膨胀下去，而产品经理对方案本身的理解和熟悉度又是职业项目经理无法取代的，这就是产品经理也要行使项目管理职能的主要因素。

到这里，我们再总结一遍产品经理是做什么的：

"在宏观的商业目标指导下，设计产品的功能，然后以特定文书形式交付给给执行团队，接着管理项目的整体进度确保最终落地效果符合预期，实现商业目标的工作。"

二、B端产品经理的工作内容

前面了解了产品经理的概念，到这里，我们就要更进一步来解释产品经理的工作内容和产出了。

但必须提前强调的一点是，产品经理也是一个很宽泛的抬头，和设计师一样，必须要圈定出范围才能讨论下去。比如界面、建筑、服装、工业、造型设计师都是设计师，但显然你不可能把他们归类成同一个职业。

产品经理也有划分，包含工业产品经理、汽车产品经理、硬件产品经理、快消品产品经理等等，我们讨论的对象主要集中在软件产品经理中。而面对种类繁多的软件类型，市场就做出了进一步的划分，最常见的就是 C 端和 B 端的划分。更细致的还有根据功能模块产生的，如支付产品经理、数据产品经理等。

我们这里主要讨论的就是 B 端产品经理的工作，其它产品经理的类型在以后再解释。

上面是产品经理的主要工作内容。

1. 需求分析

需求分析，就是考虑产品应该做哪些功能的过程。前面说过，功能的制定是考究质量的，不是随便抄抄或者拍脑袋凭空构思出来的，所以一个专业的产品经理在制定具体需求之前，是一定要做大量分析的。

在 B 端，最重要的分析必然是业务相关的分析。比如为公司设计一个财务管理系统，那么最重要的工作肯定是首先搞懂这家公司有关财务的流程和条例，比如财务部门的组织架构，财务出纳的审批方式，内部工资的发放和报销规则等等。

这些全都是具体的业务信息，我们要设计一个系统肯定是围绕着业务的要求和流程制定，尤其是找到业务中的痛点。比如转账打款流程中的多重审批并归档，需要数字化的解决方案保障内部的廉洁和预防贪腐的滋生。

业务的认识和痛点会构建整个项目的绝大多数功能和模块，但一个复杂系统的组成肯定不是从单一维度中提取需求，还包含其它维度的考量。

比如维持系统本身运作的基本模块，如日志、数据还原、资源管理、系统通知等，或者是基于用户体验的角度，添加如亮暗模式切换、便签备忘录、表格全屏模式等，再或用户的建议反馈、老板的喜好和"妄念"……

最后还有两个关键的要素，就是人力资源和项目周期，人力资源就是后续设计、开发、测试的相关人力，以及各自的专业水平，人数的多寡和专业水平的高低都会影响功能开发复杂度的上限。而项目的时间周期，决定了可以完成需求数量的上限。

受这两个因素的影响，产品经理往往要对前面构思的需求做调整（多数是减法），将一些次要需求删除或者优先级不高的留到下个版本再说。

所以，需求分析就是花费大量的时间，结合多个维度的信息来考虑产品应该做哪些功能。

在这个阶段中，因为分析的维度和内容既多且杂，所以收集的材料、分析的过程、自己的思考，都需要通过特定的工具做记录并整理。包括思维导图、UML、框架图、流程图、文档工具等，但因为是前期的构思阶段，所以并没有严格的行业规范，只要能满足自己的目标即可。

2. 需求输出

分析和规划好这次版本的需求，你已经很清楚这次版本要做哪些工作，但那仅仅是对你自己而言，前面收集和整理的碎片化资料只有你自己看的懂，不可能直接让别人来看这些东西。

所以，产品经理就要再做一个必要的工作，将你的想法通过更规范、清晰的方式输出出来。这里面主要包含两个要素，产品原型和 PRD 文档。

产品原型 Product Prototype，就是将你对这次版本需要做的页面、功能通过可视化的线框图绘制出来。国内主要使用的专业产品原型绘制工具有 Axure 和墨刀。

产品原型工具的特点，就是可以比较快速的创建可交互的高低保真原型，比如页面的跳转，表单的操作，广告轮播等，然后自己进行演示或者让其他人直接上手操作试用。

虽然可交互原型看起来很有用，但对于很多专业团队来说并不是特别在意该阶段的原型是不是能交互，因为产品原型的目的是传递产品的功能和页面大致框架，后面还有设计师来完成更具体的交互和界面，所以产品经理不需要额外浪费精力和时间去制作可交互的产品原型。

也正因如此，越来越多的产品经理开始改用 UI 设计软件来做原型，比如使用 Figma、Sketch、XD 或即时设计等。虽然交互功能较弱，但是绘制页面的效率远远高于原型设计软件，能更高效的实现原型输出的目标。

但光有原型图例也不够，因为每个页面都会包含若干设计图解释不了的逻辑和信息，比如一个用户名输入框最大支持多少字符，支持哪些字符格式，或者这个下拉菜单中包含多少选项，选项的来源是什么等等。

这就需要 PRD 产品文档来进行输出，PRD 就是一个用于记录产品需求详情的图文说明文档，包含各类图形和文字解释，帮助团队成员更详细的了解本次版本中的需求和相关功能细节。

PRD 文档有两种形式，一种是直接在 Axure 类工具中创建不同页面结合原型输出的文档的，另一种是使用类似飞书、语雀等线上文档工具制作，需要将不同图形从外部导入。还有一种日渐稀少的方式，就是用 Word 、PPT 等办公软件制作。至于它们之间有什么优缺点，这在以后的分享中会具体说明。

完成产品原型和产品文档，就是产品经理工作中最重要的部分，因为不管你有什么石破天惊、旷古烁今的想法，都需要把需求讲清楚了别人才能做出来。

3. 需求评审

完成了需求的输出，就可以交付文档给团队成员了嘛？在 "理想环境" 下文档写得够清楚，确实直接交付设计师和程序员就可以开工了。

但既然是理想环境，那肯定就是现实不了的，比如你会遇到下面几个问题：

产品文档不能保证写的足够清晰易懂，可能看不懂或者理解错误
产品需求本身可能存在不少逻辑问题和缺漏，你自己没有发现
有些需求本身的存在会受到质疑，团队成员不认同拒绝执行
团队成员不仔细看文档就开始动工，工作结果充满了 "自己的见解"

所以，产品经理还需要组织相关的产品评审会议，通过会议演讲来解释自己的产品方案。虽然评审听起来好像就是开一次会，但实际上远远不止那么简单。

一方面评审肯定是需要做相关的准备的，另一方面，一个有活力的团队，产品评审并不是 "指派任务" 现场，而是产品方案的 "批评检阅" 大会。团队成员大概率会用很挑剔的态度来审视你的方案，并提出大量的"友好建议" ，企图让产品经理主动认识到自己的错误和不足。

如果真的只是方案的缺漏错误还好，毕竟都是客观存在的问题。评审中最困难的是解决主观上的反对建议，比如这个功能我觉得不好，那个功能我觉得用户不能接受。当出现了不同团队成员提出不同的反对建议，就很容易演变成形而上的争论，全靠 "我觉得" 各执己见。专业的产品需要通过非常严谨的思路和想法采纳或说服不同成员的观点。

作为产品经理如果让这种反对意见存在且不加解决，团队成员对需求本身的认同度低，那么最后输出成果的质量就必然受到严重的影响。最好的理解方式就是想想你的老板、上级整天布置给你的那些难以置信的看起来很弱 Z 的工作指示，你会有动力把它们做好？

所以产品经理需要通过非常严谨的思辨和解释来解除对方的疑问，转变对方的认知，并认同自己的方案。统一全员共识，就是这个阶段最核心的工作。

不管是对方主观臆断还是确实存在问题，第一次评审大概率会存在很多地方需要改进，这就意味着评审结束后产品还要回去优化方案，然后再进行二次评审。

需求评审阶段，是对产品经理综合素养要求最高的一环，也是产品经理的 "受难记" 。既要有良好的基础水平和抗压能力，也要有出色的临场应变和逻辑思维能力。

4. 项目管理

产品的方案评审完，就等于把不同部门、成员的任务指派下去了，接下来的项目阶段，就是不同部门和岗位的执行阶段。

但是，不管任务的指派有多严谨，需求白纸黑字写得有多清楚，我们也不能确保项目的执行一帆风顺，且结果百分百符合预期。

中间依旧会出现一系列的阻力，比如：