硬件产品经理一般负责产品的整个流程管理，本篇文章介绍硬件产品经理的四个工作流程：产品规划、立项研发、GTM、复制推广，并对四个流程内容进行详细地介绍分析，希望能对你有所启发。

硬件产品经理是产品的最终负责人，负责产品的全流程管理。说得直白一些，就是任何和硬件产品盈利有关的，都是硬件产品经理负责。

公司创建之初，一般由创始人直接负责产品，从产品概念开始，到产品demo，再到工程样机，最终到产品量产，逐步完成商业闭环。

这个过程中，一方面积累了产品、技术竞争优势，另一方面也有了一定的客户。随着产品的技术成熟度提高，产品价值上升，同时市场教育不断铺开，用户替换成本下降，当新解决方案的性价比 > 原解决方案的性价比时，产品进入成长期。

即“新产品价值/新替换成本 > 老产品价值/老替换成本”。

成长期的特点是客户个性化需求日益增长，中高端客户希望使用更好看、更好用、更不同的产品，低端客户则希望使用更便宜的产品，结果就是单一产品无法满足公司发展，多产品布局，或者产品更新换代成为公司必选项。

此时创始人已无法兼顾公司的产品职能，需要分权，由产品经理承接具体某一块的产品业务。后期产品业务做大做强之后，产品经理升职为产品总监，开始招聘产品经理负责产品业务中的某几款产品。

硬件产品全流程管理包含四大阶段：产品规划、立项研发、GTM、复制推广。以下我与大家简要介绍一下各阶段所涉及的主要工作（详细职责会在后面的章节重点阐述）。

一、产品规划

产品规划是从产品需求开始，在图纸上完成产品的概念定义及商业化论证的过程。当我们发现一个未被满足或者满足有限的需求时，我们会在脑海里头快速匹配相应的产品来满足客户的需求。

此时，我们定义了基本的产品概念。有了这个基本的产品概念，我们开始做几大论证：

• 产品市场论证：“打哪个细分场景？”、“市场大不大？”、“用户价值强不强？”
• 产品竞争论证：“在这个细分场景里头，我们的产品定位是什么？、“我们的对标竞争对手是谁？”、“我们的竞争策略是什么？”、“产品关键参数有哪些？”
• 企业竞争论证：“为什么我们能赢，竞争优势在哪里？”、“上下游链条上，我们有哪些竞争优劣势？”、“这些竞争优劣势，我们有办法借力或者弥补吗？”
• 产品技术论证：“我们采用哪个芯片平台方案？”、“产品关键参数能否满足？”、“有哪些技术、工艺需要先行预研？”
• 产品商业论证：“通过什么业务模式切入？”、“产品投入产出数字是什么，背后数字逻辑是什么？”、“产品GTM节奏是什么，目标客户是谁？”

经过这发人深省的论证之后，最终我们输出产品的商业计划书，并经过产品总监批准，进入立项研发阶段。

二、立项研发

完成产品规划之后，我们清楚知道要做什么、为什么做、怎么做，接下来就是产品需求的明细化，并形成PRD（Product Requirement Document）。如果涉及到产品技术的预研，则会先行启动预研。

正式研发过程如下：

① 产品ID（Industrial Design）：ID草图设计、ID工程设计、CMF设计、ID手板制作

② DVT（Design Verification Test）：

• 结构：概要设计、详细设计、硬件板框图、结构手板试装、可靠性摸底、开模发起
• 硬件：原理图设计、PCB设计、PCB快板打样、PCB贴片、硬件测试、单板Bom制作
• 嵌入式：技术方案设计、BSP（Board Support Package）开发、嵌入式开发、功能自测
• 软件：云端、App、面板开发

③ EVT（Engineering Verification Test）：

• 结构：开模完成T0、修模T1、工程样机试装
• 包装：包材图纸设计、包材打样
• 样机试制：长周期电子料备料、基板备料、PCB贴片、整机组装
• 测试：软件测试、硬件测试、可靠性测试、认证摸底
• 认证：认证样机发起

④ PVT（Production Verification Test）：

• 嵌入式：固件发布
• 软件：云端、App、面板发布
• 生产小批量：试产备料、小批量试产

⑤ MP（Mass Production）：

• 量产：完成种子客户首批订单
• 认证：完成认证

因环节众多，只将核心环节整理出来。

三、GTM

产品在立项研发阶段时，产品经理需同时考虑GTM，整理文档及规划营销活动。理想情况是，在产品量产前完成GTM，GTM活动之后就有订单进来了。

• GTM资料输出：产品规格书、产品说明书、推广文档、宣传单页
• 产品宣传活动：产品发布会（公司网页、内部邮件、社交媒体、代理商渠道）
• 产品沟通培训：组装内部销售、技术支持、代理商的产品培训沟通会
• 客户拜访：拜访重要客户，定向推广产品
• 产品营销活动：产品成功案例分享（内部邮件）
• 客户支持：与销售一起，与客户做沟通等售前、售后服务

GTM目的是拉近产品与内部客户（销售）、外部客户的距离，让产品与终端客户距离最近。尤其是B端产品，越靠近客户，越节省销售费用，GTM作用也更明显。

四、复制推广

通过调整产品策略，推广到更多领域。常见方式如下：

• 场景迁移：通过软件功能变化，如C端产品和B端产品迁移、家用场景和户外场景迁移
• 市场迁移：通过安装方式或电气接口变化，如A地区产品迁移到B地区产品
• 渠道迁移：通过转变某一特性，如运营商定制接入产品，切入运营商渠道
• 业务模式迁移：通过转变业务模式，如品牌模式迁移成OEM/ODM模式、成品模式迁移成套片/SDK模式
• 售卖模式迁移：组成解决方案售卖，如搭配其他产品组成解决方案售卖

因复制推广最终决定于具体的产品及应用场景，以上只提供部分思路。

五、最后

无论是硬件产品经理，还是硬件产品总监一定要有Top-down的思维方式，得从公司级产品战略去思考产品的布局，产品之间不能相互打架，任何新产品的布局是为了抢占新市场，而不是内卷。

同时又得有Down-top的分析能力，抽象技术层、产品层、解决方案层，将产研、产销效率复用最大化。就像蛇贪食一样，无论蛇吃地多么的冗长，依旧可以共进共退，指哪打哪。

逻辑思维对工作认知有一定的影响，对于任何岗位而言，都需要建立一定的工作思维。那么，产品经理的职业观具体该如何定义？本篇文章将会为你解析，对于初级或者中级的产品伙伴都能有一定的帮助。

这个系列我会用四篇文章，系统的讲述初级/中级产品经理在工作中会遇到的在思维方面的误区，以及他们的职业发展方向。

一、边界

看这篇文章之前，请先自己思考下，谁能说下2B和2C的产品经理区别？

做过2B的产品经理肯定会有这样的体验，产品有bug有时可能不重要，有时候甚至为了出货要“糊弄”客户，而这些事情在2C的产品经理看来是绝对不允许发生的。

我们列出在2B和2C模式下我们与用户的接触路径，大家对2B和2C的产品经理就有了更深刻的认识。

• 2B：你→客户→用户
• 2C：你（→代理/分销）→用户

2B模式下的产品经理更多类似产品助理和项目经理的职责，产品经理发掘需求的过程被客户承担了。如果你有能力也有机会，当然可以针对客户需要的产品和客户进行讨论。但我们不得不承认在实际工作中，更多是按时完成客户已经制定好的产品。

而在2C的模式中，产品经理这个岗位是直面用户的，是真正和用户打交道的，这样的岗位和角色，是我们今天要讨论的。

所以以下所有内容，有两个边界：

• 针对消费电子行业。
• 针对2C即就是面向用户的产品模式。

我本身一直在消费电子行业，做过2B行业的产品经理，之前负责创维数字菲律宾市场，当时我们的客户是当地最大的运营商SKYCABLE和Cignal，相当于中国的移动和中国联通。

18年底的时候我转到国内消费电子行业，做2C的产品经理，做过网络机顶盒，智能音箱，投影仪等，完整的亲历了创维安防从0到1的整个过程，目前国内市场基本趋于稳定，从去年开始我个人又转身去开拓海外安防市场，当前的具体工作也不仅限于做产品经理了，市场，销售，组织，管理等都有涉及。

我深知要做好一名产品经理有多不容易，我也踩过很多坑。所以今天主要是想跟大家一起分享个人在这个过程中的一些感悟，希望在产品经理的这条路上我们能少走弯路，早日成长。

我时常对自己说，人之忌，在好为人师，所以这个系列的文章，只是我个人经验的分享，不是什么科学方法论，也不是什么金科玉律，大家有不同的想法，也欢迎探讨。

接下来，我们正式开始。

二、缘起

大家先在这里先停下来，回想下自己当初为什么选择做 “产品经理”？

“你愿意卖一辈子糖水，还是过来跟我一起改变世界。”这是当年乔布斯邀请百事可乐总裁约翰到苹果担任CEO时说的话，我相信很多人愿意来做产品经理，都是或多或少抱着这样的想法。

但真正的开始做了这个岗位后，可能很多时候没有那么多刺激和新奇。有的是日复一日的盘旋在工作日常的琐碎中，和软件工程师为了需求的改动争得面红耳赤，和硬件工程师为了一个灯效弄得不可开交，和ID设计师在一版版的的改动中关系变的岌岌可危，大战一触即发。

可能在工作前一二年甚至二三年期间，就干一些产品助理的工作，跟进项目中产品功能的实现，体验产品功能，甚至陷在测试里面，和设计师一起设计产品包材，日常处理售后问题等等。

但请记住，这个阶段，其实往往是拉开差距的阶段？

大家一定要注意！如果在这样的环境下，不保持好奇，进取的心态，很容易就慢慢的变成一个产品执行人员，老大有什么任务分配下来，你就按照要求百分比的完成，不要出岔子，你得到了老大的表扬，在每天这种产品执行中乐此不疲，渐渐丧失了对产品的兴趣和对新事物的好奇。

但是，这个阶段其实是我们积累的绝佳时期。我举个例子，当你做包材的时候，你不仅仅是做你当下这一款包材，你要去理解包材设计师他们在设计包材时候考虑的点都有哪些？

仔细回想下，你在做在产品彩盒设计的时候，是怎样思考的？

定位，材质，成本，内衬用珍珠棉，纸卡还是气柱袋，交期是多久，是否可以满足生产计划，线上要不要再涉及一个邮寄盒，出海考虑尺寸满足货柜，配色应该是怎样，知不知道暖色系中最温暖的的颜色是什么等等，这些都是在做彩盒这个小小的产品时候需要考虑的问题。

我们产品经理有个好处就是会合很多与产品有关的岗位打交道，在这个过程中，你一定要多思考，领导给你的任务是1，你要利用这个任务完成的时候，给自己的积累是10，甚至更多。

我们老说厚积薄发，这个阶段，其实就是产品经理最佳积累的阶段，也是逐渐拉开差距的阶段。

如果你现在处于这样的阶段，我希望你，每周一都问自己一句：上周我在产品认值上的收获是什么，这周我要补齐哪一块的知识储备。

大家都知道戴森吹风机吧，其实从戴森决定创业到研制出第一款吹风机，他花了整整15年时间。张爱玲有一句话叫：出名要趁早。我们好像也看到很多牛逼的人一上来就弄出个惊世骇俗的产品。

但很多做产品的人，都是要经历很长时间的寂寥，台上一分钟，台下十年功。作产品的人一定要有定力，耐得住寂寞。如果能熬过这个阶段。

那么第三个阶段，将会是你发光发热的阶段。

绝大多数人要经历这样的三个阶段，尤其是第二阶段，里面与很多技法，但首先，我们来看看需要树立哪些正确的想法。

三、职业观

对照以下的问题自检一下，看看是否有遇到过其中至少一个：

• 我的领导在工作中管的太多，包材设计时候一个字母的样式都要我换好几次？
• 我的领导不管我，不给我教东西，很多东西我都不知道要怎么做，只能自己摸索？
• 大家欺负我是新人，推动研发做事情好难？

如果有遇到，请回想下当时你是怎样解决的。

我相信很多新人一定会遇到这样的问题。以下这几句换了，我觉得是我们作为一个产品经理刚入职场时候需要明白的。

1. 权力不是被赐予的，权力是能力的衍生品

很多新人刚入职场，你觉得自己做什么事都要受到领导的管制，然后甚至可能做个很简单的事情，也要想领导去汇报，好像自己放不开手脚似的。

真正的原因你要明白，你的权利和你的能力是对等的。领导授权的过程，他大概是一个：授权——反馈——授权的过程。

• 领导授权，得到你的正反馈，那么加大授权，正反馈，再加大，最终独立负责业务。
• 领导授权，得到你的负反馈，那么就会收缩你的权利。

所以你要明白，你的权利是你能力的衍生品，你有多大的能力，你才能有多大的权利。

我们换个角度来想想，如果你刚一进职场，领导就给你权利，让你直接定义公司下一代的产品，那对公司来说是不是很冒险？对你来说，我想你自己也会怀疑自己有没有这样的能力接住这样的权利。

所以不要再抱怨，你手上的权力很小，做不了很多事情，你仔细去反思一下自己的能力能不能够承担更多的权利？如果你有这样的能力，那就展示给你的领导看，在你的工作上表现出来。

说完了权利，我们再来谈谈尊重这个词。

2. 当你的能力越多时，别人就会越尊重你

尤其是产品经理和技术人员打交道的时候，当他陷在他的专业思维无法突破的时候，你不是说我不管，你一定要弄出来，而是换个角度来帮助他，打开思路。

我去年做了一款球形的那个摄像头。在主板上有一个指示灯，但是指示灯外面是有层结构的，所以你在距离稍微远一点的地方，这个指示灯就看起来比较暗。

当时去和硬件同事提出要把这个灯加亮的时候，他告诉我这个功率已经是最大了，当我去问结构工程师的时候，他说这个结构件已经是最透了，再透就看到里面其他的结构了。

这个时候我如果说，我就要更亮，那他们会怎样？他们一定会和我去讨论争论说做不了。

我后来想了一下，在我们平时生活中用的那个光纤线，它这个导光性就特别好。我就让我们结构的同事去在网上买了一点那个光纤。后来光纤一头顶住那个灯，一头接触到盖子。

结果真的在外面看就亮了很多。那这个虽然是一件小事，但那次之后我再和结构工程师去讨论的时候，明显的感觉到他也在逐渐跳出他的舒适圈，尝试和我一起给难题找解决方案。

公司为了让新人更快的学到一些东西，给大家配备了导师，但大家知道，既然能做导师，其实他本身的能力就很强，但能力越大，责任越大，事情越多，你感觉好像他也比较少时间教你似的。

很多新人这个时候就会犯嘀咕，就心里想说我这个导师好像不太称职，或者公司的一些前辈你去问他问题的时候，他感觉好像不太怎么愿意回答你。

你一定要记住这一点。

3. 没有人有义务要教你，包括你的领导

我们其实都是在在为公司的目标业绩去前进的，你的领导他其实只是在职级管理上在你之上，但这并不意味着他有义务要教你很多知识和能力，他愿意教你有两个情况：

• 他需要你帮他完成他的目标，所以他需要教你必要的知识。
• 他真的想帮你。教你是情分，不教你是应该。

如果有机会，你多多向他请教，我相信很多人是去愿意。分享的，但是如果他不愿意分享，你要想办法自己去成长。比如说你现在在看这篇文章，这就是一种学习途径。

最后一点了也比较通俗的，但对于新人来说很重要的，就是不懂就问，不懂就去学。

你刚开始几年不能去问不懂，去学的时候，没人会嘲笑你，他只会觉得你是一个很好学的，但是如果这个阶段你没有抓住机会，可能过来4，5年，5，6年的时候需要你独挡一面的时候，你很多东西还是不会，那这个时候其实才是最痛苦的时候。

在刚入职的时候不要担心你的无知，因为大家都是这样过来的。不懂装懂才是最可悲的。既耽误了别人，也骗了自己。

聊完了职业观，下一篇文章我们再来聊聊产品观。

作为一名产品经理，工作需要对接沟通的岗位有很多，那么，面对这些不同的岗位关系时，该如何发挥自己的能力呢？本篇文章从三个层面对此分析，希望能对你有所帮助。

硬件产品经理虽然抬头是个经理，实际却没有管理权限。产品经理作为产品的负责人，几乎所有的事务都是通过他人来完成的，所以“如何让团队成员积极参与，并有效完成任务“，是产品经理终身要学习的课题。

非管理职能调动资源，是硬件产品经理的核心矛盾。

目前，企业主流的组织方式是矩阵模式，内圈是产品、研发人员，包含横向资源线，纵向产品线，负责产品研发。外圈是业务、市场人员，负责产品销售和推广。

这里头有三种资源关系：

• 第一种是强矩阵资源关系，和产品线强关联，是固定资源，如硬件、结构、嵌入式、软件、测试等，资源的协调权归属于产品总监。
• 第二种是弱矩阵资源关系，和产品线弱关联，是企业的公共资源，如工业设计、包装、工艺、可靠性、质量、采购、认证等。
• 第三种是合作伙伴，如销售、市场人员。

因产品经理没有“管理”权限，需要更多地发挥自身的“领导”力。那什么是“管理”、什么是“领导”，两者的区别是什么？

《可复制的领导力》这本书有关管理和领导的解释很通透，我结合我的理解，和大家分享下：“领导”和“管理”两者之间最大的区别就是核心驱动力不同。

“管理”的核心驱动力是：“怕”。员工怕老板，担心事情做不好，担心完不成KPI，是绩效驱动型。“领导”的核心驱动力是：尊重和自我实现。双方充分尊重，相互成就，是成长驱动型。

所以，产品经理处理这三种资源关系时，一定要更多地发挥自身的“领导”力。以下，我和大家谈谈我的理解。

一、与老板

产品总监作为产品线固定资源的分配者，实际是产品线内部的投资人，想要更多的资源，你必须说服老板。告诉他这个产品的独特性，你一定不能错过。

1. 充分了解老板的目标

老板的目标，决定了产品的走向。如果老板的目标是稳定有升，追求业务稳健为主，那资源投入大、项目风险高的产品就不容易获得他的认可。

如果老板目标是要布局一个未来的潜在机会，那激进型的产品被关注的可能性就很大。所以，产品经理的商业机会书，一定要充分了解老板的目标，并与之匹配，借势而为。

2. 引导老板相信机不可失

老板最怕什么？老板最怕产品的切入时机不对。如果产品做晚了，就容易错过机会窗口。如果产品做早了，资源又耗不起，容易倒在黎明前的黑暗。

所以尽可能地找多方背书，让老板相信这个产品的最好时机就是现在（当然首先产品经理你自己得相信，To be real 很重要）：

• 竞争对手维度。举个例子，苹果发布手表之后，大批厂商开始布局手表了，为什么？因为苹果完成了产品市场、产品技术的论证，手表被证明商业可行、技术可行了。
• 下游客户维度。如果很多客户都非常看好某个新产品，经常过来咨询，甚至愿意出NRE（Non-Recurring Engineering一次性工程费用），那商业可行的概率就很高。因为下游客户在前线直接接触客户、用户，对市场敏感度高，他们的意见往往就是终端的意见。
• 上游供应链维度。多个芯片原厂的路线图，都指明了同一个的技术方向，那这个技术方向就极可能是未来的方向。基于这个技术方向的产品，都值得做一遍，占领技术高地。

3. 经常请示和汇报，持续加强老板的关注度

及时与老板汇报产品的进度、亮点、问题、阶段性成果。一来可以通过老板快速协调资源解决棘手问题，二来阶段性成果能给到老板正面反馈，加大他的持续关注、深度参与。

试问一下，当老板觉得自己是产品团队的一员时，他还允许这个产品失败吗？当然不会，他会调用所有可利用的资源让产品成功。

二、与关联资源

关联资源作为产品经理核心调用的资源，配合的好坏，直接决定了产品的成败。但因为产品经理和研发目标不同，一般来说产品经理是希望尽量多做功能，这样产品在市场上更有竞争力。但功能做多了，也意味着风险大了，出问题的可能性高了。

而研发同学考核一般为问题指标，如PCB发板几轮成功率，软件提测几轮通过率，严重BUG数量等（预研产品指标不一样，更允许犯错）。

所以，产品经理一来要充分理解对方，不要觉得研发同学在搞事。二来要充分发挥自身的领导力去激励对方。

1. 点燃对产品的热情

产品经理在做需求评审时，一定要尽可能多地把产品来龙去脉和研发同学说明清楚，让他们明白，“为什么这个产品对于企业或产品线这么重要？”，而不是只讲产品需求。

部分产品经理认为，需求评审时候只讲需求，能让对方更聚焦到具体的任务。其实不然，因为每个同学手头不止1个负责的产品，那个先做的产品能得到更多的精力、时间关注，成功概率也会更高，所以先做哪个有时候比怎么做更重要。

大家试想一下，如果乔布斯开iphone的需求评审会。他说：我们将重新定义手机，并改变人与人的沟通方式。你觉得研发同学会不尽心尽力吗？当然不会，点燃产品的热情远比利益驱动有力量。

2. 懂一点技术，真诚沟通更顺畅

需求评审是一个博弈的过程，如果你没有任何技术背景，那研发就不太愿意和你袒露心扉，毕竟秀才遇到兵，有理说不清。且部分产品经理不太习惯承认自己的不足，从而使沟通陷入僵局。

结果就是产品经理觉得研发人有问题，总是拒绝做难的需求。

研发觉得产品经理人品不行，跟着他干没前途。所以，产品经理要学习一点技术，然后遇到真不懂的，尊重地请教反而会有好的结果。

3. 营造积极解决问题的氛围，并当众欣赏和赞美

积极向上的氛围，能让团队成员更愿意发挥自身的能动性。所以，要在成员中找到标杆，并在群里或当众表扬他的特性。

比如赞美小王：在排查问题时候，充分发挥了自身能动性，牵头与上游供应商、质量部多次会议找到几个可能的方向点，然后逐个做排查，成功赶在量产前解决了这个严重问题。

当设立榜样后，团队的其他人将会向榜样看齐。

另外，对于优秀的项目成员，产品经理应该想方设法在其直属领导面前做赞美，让优秀的人有更多的露脸机会。

4. 庆祝阶段性成果

对于产品获得阶段型成果，比如完成首批订单交付、产品样机落地，需要邀请所有团队成员一起参与庆祝，感谢大家的付出，并认可他们的成果。我们是团队，共进共退。聚是一团火，散是满天星。

5. 强关联资源与弱关联资源

强关联资源，属于产品线固定资源，平时合作紧密，沟通协调问题不大。但弱关联资源，因涉及项目众多，无法深度参与项目，推动起来会相对困难。

所以，一定要站在公司的角度去推动其对于整个公司的共性价值。同时，当产品有阶段性进展时，要鼓励对方把成果拿到公司老板去展示，让对方有足够露脸的机会。

比如，推动采购谈一个芯片的好价格，在解释芯片价值的时候，就要重点强调这个芯片对于公司所有产品的价值。我们不是做一个产品，而是做一个全公司级的底座。

三、与合作伙伴

销售和市场人员是产品经理的合作伙伴，更是业务人员。他们业绩压力大，必须死死盯着短期目标，因为对于他们来说如果目标完不成，在公司就失去了存在价值。

所以，从产品的推广和销售上看，他们往往倾向于自己最熟悉、产品卖的最多、产品最稳定的老产品，因为他们已经过市场充分论证，他们需要做的只是找到更多的客户，快速复制切入。

而新产品技术、产品成熟度不可控，市场逻辑不通透，业务人员很容易成为小白鼠，精力花费多，产出有限。所以，业务人员面对新产品往往是观望，然后等着客户来拉动他。所以，如何带动业务人员的积极性，是一个值得持续思考的话题？

1. 全力支持业务人员

充分准备产品子弹，如规格书、推广文档、宣传单页、说明书、样机，并安排培训会，准确地与业务人员澄清产品的机会市场、客户画像、竞争优势等。

对于业务人员过来的支撑需求，比如出差去拜访客户，一起联动切入，或者问题、报价咨询，要第一时间响应，让业务人员没有后顾之忧。

2. 宣传标杆案例，发挥鲶鱼效益

对于某个客户切入成功，并完成出货。可以在公司内部邮件或渠道，宣传产品标杆案例。

一来佐证产品已经市场论证成功，你们不要再有后顾之忧了。二来也通过这种方式发挥业务人员老板的敲打作用。当业务老板看到这个案例时候，他会怎么说？

“这个产品他们的这个客户可以，我们区的某某客户和他同行业、规模还比他大多了，我们是不是可以照葫芦画瓢，快速拿结果”，这就是鲶鱼效益了。

四、总结

非管理职能调动资源，核心是尊重和自我实现利他心的展示。好的产品，一定是多赢的结果，客户赢、产品经理赢、老板赢、关联资源赢、合作伙伴赢。

在做需求收集之前，要确认需求的来源，一般包括产品规划类、业务类、用户反馈类、市场及竞品需求四个内容。接下来，我们看看作者的分享。

在这里总结了几种进行需求分析的方法，有5W1H分析法、用户故事地图、马斯洛需求层次、KANO模型、四象限法则、RICE原则等，由于B端产品涉及到的角色管理流程复杂，需求大多来源于业务方，针对于B端需求分析最常用的方法为5W1H法和RICE原则。

在进行需求分析之前，首先需要收集需求，调研需求的方法有用户访谈、问卷调查、焦点小组、业务轮岗实习、数据分析、行业研究、竞品分析等。

在进行需求收集之前，先确定需求的来源有哪些，一般需求的来源分为产品规划类需求、业务类需求、用户反馈类需求、市场及竞品需求。

一、产品规划类需求

根据公司的战略方向、产品定位来制定产品规划类需求，从市场大框架来梳理产品架构，知道这个产品的目标是什么，产品边界在哪里。

在整个规划过程中，会不断完善和调整产品架构图，可按三个层级梳理，以客服即时聊天系统为例：

• 第一层，按照角色来判断梳理，客服即时聊天系统可以分为客户端、客服端以及运营端，主要解决客户能及时找到客服人员解决问题。
• 第二层，梳理各角色涉及到的模块，客服即时聊天系统包括了与客户对话的H5聊天页面，客户信息管理、对话管理、基本设置等。
• 第三层，针对各模块梳理大致点，如对话管理可以分为在线对话、等待接入、传送对话、响应传送、结束对话、等待评估、客户评估、历史对话、常用语管理等，逐层级拆分需求把产品架构图整理绘制出来。

二、业务类需求

接触到一个新业务时，在梳理业务流程中，收集业务类需求，先要理清最基本的业务组织架构图，通过组织架构图理解管理体系和职能单元的设计，以及后续规划，然后通过用户调研，梳理出目前的业务运作流程。

在业务流程里的第一个基本元素就是角色，有了角色才会有分工、有协助，才能完成特的价值目标，其次是活动，即每个角色都会有具体需要做的事情，当每个角色有了具体的活动，就会有产出，最后达成一定的目标。

对于业务类需求，最好的方法是轮岗参与业务环节和用户调研。对于用户调研，运用需求调研五步法：

• 先明确调研目标，了解业务模式和业务特点，了解业务目标和业务规划，了解当前业务运转方式，然后挖掘当前问题与痛点
• 选取调研对象，根据业务组织架构，选择每一个节点的干系人
• 设计调研大纲，根据调研目标和调研对象，针对每个干系人设计不同的问题
• 执行调研计划，提前将调研大纲发给被访者，以便被访者先大概了解访谈内容，提前做准备，在访谈过程中还应该循序渐进，在调研结束后，与被访者保持联系
• 总结归纳输出，对访谈内容进行整理，输出用户访谈记录表

在此过程中，进行全场景分析，即谁在什么情况下，在什么时候，带着什么目标，通过什么途径，采取了什么样的动作，完成什么样的目标，具体拆分：

1. 场景要素
2. 梳理出尽可能详尽的业务流程
3. 基于业务流程找到对应的全场景
4. 基于全场景找到对应的用户需求
5. 确定边界，也就是确定哪部分场景需要系统支持，哪部分场景需求不需要系统支持，哪部分是手工+系统支持

综上，业务类需求基本就能提取出来了。

三、用户反馈类需求

根据用户反馈的需求优先级整理成用户需求池，我们的用户提需求的时候，经常会按照他们平时的工作习惯，直接给出解决方案，让你按照他们提的方案进行修改，那这个需求到底该不该做呢？

我们不能只做需求的传递者，俗话说的传话筒，要做一个需求解决者，利用13要素5步法深挖需求。

1）是谁？

提出人是谁，使用人是谁？受影响人是谁？

2）想要做什么？

基本场景是什么：是谁想要解决谁的，什么问题？这个问题中有需要进一步细化和明确的概念吗？发生频率是多大？

3）了解需求背景，为什么？

多问为什么，核心问题（痛点）是什么？强烈程度如何？实际的价值是怎样的？

4）是否更多的可能性？

横向替代场景是什么？纵向互补场景是什么？把该有的功能点都列出来，看是否有更多的细分场景？

5）如何解决？

要解决这些问题有哪些可行的解决方案？这些方案实现的成本有多大？你觉得哪种方案最适合？该解决方案对用户而言有什么优缺点？有没有其他需要挖掘的需求点？

把这些问题进行场景化描述出来，问题一一确认完毕，那么这个需求就能确认并纳入到需求池中了。

四、市场及竞品需求

首先深度体验竞品功能，梳理出功能清单列表，体验竞品模块的功能流程和用户路径，再看该模块和其他模块产生的交互点，了解完竞品模块后，再根据自己产品的实际使用场景来梳理可以借鉴的点，对于竞品分析，重点还是要做产品的重度使用者，挖掘出更多的用户痛点。

将需求收集完毕后，接下来会进行需求管理，会将需求分为功能性需求和非功能性需求，而功能性需求包括了业务需求和用户需求。然后对于需求优先级排序，一般会运用RICE原则和价值成本模型，制定需求版本迭代计划。

RICE原则：

• Reach（触达）：多少用户提出来的
• Impact（影响力）：对用户的价值有多少
• Confidence（信心度）：产品经理的信心
• Effort（努力）：标准化的难度和研发成本

对于B端产品，需求排期都是在综合分析后进行的决策，并不是单一的分析，看的还是产品经理本身的经验和能力。

作者从一次产品体验经历，总结做SaaS产品经理需要具备的能力以及需要克服的困难，面向客户，需要关注客户诉求；而对自己，需要及时反思。接下来，我们看看作者的分享。

01 一次不愉快的产品体验

上周发生了一件小事，我使用的某个知识付费APP出现了bug。

把问题发在服务群，他们答复说“本来就是这么设计的，2020年就已经开始执行了”。

但是有意思的是，这个所谓的“有意设计”，APP端和H5端的逻辑却明显不一致，我很难理解一个有意的设计，为什么3年了还有如此明显的漏洞，以至于给我们造成了难以估算的损失。

对方是一个小团队，CEO也在服务群，我直接@他们CEO，结果没有任何回应。

这让我想起另一款知识付费软件XX通的CEO老鲍，曾经我使用XX通也遇到问题，我隐掉产品信息后发文抱怨了2句，老鲍就主动找我道歉，还特意拉群来解决问题。

XX通的规模已经不小了，但是CEO对问题的积极回应，和这位小团队CEO倒是形成了鲜明对比。

其实，哪家产品没有bug？哪家SaaS不会遇到客户投诉呢？但是不同的处理方式，却显示了CEO的水平差距。

你可能会说：王老师毕竟是SaaS行业的自媒体，XX通自然会重视一些。

我不知道是否有这个因素，但是我知道XX通还会特意举办“产品吐槽大会”，公开让用户来吐槽。

就像老鲍说的：我不一定能解决用户的所有问题，但是我一定会听他们抱怨。

有这样“主动找骂”的态度，我相信XX通不会对用户的投诉视而不见。

当然，从直觉上来说，主动找骂是一件“不正常”的事情。

但是，这正反映出一个真相：

真正优秀的SaaS产品经理，都是反人性的。

02 我被客户骂了20分钟

某位大佬说过：每天有一亿多人教我做微信。

很多SAAS产品经理因此认为：做产品应该有自己的主见，不能轻信客户。

这句话当然没错，但是很多产品经理走入了另一个极端：他干脆就不听客户的抱怨了。

实际上，不管客户的观点有什么错误，其背后的“诉求”是客观存在的。

本质上，SAAS产品就是要满足众多客户的共性需求。因此，优秀的产品经理一定会尽量多的收集客户诉求，从而提炼出共性需求。

另一方面，C端产品和B端产品的逻辑差异很大。

C端产品往往强调“点”的需求，场景相对简单，而且产品经理还能自己作为用户，感同身受。

B端产品往往强调“面”的需求，场景相对复杂，产品经理也很难到各行各业去任职，作为用户感受自己的产品。

因此，B端产品就更加重视客户的声音。

不过，客户提需求的时候，往往都伴随着抱怨——如果产品是完美的，客户又哪来那么多需求呢？

因此，主动去听取客户意见，往往要克服“喜欢听好话”的人性。

曾经，我在Oracle的时候，服务的都是百亿、千亿级的上市公司，客户都很尊敬的叫我“王老师”。

后来我转型做SAAS产品，因为一个功能设计不够灵活，在电话里面被一个小企业主骂了20分钟，说我们的产品是“烂泥扶不上墙”。

接完电话，我还是挺委屈的，毕竟第一次被客户骂得狗血淋头。

不过，我马上在当月的迭代版本中完善了这个功能，结果新功能一经推出，在没有任何推广的前提下，就有超过40%的客户主动使用。

由此可见，客户的话虽然难听，但还是有价值的。

03 不自信，是产品经理的美德

自信是人类的美德。

比如，在大自然的生存竞赛中，自信的人会更加果敢，相比于那些谨慎的竞争对手，他们往往能抢得先机，从而赢得生存的机会。

但是，作为一个SAAS产品经理，却需要时刻提醒自己“不要那么自信”。

红衣教主周鸿祎的成名作是3721，他对3721的定位一直都是中文网址服务。

然而，很多用户都说3721做的是搜索，甚至一位来自雅虎的副总裁，也很不客气的对周鸿祎说：你们的方向有问题，你们应该转向搜索领域，因为搜索才是未来的趋势。

可惜的是，周鸿祎过于自信了。

他不仅没有理会用户的意见，甚至反其道而行之，命令程序员拿掉网站上的搜索框。

结果等到百度崛起，周鸿祎才发现自己错过了一次人生最重要的机遇。

因此，产品经理一定不能过于自信，以为自己是多年的行业专家，就听不进别人的意见。

在有的SAAS公司，产品经理和销售、客户成功部门都有很大的矛盾。

原因一方面是SAAS公司为了避免产品被个性化需求带偏，赋予了产品经理拒绝需求的权力。

另一方面则是少部分产品经理过于相信自己的判断，而不愿意虚心向同事、向客户学习。

实际上，越是优秀的SAAS产品经理，越喜欢和销售同事跑一线，收集尽量多的市场信息。

曾经智齿科技的产品VP老陈来SAAS星球分享，他说自己就经常兼职做售前，跑一线去和客户沟通。

作为产品VP，他本来可以把这些事情丢给售前经理或者产品经理，但是他坚持多接触客户，就是为了避免因信息闭塞而做出错误决策，甚至错过重要的市场机会。

我在担任SAAS产品经理的时候，也经常和销售同事一起跑客户。

有一次，我陪着销售同事去拜访某个行业的头部企业，原本以为只是一个十几万的定制化需求，结果我发现是一个新产品线的机会，而且可以借着这个机会，顺利切入大企业市场。

不久，我们就和这家外资企业签下百万级的订单，一直到今天，他们仍然在续费使用。

后来，公司又把这个产品销售给了其他大企业。

结果，到今天，我的老东家已经从一家“面向小企业的SAAS公司”，顺利转型成了“面向大企业的SAAS公司”。

虽然我后来离开了公司，但是至今和销售部门的同事保持了良好关系，原因就在于我没有自以为是，而是主动和销售同事一起跑客户，一起向客户学习，一起发掘市场机会。

04 “活102年”为什么那么难？

马云说：阿里巴巴要做一家102年的企业。

对于一家企业来说，为什么“活102年”那么难，以至于值得成为一家伟大公司的愿景？

原因在于，市场在不断变化，新的竞争手段层出不穷。一家企业能活到102年，说明他能够及时响应市场的变化，不断自我变革，具备顽强的生命力。

但是，自我变革，首先就得承认自己的无知，学会虚心接受他人的意见，甚至接受用户毫不客气的批评。

这些事情都很痛苦，但却是为了做好SAAS产品，必须克服的人性弱点。

本篇文章将探讨产品经理验收时存在的几个问题：是否需要验收、为何不验收、验收与测试的不同及误区等，帮助大家了解验收的内容，希望本篇文章能对你有所帮助。

最近，在一个产品沟通群里，产品经理们又炸开了锅，起因是其中一名产品经理提到自己公司的产品上线之后，功能与业务不符，测试将这个“锅”甩到产品身上，认为产品没有做好验收，而产品认为这本身就是测试的工作。

于是，产品经理们开始在群里疯狂吐槽各自公司的测试人员，我看到了“一致对外”，但却没看到任何人在反省产品经理到底应该如何验收才能避免这样的事情再次发生。

一、产品经理到底需不需要验收

这个问题的答案是肯定的，产品经理一定要做验收，至于其必要性，我们看一看产品经理不做验收会产生什么后果就知道了。

1. 产品与设计不符

按产品与设计的偏离情况，可分为3种：

1）不符

这种情况指的是产品与设计有偏离，但无伤大雅，甚至可以不按原设计调整。

比如一个原本应该用红色级别的 Toast 提示被开发成黄色级别，由于红色和黄色在系统中均有表示警告的含义，所以这个偏离也不是不可以接受的。

2）一般不符

这种情况指的是产品与设计有较大偏离，可能已经影响到产品的使用。

比如一个原本通过弹窗提示的内容被开发成出现一定时间后自动隐藏的 Toast 提示，这个提示文案是在持续等待一段较长时间后出现（比如上传大文件，或系统处理较多数据的场景下）。

期间用户的视线可能离开产品界面，弹窗提示可以在用户回来后看到执行结果，而自动隐藏的 Toast 提示用户可能会错过。

3）严重不符

这种情况指的是产品与设计严重偏离，已经严重影响到产品的使用。

比如设计约束一个手机号只能注册一个账号，注册时，已注册的手机号不能注册成功，但开发的时候漏掉这一步，注册时可以使用同一个手机号注册多个账号，导致登录时系统无法识别具体要登录哪个账号而出错。

2. 产品与业务不符

这种情况未必是因为产品与设计不符造成的，而是可能产品设计本身就与业务不符，产品的存在是为了服务业务。

所以一旦产品出现与业务不符的问题，则每一个问题都可能是致命的。

3. 需求变更

产品设计与业务不符需要通过调整错误的需求实现来满足业务，这必然会带来需求的变更。

4. 返工

发现错误的设计或实现，需要推翻原来的工作成果，重新设计和开发。

5. 进度落后

无论需求变更还是返工，都会使原本规划好的进度落后。

6. 扯皮推诿

出现问题，大家都觉得不是自己的责任，开始互相甩锅。

二、产品经理为什么不喜欢做验收

既然产品经理验收环节这么重要，为什么产品经理们却不喜欢做验收呢？

1. 验收工作繁琐且枯燥

产品设计的过程是一个探索和创造的过程，对产品经理而言是一个充满乐趣的过程，多数产品经理在完成产品设计交付给研发的时候，都会有一种“这是目前我能做出来的最棒的设计”、“不可能有比这更好的设计方案了”的想法。

而验收就不一样了，虽然交付的是设计，验收的是产品，但产品经理会认为自己的设计很清晰，不应该有人会误解，甚至会有一种“我的设计这么棒，竟然让我给自己的设计挑毛病”的想法。

2. 理所当然地认为这是测试的工作

有的产品经理会认为，设计交付给开发之后就没有自己的事了，最多在开发过程中帮开发厘清一些有疑问的地方，后续其他工作则与自己无关。

3. 规划的版本时间过于紧凑

一般版本的研发时间由研发部门来确定，而研发部门在确定版本时间的时候，只会将测试的时间考虑进去，而不会考虑产品验收的时间，产品经理验收时间不够，验收没有效果，久而久之就没有了验收的习惯，测试通过就上线了。

三、产品经理验收和测试的区别

产品上线后出现问题，首当其冲的就是测试，接着就是产品经理，最后就容易演变成两者的相互“甩锅”。

究其原因是因为公司或部门对二者在产品验收和测试环节的职责范围没有明确划分，最终只能由管理者来确定应该承担责任的人，一般如果管理者是研发负责人，会将责任归咎于产品经理没有做好验收，而作为产品负责人的管理者则会认为是测试人员的测试工作做得不到位。

因此，产品研发两个部门经常“打架”，这也是其中的原因之一。

关于产品经理验收和测试人员测试的区别，我大概列了以下几点，各位可以根据自己项目的实际情况参考一下。

看了以上对比之后，你可能会产生一种想法，觉得产品经理的验收好像很随性，没有明确的标准，没有量化的工具，甚至没有明确的目标。

的确，明确产品经理验收这个环节在业内并没有形成相对统一的标准和方法，更多靠的是产品经理个人的经验和在验收时的敏锐程度。

因此每个产品经理也都形成了一套属于自己的验收经验，一名优秀的产品经理经常能够发现很多测试都难以发现的问题。

四、产品经理验收，到底是验什么？收什么

下面根据本人以往的一些项目经验，简单总结一下，产品经理验收，到底是验什么？收什么？

1. 验什么

1）验业务

产品经理是离业务和需求最近的人，也是接收业务信息和需求信息“失真率”最小的人，验收的时候，优先要考虑的是产品到底能不能满足业务，或者对业务目标有没有帮助，而不能一味考虑产品是否与设计一致。

所以产品经理验收产品的时候，需要代入业务目标。

一个功能，如果能够满足业务目标，但是与设计不一致，在不会影响其他功能或交互的情况下，也是可以被接受的。

因为实现同一个业务目标有时候不一定只有一种设计。

2）验设计

“不能一味考虑产品是否与设计一致”不代表可以不考虑。

上文说到，产品经理验收的时候不像测试人员一样有测试用例，所以产品设计就是最好的验收标准。

按照设计来验收是最快的验收方式，只是在碰到与设计不一致的功能实现时，优先要判断的是实现与业务是否一致，而不是不管不顾地推翻已经做完的功能，要求重新按照设计来做。

3）验场景

场景指的是业务场景，这个环节也是产品经理最容易发现测试人员发现不了的问题的环节。

测试人员对业务的了解基本都是通过产品经理的传递，测试时，针对的业务场景比较单一，产品经理因为对业务的了解更深刻。

因此在测试时，可以挖掘到更多的业务场景，也更容易发现不同业务场景下的问题。

2. 收什么

1）版本基准

当前版本已经验收通过，可以封版发布，所谓的版本基准就是最终发布的版本内容，有些人可能会说，那不就是版本规划吗？其实不然。

版本规划指的是计划要实现的功能，版本基准指的是最终实现的功能，在特定情况下，版本基准等同于版本规划，但更多的时候，版本基准与版本规划总是会有一些不同。

因此需要将当前的版本基准记录下来，否则如果以后按照版本规划回溯当前版本的时候，会发现实际实现的版本与规划的版本并不完全一致。

2）问题清单

“我们需要尽量发现问题，尝试解决一些问题，允许存在一些问题。”这是验收版本时的一个核心思想，你不可能解决所有问题，因为问题会不断出现，所有尝试为了解决所有问题的行为最终都可能会导致版本延期。

所以要有选择性地解决一些必须在上线前解决的问题，并允许一些无伤大雅的问题存在，当然，这些问题并不是就此放任，而是需要记录下来，形成问题清单，在后续的版本中逐步解决。

3）迭代计划

迭代计划除了来自业务的发展和变化，同时也来自验收，验收过程中记录的问题以及发现的新的需求，将形成新的迭代计划，并入到新版本的规划中。

五、产品经理验收容易陷入什么误区

产品经理验收环节容易陷入这个误区，这些误区容易导致验收不充分。

1. 想当然

产品经理在验收某些功能的时候，容易陷入一种误区，觉得自己的设计逻辑是很简单、很符合直觉，或者这是一个常识性的约束，不会有人理解错误，因此就不加以验收。

比如大家都会认为在使用手机号注册账号的时候，如果手机号已注册，是无法注册成功的，产品经理认为这是一个常识，哪怕自己没有在文档中写出来，开发应该也会这样实现，验收的时候也无需针对此项约束进行过验收，结果产品出来的时候，同一个手机号可以重复注册，导致登录的时候系统出错。

要避免这个误区，首先在设计的时候，即使是常识性的约束条件也应该清楚写进文档中，并在开发完成后逐项验收。

同时，要正确理解研发人员的工作方式和工作思维，很多时候是几个研发同时开发一个业务功能，每个人只负责一个子模块，从他们的角度，很难在脑海中拼凑出完整业务的形态。

所以只能根据设计和文档进行开发，设计和文档中没有的内容，他们是不会主动添加进去的。

2. 验收场景不充分

这种就是验收前没有什么计划性，看到哪验到哪，想到什么验什么，这种“随心”的验收方式很容易忽略掉一些场景。

虽然产品经理验收不像测试那样有严格的测试用例，但要避免验收场景不充分的误区，最好在验收前先有一份“场景验收计划表”。

计划表主要需要包含验收的场景、准备的数据、预期验收结果、实际验收结果。如果可以，提前准备好数据值，这样验收的效率更高，准备数据值的时候，注意需要准备多个，主要需要错误的数据值、正确的数据值以及边界值。

下图是我针对注册登录环节验收整理的部分场景的验收计划表，仅供参考：

3. “罗生门”

开发说修复完了，测试说测试通过了，结果产品一看，全是 bug。

这种主要是到了产品后期准备上线的时候经常遇到的问题，产品发现一个问题，开发就改一个地方，测试就测一个地方，导致其他有问题的地方没有被发现。

这种情况一般是需要多方去规避，比如公司应该有明确的测试流程和管理制度，研发规划时间的时候需要冗余足够的时间，产品经理应该充分阐述清楚业务场景等。

以上便是本文的全部内容，感谢阅读。

在进入职场之后，产品经理要如何实现自身的能力提升，从而更好地投入产品岗位、应对产品工作？在本篇文章里，作者就总结了初级产品岗位人员的能力提升方向与可学习的路径，一起来看看吧，或许会对初入职场的产品经理们有所帮助。

2019年～2021年期间，我在做智能写作项目创业的时候，由于当时市场相关产品较少，遇到了问题没有可以参考的竞品。

我们只能一路探索，一路踩坑，一路修正。随着产品的迭代，我也在不断地迭代自己的认知，梳理AI产品的方法论和技能树。当时还和Shadow在“蔚来”做了一次关于《AI时代的产品思维》分享。

但是光有方法论还不够，随着团队越来越大，也出现了一些管理上的新的问题。团队中新入行的同学，在职业发展的道路上产生了迷茫，甚至也有人提出了离职。

我回想起刚毕业的时候，我的导师告诉我：“如果赶路时候，心中有地图，那么你就不会惊慌，你要找到心中的那张图。”因此，作为产品合伙人，我提议在公司内部推行职业岗位上的能力模型。让小伙伴们能看到自己的成长的方向。

其实，我并不是想要推行大厂的那套职级的天梯，更重要的是让小伙伴们有明确的修炼方向，产品小伙伴的也觉得跟着我获得了专业提升。

现在正值毕业季，有很多刚毕业的小伙伴加入产品岗位中来，也希望能帮到大家。

一、修正观念：人人不都是产品经理

大多数人听到“产品经理”这个词，总会联想到“人人都是产品经理”这句话。但实际上产品经理这个岗位并没有那么简单。

用一句话概括产品经理的职责就是“帮助团队交付正确产品给用户的人”。也就是说，产品经理要能凝聚团队的力量交付有价值的产品给用户，而不是一个人孤军奋斗。

我认识的一些优秀的产品经理，往往都是程序员或者交互设计师出身，他们的特点是学习能力很强、知识面广博、思维敏捷、逻辑严密、沟通能力很强。他们能带着你一步步思考，能够清晰地告诉你怎么样的产品才是正确的产品；另外，他们还有很强的驱动能力，不管是对自己还是对他人，是团队不可多得的发动机。

我个人的成长经历也比较杂糅，大学是学工业设计的，却阴差阳错的做了程序员，还和朋友一起创业。有人评价我不够专注，但是恰恰正是有这样的经历，让我对如何做产品有了最直接的体感，这个能力区别于在大厂单一岗位培养的产品经理。另外，我也不是完全跟着感觉走，平时也在不断的学习和总结，用体系化的思维框架整理自己的经验和知识，每个职业都有自己的最底层的思维框架，产品经理也不例外。

从思维框架层面，产品经理的核心能力就是要懂得如何平衡人的需求、技术的可行性、商业价值三方面问题。这个思维框架被著名的设计公司IDEO称之为“设计思维”（Design Thinking）。

我在从业的过程中，用这三个圈的指南针来指导我在产品岗位上学习、工作和决策：

1）人（Human）：以人为中心。产品经理应该深入了解用户的需求、痛点和行为，通过观察、用户研究和用户反馈等手段获取关于用户的信息。产品经理需要思考如何创造出对用户有意义、有价值的产品和服务，以提供优秀的用户体验。

2）商业（Business）：关注商业可行性。产品经理需要理解公司的商业目标和战略，将用户需求与商业需求相结合。产品经理应该思考如何创造出具有商业价值的产品，并将其与市场需求和竞争环境相匹配。同时，产品经理还需考虑产品的盈利模式、市场份额和增长潜力等商业指标。

3）技术（Technology）：利用技术实现创新解决方案。产品经理需要了解现有的技术趋势、技术能力和可行性，以确定合适的技术方向和解决方案。产品经理应该与工程团队紧密合作，探索和评估不同的技术选型，并确保产品在技术上可行、成本可控、系统稳定和可扩展。

通过综合考虑人、商业和技术，产品经理可以更全面地理解和分析问题，找到平衡点，并在设计和决策过程中做出明智的选择。这三个圆圈相互影响、相互支持，帮助产品经理设计出具备用户满意度、商业可行性和技术可行性的产品。

另外，从产品经理的职业能力上看，可以分成四个圈层：素质层、认知层、影响力层和交付成果层：

1）素质层：素质层指的是产品经理的个人素质和品质，包括职业道德、责任心、团队合作能力、沟通能力、自我驱动等。这些素质是作为产品经理的基础，能够帮助建立良好的工作关系、处理复杂的工作情境，并展现出专业和可信赖的形象。

2）认知层：认知层指的是产品经理对产品管理领域的知识和理解能力。这包括对产品开发流程、市场分析、用户研究、竞争分析、商业模式等的理解。产品经理需要具备全面而深入的行业和产品知识，能够从战略和商业角度思考问题，并做出明智的决策。

3）影响力层：影响力层强调产品经理在团队和组织中的影响力和领导能力。产品经理需要能够有效地沟通和协调各方利益，与团队成员、上级、利益相关者进行有效的合作和交流。他们应该能够激发团队成员的潜力，建立良好的工作氛围，并在组织中推动产品管理的重要性和影响。

4）交付层：交付层是指产品经理能够通过实际行动和结果展现自己的能力。这包括制定产品战略方案、需求管理、撰写需求文档等工作，最终的结果通过成功推出具有商业价值的产品、实现产品目标、提高用户满意度等来呈现。产品经理要能够有效地管理产品项目，与团队紧密合作，按时交付高质量的产品，实现业务目标和商业价值。能力越大，责任也就越大。

产品经理的交付能力成长过程分类三个阶段：方案交付能力、产品交付能力、战略交付能力。

这四个层次相互关联，结合设计思维的三个圆环构成了产品经理综合能力的框架。通过不断提升自身的素质、扩展认知领域、增强影响力和能够交付出色的成果，产品经理可以更好地应对各种挑战，发挥更大的作用，并取得成功。因此有了这张岗位能力模型图：

二、方案交付能力：千里之行始于足下

你可能会发现，初级的产品岗位名称（对标阿里P4及以下）常用的是产品专员或者产品助理，为什么不用“产品经理”这个Title？

初级阶段的产品工作人员工作和能力，其实配不上“经理”的Title，产品经理是需要承担团队最终的交付结果的人，需要学习产品管理知识、需要有深刻的行业知识、需要有技术和设计能力、需要有沟通和协调能力等等，没有三到五年的基本功修炼，是不可能有好的“产品交付能力”，先要达成“方案交付能力”。当你具备了基本“产品交付能力”才能算一个合格的产品经理。

因此，针对初级的产品从业人员，我们团队用“产品设计师”的岗位名称。从而强调我们新晋的产品工作者，首先要有交付正确方案的能力，“方案交付能力”是“产品交付能力”的基本功。起码要能产出高质量的产品原型设计方案和具有可行性的需求文档。

如果把P1到P4，比作做是大学四年的学习的话，我们需要修完所有的专业课程才能顺利的毕业。现在我开始对这些“专业课”进行介绍，并且推荐了一些“课本”，希望不管你是产品设计师还是初级产品经理，都可以查缺补漏一下。

首先，要把一个合格的方案交付给团队，我们就需要有基础的设计能力，能够将合格的原型给到团队。

1）原型设计

原型设计是很重要的交付成果物，让团队成员能够清晰的知道需要做什么。主要讲清楚产品需要有哪些信息，是如何与用户交互的，分为低保真和高保真图，想要产品体验好，交互设计能力不可少。

需要了解交互设计基本原则，推荐书籍《About Face: 交互设计精髓》《点石成金》《简约之美》《用户体验要素》《破茧成蝶》；设计心理学，推荐阅读唐纳德诺曼《设计心理学》系列。

需要有信息架构的设计能力，如果是AI产品经理，还要从传统UI的信息架构还要延伸到语音对话的沟通信息架构，推荐阅读《信息架构，超越WEB设计》《语音用户界面设计：对话式体验设计原则》《Google 对话式交互规范文档》《Amazon 语音交互设计规范文档》《Machine Learning for Designers》。

另外，就是UI设计的相关知识，我们不仅要去关注流行趋势，更需要熟悉UI设计的理论和准则，推荐阅读书籍《认知与设计：理解UI设计准则》《平面设计原理》《写给大家看的设计书》《通用设计法则》。

除了活动类产品，强调活泼有趣的画面感，大多数产品UI都遵从设计规范（Material Design、iOS规范等），需要具备了解设计规范的制定逻辑（配色、排版、组件、图标），并且能够将规范和产品的灵活结合在一起，最后通过UI设计软件（Sketch、Figma）进行输出。

2）产品规划

产品规划中需要产出对应的规划文档，最常见的有产品需求文档PRD、其次是市场需求文档MRD和商业需求文档BRD。

针对初级的产品工作人员，最基本的要求是需要能够写好PRD。需求制定并不是把原型图简单的往上一放。一方面，你要深入地理解用户需求和产品目标，并且对需求进行识别和拆解，推荐阅读《金字塔法则》《软件需求（第三版）》；另一方面，要能撰写清晰、具体的需求文档，包括需求描述、功能需求、非功能需求等，以便开发团队和其他相关团队理解和实施需求，推荐书籍《火球UML大战需求分析》《需求工程》以及阿里巴巴的“五导家”模型。

随着产品开发的进行，需求可能会发生变化。因此，产品工作人员应该定期更新PRD，以确保文档内容与产品的最新需求保持一致。

3）市场调研与竞品分析

市场调研与竞品分析的内容通常呈现为调研报告，也会呈现在BRD和MRD上，用来推动领导层和团队达成共识。

市场调研不是一堆复制黏贴、截图就完事了，需要收集数据和分析、解读和洞察，将调研结果能够应用于产品决策和战略制定上面。我们通过对于企业的调研可以分析它的产业价值链和商业模式，推荐学习波特五力模型、SWOT分析和商业模式画布。

我们还要通过分析产品的迭代情况和功能反推背后的战略目标，推荐阅读和学习《用户体验要素》《蓝海战略》的价值曲线图、“用户体验地图”分析等。

4）业务数据分析

业务数据分析的报告内容通常出现在产品的规划文档和复盘报告中。初阶的产品工作人员需要，了解常用的一些数据指标的计算方式，如DAU/MAU、PV/UV、GMV、ARPU、点击率等，产品经理需要经常计算业务的转化漏斗，需要擅长使用Excel或者Python，推荐阅读书籍《深入浅出数据分析》《深入浅出统计学》《数据思维：从数据分析到商业价值》《产品经理数据分析实战手册》 《网站分析实战：如何以数据驱动决策，提升网站价值》。

另外，也会涉及到一些通过SQL查询获得业务报表的场景，所以产品经理还要了解基本的SQL语法，推荐书籍《SQL必知必会》《利用Python进行数据分析》。

并且产品经理也要知道，如何根据不同的业务特点制定的核心的可衡量的业务指标、制定产品的改进策略，推荐阅读《精益创业》《精益数据分析》《增长黑客》等相关书籍。

5）用户分析

用户分析的内容会出现在产品规划文档中，也会出现在产品复盘的文档中。在产品项目前期，我们也要参与到用户调研和用户画像制定的过程，在阶段性复盘的过程中我们也要去了解和收集用户的反馈。我们需要能够有以人为中心的设计思维方式，站在用户的场景和视角来思考问题，推荐学习“用户体验地图”的相关知识点。

绘制出有效的用户画像 Persona（相关书籍推荐《About Face：交互设计精髓》），通过分析用户在场景中的流程，找到痛点，使用心理学一些知识点去发现问题解决问题，提出产品需求和迭代的方向，推荐书籍《认知心理学》《社会心理学》《思考，快与慢》《马斯洛需求层次理论》。

对于C端产品来说，还有很重要的是，自己也要能带入到用户的角色中去和用户打成一片，成为自己产品的用户，在使用中发现更多的问题。另外，能够了解定性和定量的用户调研手段和分析的一些方法，推荐相关书籍《用户体验与可用性测试》《用户体验度量》。

有了上面5项基础的交付技能还不够，你需要更多的背景知识的支撑，才能让你的方案更有灵魂：

1）商业认知

初级产品工作者通过学习市场营销的知识，来提升自己对市场和运营的理解。例如，4P理论、STP理论。

另外，产品经理需要与运营团队紧密合作，知道产品运营的思考方式，推荐阅读书籍《流量池》《运营之光》《参与感》《爆款文案》，要从一个简单的营销页面就能感知到很多的门道。

此外，产品的每个前台功能都可能涉及到一个运营后台，涉及到推荐逻辑和管理逻辑，也要充分考虑到内容运营和用户运营的各种底层逻辑。

2）软件工程与架构

虽然产品工作人员不需要亲自敲代码，但是产品是怎么做出来的需要有清楚的认知，否则就是盲人摸象。

软件工程知识可以帮你系统的了解软件生产过程，推荐书籍《软件工程最佳实践》《软件工程：实践者的研究方法》；软件架构的相关知识，能够让你知道如何设计软件系统才是合理的，让你的需求文档更有说服力，推荐阅读《系统架构，复杂系统的产品设计与开发》、《大象：Thinking in UML》等书籍。

另外，建议所有的产品经理应该亲手尝试编程做一两个小项目，这样你对技术会有更深刻的体会。其实编程语言比英语要简单很多，特别是今天有了ChatGPT的加持，门槛变得更低了。

3）人工智能技术

AI产品经理需要了解人工智能的相关知识，知道如何将AI技术应用到自己的项目中去。包括但不限于以下几个方面：

首先，对常见的人工智能算法和模型有基本的了解，如机器学习、深度学习、自然语言处理等，能够知道常见的模型评估指标，如准确率、召回率、F1值、AUC等。

其次，需要了解数据处理和数据标注的基本原理和方法，以确保数据质量和训练模型的有效性。

同时，了解人工智能的伦理和法律问题，如隐私保护、数据安全等，以确保产品的合规性。

最后，对人工智能技术的发展趋势和应用场景有一定的了解，以保持对市场的敏感性和判断力。

此外，了解常见的人工智能工具和平台，如TensorFlow、PyTorch，以及GPT、Stable Diffusion、Midjourney、LLaMA等，能够理解它们的使用和优缺点。

4）行业认知

产品工作人员需要对自己企业当前所处的行业有足够的了解，小到一个常用业务功能的设计的最佳实践，大到整个行业竞争的格局和市场变化。

能够分析生态链和已有商业模式，推荐书籍《商业模式新生代》的商业模式画布、迈克尔·波特的“价值链分析”。

了解市场规模、增长趋势、机会和挑战，同时评估竞争对手的产品特点和定位，推荐书籍《市场竞争战略》。

预估行业的趋势，推荐阅读《跨越鸿沟》《创新者的窘境》高德纳Gartner的《技术成熟度曲线》。

另外，还要关注国家的法律法规的动态，避免在产品设计的过程中触及红线。对于行业信息的获取，一方面是同行或者业内资深人士的交流，另外一方面可以通过一些行业的自媒体或者媒体网站如36氪等媒体网站来了解。

另外，还有三个对于基础素质的考核：

1）执行能力

作为执行层，执行力毋庸置疑的重要，执行力并不是低头干事，我们需要明确自己的目标，通过能够分析问题，拆解问题。需要了解“金字塔法则”，”5W1H分析“，并合理安排的自己每日的时间和计划、“SMART法则”和“重要紧急四象限”、PDCA循环（Plan-Do-Check-Act）（推荐书籍《麦肯锡问题分析与解决技巧》），从而提升自己的工作效率（推荐书籍《高效能人事的七个习惯》）。

另外，也要了解项目管理的敏捷开发相关知识，你才能更好地管理和执行需求。

2）沟通能力

不懂沟通，就不会执行。做产品的一定要和开发撕逼的吗？不同的人有不同的沟通方式，核心的关键是站在对方角度思考，而不是陷入到不良的情绪中。

所谓沟通能力并不仅仅是把事情说清楚的能力，善于沟通的人往往善于倾听。很多时候，你的解决方案并不是完全来自你自己，需要产品经理有专业的沟通能力，要能用相关专业知识带领大家层层深入，最终达成团队共识，推荐书籍《关键对话》《非暴力沟通》。

3）学习能力

其实“学习能力”是一种心态。在职场上，许多人工作了好几年，为什么没有什么长进？其实大部分人对工作的态度是做一天和尚撞一天钟，并没有主动提升的意愿；还有一部分人虽然看似热爱学习，但陷入了“理障”和“我执”。

“理障”是把自己限制在自己认为的道理或逻辑中，忽视其他差异性的观点和信息；“我执”是相信自己永远都是对的，不接受别人的批评和挑战。这两类心理现象都会限制我们成长。

如果要破除“理障”和“我执”需要我们做到以下三点：保持开放心态、有批判思维、做到知行合一。

例如，当你画原型图的时候，可以根据一些设计原则进行设计，但是不必太拘泥某个设计原则，因为设计原则是前人总结的经验，并不适用于所有场景，当你无法决策时候，一方面你可以根据业务目标判断。另外，你可以和他人交流，有时候直觉判断可能会更加准确。另外，上线之后可以通过复盘和反思修正自己的认知，推荐书籍《刻意练习》。

三、小结

初级产品岗位的历练大概2~3年左右，时间并不漫长，如果你能知行合一，你可以学到很多东西，但也可能会遇到很多困难……但这并不是坏事，因为简单的事情是无法铸就你独一无二的竞争力的。

产品经理是一个极其需要综合能力的岗位，但是学校并没有产品经理专业，每个行业、每个公司，每个团队，每个人的理解都会有所不同。

我大学本科和硕士都是读工业设计专业，当时受保罗·格雷厄姆的《黑客与画家》的影响，有种想自己亲手把软件做出来的冲动。我在临近毕业时候特地去学习了编程技术，并找了程序员的工作，又工作了一段时间，我最终选择了产品经理这个岗位。很多人不理解，认为我做事情不够专注。其实，我并不这样认为，其实设计和编程都是一种创造性活动，我真正的目标都是要把一个好产品做出来。

正是因为有这份经历，让我对于怎么做一款互联网产品也有了更深刻的理解，之后在创业的过程中，也能够更好做好创业者的角色。

有一次创业，我的合伙人都是算法工程师，因为公司没有像样的产品，导致这家创业公司开了快一年了还是没有一个订单。当时团队也没有钱招聘设计师和前端开发人员，我和团队说：“这样吧，给我点时间，把东西做出来，到时候看看能不能卖钱或者融资”。然后，我主动承担起设计和前端开发的任务。半年过去，产品做出来了，也成功谈到了投资，团队续命成功。这就是产品交付能力的最好证明。

毕业许多年后，我偶尔还是回学校讲课。我也经常提醒学弟学妹：“产品设计师不仅仅要能出设计方案，还要有足够强的动手能力，这是传承百年的包豪斯精神。”

如果你已经正式地进入产品经理的行列，请听下回讲解《产品经理如何交付产品和战略》。

产品经理这一岗位下有许多细分范畴，其中，财务产品经理就是一个细分类别，它属于B端产品范畴，不仅需要懂业务，还需掌握财务知识。那么，你了解财务产品经理的职责所在吗？财务产品经理又有着怎样的发展方向？一起来看看作者的总结。

一、产品经理与财务产品经理

产品经理，指针对某一项或某一类的需求进行规划、设计、管理的人员，注意这里的“经理”是指个名词，泛指一种岗位，不是管理序列的“经理”、“主管”概念。

产品经理概念比较广泛，从研发对象主要分为有形产品经理、无形或数字化的产品经理，如“产品经理”概念创造者-宝洁公司，他们的产品经理主要设计、研发各种洗护用品，是看得见摸得着的有形实物；而最近火爆全网的ChatGPT，则是由微软收购的OpenAI公司的产品经理设计出来的，是一项无形、数字化产品。本文主要讲后一类（数字化）产品经理，它又分为C端产品经理和B端产品经理。

财务产品经理，属B端产品范畴，但比B端更具特色，不仅要懂业务，还要精通财务知识，在纷繁复杂的业务变化中要敏锐定位到对财务的影响，并能迅速找到解决办法。

二、财务产品经理工作职责

1. 什么是财务产品经理

简单来说就是负责财务相关需求并落地实现的产品经理。关键词：财务、需求、实现。

不懂？没关系，我们来看《资产负债表》：左青龙、右白虎，呸呸呸，是左“资产”、右“负债及权益”，相信了解点财务知识的同学就明白，这是负债表的构成。如下图：

2. 财务产品经理的范围与边界

财务产品经理根据职责内容的不同会分为不同的类别。通过上图，我们大概知道，有“货币资金”科目，对应“支付产品经理”；有“应收账款”、“应付账款”，对应“结算产品经理”；有“应交税费”，对应“税务产品经理”；固定资产、无形资产对应有”资产产品经理“；还有体现在《利润表》中的“收入”科目对应“营收产品经理”，以及“成本产品经理”、“管报产品经理”等等。

在不同的企业根据企业实际特性进行划分，如金融企业的“支付产品经理”、提供第三方服务的企业（如滴滴打车）的“结算产品经理”均会划为业务类而非财务类产品经理。

由此可以看出，财务产品经理的边界以财务为核心，到业务系统的交互点为直径所形成的圆圈。

作为财务产品经理，应该理解并能评估业务如何影响财务及后果。另外，需要具有财务敏锐度，以便在企业产品架构中定位财务产品。

3. 与财务信息化经理的区别

也许有同学会问，财务的需求，似乎并不一定要产品经理来实现，外采一款ERP也能满足财务需求了。

这话，说对也对，说不对也不对。业内大多财务信息化经理都是从友浪蝶或OS记的实施顾问转换而来。如果仅仅是满足财务的标准需求，市面的ERP确实能满足八九成。再加上ERP实施商一般都身兼咨询业务，如德勤、毕马威等，还能给企业带来一波赋能，将先进的管理理念引入企业，确实是件双赢的事。

那是不是说，就不用财务产品经理了呢？不能。

企业是发展的、变化的，企业的管理思想与理念也在不断改进、完善，从战略、规划、预算、经营、及预实对比及分析等方面为抓手，这些措施的落地都得依赖业务系统、财务系统。一千个人有一千个哈姆雷特，市面上的ERP都是标配功能，无法完全适配企业的各种特性需求。如何将企业的需求落地，就需要财务产品经理发挥聪明的智慧，或二开、或全新研发一个系统。

针对财务信息化这块，涉及方方面面，详见：《还傻傻分不清：财务信息化与财务产品？》。

三、财务产品经理如何快速做出成绩

大家都说要向T形发展，即一专多能，但作为财务产品经理得向π型人才发展，成为拥有2种（财务、业务）专业技能，将多门知识融会贯通的高级复合人才。形成知识广博、经验丰富，同时又具有几项独特竞争力、对某项专长特别突出的新型人才。

1. 理清财务事

作为财务产品经理，应站在公司整体层面设计财务产品架构。非常敏锐的感知和判断每一项业务的变化对财务的影响。

如公司开拓一项业务线，相应就会有新的收入、成本、费用、资金（收、支）等，收入会涉及收入确认准则、类型、税率；成本，如果是销售有形商品则会涉及存货、资产、库存商品等，如果是提供劳务或服务，如美团外卖、滴滴打车的撮合服务；费用会涉及计价、结算、费用控制、确认时点（五步法或三步法）；资金涉及支付、银行、对账，以及与收入的关联。

考考大家，如百度的搜索排名、抖单的广告、京东的会员费，他们的收入与成本分别怎么确认与计量？从产品化思考，应怎么设计？

另外，财务产品经理的主动意识很关键。不能等着财务或业务提需求，要主动梳理财务流程与业务流程，发现和挖掘业务、财务存在的不合理点，思考解决办法，用四象法列出重要程度、难度（实现成本）、影响面、优先级，与干系方沟通，取得支持后主动推进。

2. 钻研业务

平时都说干一行爱一行，作为财务产品经理，干一行得爱二行，财务产品要专要深，业务更不能落后。初入一家公司，最好申请到业务一线呆上1-2周，与一线业务同学手把手的干活，多听多做少问为什么。把问题与思考记在本子上，思考业务背后所隐藏的动因或原理，业务动作为什么要这么做，目的是啥。当把业务摸得门清时，才会让你不被各种伪需求和无效需求带偏。

同时成为业务最贴心的财务伙伴，将财务语言转换成业务语言，及业务当中哪些会涉及财务的点提前告知与宣贯，避免踩坑。

3. 站在产品架构思考财务产品规划

相对C端或B端其他产品线，财务产品有其特殊的一面。一是企业一般都有现成的ERP系统，无论是国际领军的Oracle或SAP，还是国内拔尖企业用友、金蝶，总有一款ERP适合不同阶段不同行业。二是如果现有ERP标准功能不满足业务需求，是基于ERP进行二开还是另行建设一个系统、再对接到财务，这很考验财务产品经理的功底，甚至连产品总监都无法能做出财务产品经理更专业的判断。

举个栗子：

A公司研发了一款智能售卖机（脑补下地铁、商超的各种自动售卖机），销售方式有3种：

• 一种是A公司直接将机器卖给终端企业B，由他们自行管理、售卖饮料、零食，并提供管理软件；
• 一种是A公司将售卖机租赁给终端企业C并提供管理软件，租金按月从C企业收取；
• 最后一种是A公司将售卖机免费提供终端企业D，根据售卖机的销售额按比例收取D企业服务费。

我们来分析下3种业务模式下如何实现自动化入账：

B企业，纯粹的销售商品行为，A公司能根据ERP的销售出库信息实现自动化确认收入、成本。

C企业，租赁模式，根据合同期间每月确认收入，同时还要将折旧、维护费记入成本，一般的ERP无法自动化实现，只能手工录凭证。需要在财务中台实现租赁收入的自动化分摊（将合同期间拆分到月）、生成应收单推送到ERP；同时需要在固定资产将处于出租状态的售卖机的折旧转入成本，这个ERP通过凭证模板能实现。

D企业，提供机器并共享收益与风险，在法律上实质为租赁经营，难点在于收入的确认。ERP是无法知道这种业务信息，需要在财务中台搭建专门模块，通过获取售卖机的销售额（无论是自动获取还是由人工填报），计算出A企业当月的服务费收入，并生成应收单、推送到ERP。

四、财务产品经理职业发展方向

财务产品经理的发展方向主要有两类，一是专业方向，二是管理方向。

1. 专业方向：财务产品专家

财务产品经理无论在甲方还是乙方，根据公司业务规模大小、发展阶段，会有不同的岗位职责。初期时也许一人负责所有财务需求，发展到一定阶段时就会产专门的财务产品团队，每负责一块或几块，专业领域会相对聚焦，产品形态会更加趋向于中台化；对个人而言，可以在其负责的领域获得深入研究的项目机会和平台。

具体的领域划分如收入、总账、税务、应收应付、资产、成本、资金、对账、结算等；成长到一定阶段后，就能独挡一面，成为财务产品专家。

2. 管理方向：财务信息化总监或负责人

在这个层级，更多的是思考建设一套合适的产品和团队，支持财务快速结账、流畅分析，赋能业务发展。眼光与格局，方向不能错，还有资源的争取与协调。在产品规划上有一定前瞻性，对财务相关信息化领域有一定研究，将业界最佳实践与最佳管理思想在企业落地。

在与团队进行需求评审的时候，如果碰见一些难以沟通的意见该怎么正确处理，不让双方都心累？本篇文章，作者将对此问题发生的原因进行分析，并提供对应的解决思路，希望能对你有所帮助。

前些天一位产品同行和我聊了一件最近遇到的工作困惑，他今年在负责自研产品的迭代设计。

当他费心尽力的完成主体方案之后，在需求评审阶段总是要花费大量的精力和其他岗位的成员解释这里为什么要这样设计。

解释的过程是很正常的，尤其是对于关键逻辑，一定要在团队内部达成共识。而他们的问题在于，关注点、争论点聚焦于一个按钮的名称，一个错误反馈的消息。时常花半个小时的时间来争论这种“细枝末节”。

有时，他甚至不想争论了，后退一步。但又觉得作为产品不能总是退让，这样不仅成果会打折扣，还会在团队内部加剧这股风气。

他说：我并非不重视这些细节，而是觉得在这些事情上投入的精力过多。甚至于可能是相互抬杠，而非正常讨论。

另外，其他成员在争论时经常说：我也是用户，我觉得你这样设计不合理。让我这位朋友哑口无声。

他觉得，团队的关注点跑偏了，本末倒置了，也觉得自己推进的太累了。

不知道其他同行遇到这类问题的概率有多大？

实不相瞒，我前些年也遇到过类似的问题，只不过当时自己比较强势，或者说能够找到一些沟通技巧，快速让对方接受。具体方法可以参见这篇文章（如果你提的需求，技术同学“百般推诿”怎么办？）。

其实愿意提意见的同事，本质上出发点都是好的，我们不能过于打击对方的积极性。但是任何事情都讲究一个尺度，过犹不及。

所以，对于上述的现象，我是这样考虑的：

我觉得这是一种“披着用户思维的外衣抬杠”的行为。因为“用户思维”这四个字，看似简单谁都能做到，实则不然。

就像人人都是产品经理一样，但真的人人都能做一位合格的产品经理吗？

答案自然是否定的。

你是用户，不一定具备用户思维，你认为自己在以用户思维考虑问题，也许只是“局部用户思维”，这和我们常说的局部思维陷阱是一个道理。

那么，我们如何解决这类问题呢？我浅析以下几个方面作为参考。

一、产品团队要树立自身的口碑和“设计话语权”

首先，最直观的表现是我这位朋友在团队中没有足够的口碑及话语权，或者说让同事足够的“信任感”。

从另一个角度讲，他没有说服你，你也没有说服他。那你为什么没有说服他呢？我觉得你理应可以说服他。

所以要么是自己对于自身的决策没有足够的信心和全盘思考，因为如果真的想明白了，再加上一些沟通技巧，大概率是能够说服对方的。

要么是自己在团队内的“威信”不足，所以产出的设计方案缺少话语权，或者缺少天然的信任保护。

试想，如果自己有一定的设计话语权，当你的方案对方不认可时，大概率他会先自我怀疑：是不是我自己哪里考虑的不周到？而不是双方意见不一致时，对方坚信自己的对的，你是错的。

二、其他成员可以建议，但产品团队有决策权

尤其是一些自研团队，我们需要头脑风暴，需要各抒己见。但对于这些观点的筛选、过滤、最终再进行挖掘与整合，打开产品团队的视野和思维，将是个很重要的过程。

而且，业务相关建议的决策权，一定要掌握在产品团队手中。即大家可以提建议，但决定采纳与否你们说了不算。

如果你觉得自己的意见弥足珍贵，那请你拿出可信的理由。

这一点，很多创业型团队，或者有些同行很不好意思拒绝对方的建议。我觉得这是产品人在成长过程中势必要迈过的一条“心理障碍”。

假设连自己同事的“伪需求”都无法解决，将来如何解决客户的建议、用户的建议、领导的建议？

三、产品团队要对结果负责

结合上一条的决策权，紧接着就是：谁决策，谁负责。

产品团队要勇于对结果负责。当你觉得对方的建议会对结果造成不利影响时，那就坚持自己的思路。

毕竟，踩坑也要踩到自己的坑里，而非别人的坑里。这是一个很正常的现象。

四、本质上是团队各个岗位职责边界的问题

试想，产品经常给研发提管理意见，研发经常给产品提设计意见。乍一听这个团队挺扁平化，大家能够充分发挥自身能力。

但细想一下，你经常被其他岗位同学“提建议”，你是什么心情？会不会想着：将来也给他提回去。

而且我们经常会发现，自己的本职工作还没有做好，关注点就会向外探索。这种模式不利于自身的专注和深耕。

相信专业的人做专业的事。当团队内部互相不认可对方是专业的，那便是出了大问题。

当然，并不是说各岗位之间各司其职，却不相互沟通；而是凡事都有一个尺度和体系在下面支撑着，我们需要在这套体系里运转。

当体系缺失，又没有绝对领导者时，便是纷争的开始。

很多问题，都要打破自己的惯性思维，不要停留在表象去考虑如何说服对方，而应该向内观察一步，从表象的背后寻找更深层的“道”和“因”。

我只把这个问题向内挖掘了一层，如果继续探寻背后的问题，可能需要更高层的领导介入解决了。因为这本身又是如何统一内部目标和思维边界的团队管理问题。

五、写在最后

最近刚刚读完《复盘》这本书，虽然我对本书的整体评价不高，但其中有一个对于团队U型复盘的章节还是能够为今天的话题带来一些启发。

团队管理中的一个核心挑战，就是如何从外在驱动到内在驱动，这需要一个反思的文化和向内看的氛围。

无论是个人还是团队，我们都习惯了一种“自动反应”。即在面对问题的时候，没有经过深层思考，而直接给出条件反射式的答案。

而且，如果一件事偶然出现，责任可能在别人；如果一件事反复出现，责任可能在于你自己。

所以，把关注点先向内挖掘，再尝试突破自动反应，再从个人走向组织，重复向内看和突破自动反应的过程，循环几次就会有更多有效的方法出现。

聊了这么多，最后只想说一句话：

我说的都是错的，真正的答案在你的脑海里。