作为产品经理，结构化思维也是必要的一个能力，它可以帮助我们进行更深入的思考和更高效的工作。那如何培养或者提高结构化思维呢？让我们一起来看看作者是如何分析的。

上期讲完了关于需求的部分常见的问题，这篇文章我们来聊聊产品经理的结构化思考。

对于初中级的产品经理，是不是常常会遇到这样的问题，当一个需求或则项目来临的时候，你不知道从哪些方面入手去分析，或不确定是否分析的全面。

在这里提供给大家一个思路，就是在平时的工作中可以大量的积累结构化思考工具。结构化思考训练能保证我们在平时的工作中保证及格水平以上，很多时候我们看起来某个产品经理在面对需求的时候能够快速的反应，原因无他，就是平时积累了这方面的结构化分析方法。

很多产品经理对结构化思考有误解，觉得是套书袋，但其实不是这样的。如上面讲的，结构化让我们在面对事物的时候至少可以保证及格水平，不要有遗漏的思考维度。在此基础上，我们可以更进一步的深度思考，创造出优秀的产品。

大家在平时可以积累一些结构化的工具，像前面提到的用户体验地图，宏观分析常用的PEST模型、五力模型，需求分析用的卡诺模型等等。在这篇文章里，我会重点拆解DFX模型，如果有人之前听过并且学习过这个模型，请仔细回忆下你了解的内容是什么。

接下来我讲的内容，我可以保证绝对和你之前从任何渠道学习到的都不太一样。

次重点推荐$Appeals和MVP模型。

• $Appeals
• DFX
• MVP

这么多模型，为什么偏偏要讲$Appeals, DFX和MVP 呢？

• MVP让产品在市场的检验中不断完善，一改了传统的硬件完全搞完再上市的设计思路。
• $Appeals代表的是大产品的思维。产品经理不应该只是关注产品的物理本身，同时要关注产品设计到的各方面。
• DFX是一种产品设计的终局思维，以终为始的设计思维。产品不是走一步看一步，而是在一开始就要明确为了配合产品最终的上市，在起始的时候应该怎样设计。

一、$appeals 模型

$appeals是由8个单词组成，而每个单词代表了产品的某一个维度。

价格、可获得性、视觉、功能表现、易用性、保障、生命周期成本、社会可接受度。这8个方面大家可以从各种渠道去学习具体的内容，在这里我就仅仅提出这个模型，有想去的产品经理可以去重点研习下。

这个模型可以说是产品经理的必备模型之一，也是初级产品经理能够跃升的第一个重要门槛。

拿出一个你之前做过的项目案例，假想你在一开始之初就知道这个模型，那么你将会怎样重新定义你的产品。模型再好，如果不拿来训练，等于白费，这个模型的重要性说多少遍都不为过份。

二、DFX模型

DFX是英文单纯design for x 的缩写，X代表的是产品的各个阶段，即就是针对“X”这个阶段，我们应该怎样design。

考虑产品生产阶段，X对应的是Manufacture 和 Assembly。在这个领域有本经典的书籍《Product Design for Manufacture and Assembly》，由Geoffrey 、Peter、Winston 合著。

DFM和DFA最核心的目标便是尽最大可能合理的减少所需要的部件，进而达到降低生产和组装成本。

DFM要求产品部件设计时尽可能降低部件在产品生命周期内的总成本。

例如某个部件特殊化设计可以减少当前这个部件的单词采购成本，但是从整个产品生命周期视角来看这个部件生产周期过长，每次都要提前囤货，这些囤货成本最终也会算到产品的成本中。如果产品在什么周期内出货量不大，每次囤货成本又过高，那么这样的设计便并不可取。

同样是某个部件的特殊设计，虽然前期需要支付不少的开模费用，但是这个产品在整个生命周期内预计会有百万的销量。所以整个开模费用加单个采购成本平摊到每个产品后的费用，相对于采用通用的部件设计会更有优势，所以这种情况下此部件可以采用特殊设计。

DFA的目标就是尽量减少组装工序从而达到节约时间的目标，在节省人工或加工成本的同时提高了生产效率。

考虑到产品销售，X对应的是Legal，即产品的合法性，合法性主要营销内容的合法性，产品质量的合规性，产品知识产权是否有侵权。

不同国家对不同消费电子品类有不同的法规要求，不同法规对应的需要做的认证不同，而不同的认证则会影响到产品的原材料选型。

例如当某个电子产品需要满足Reach认证时，它所需要的器件规格和不用做Reach认证的产品选用的器件规格就差异比较大，具体到产品的成本就会较大差异。

国内消费电子类产品大多要满足3C认证、带有WIFI或蓝牙的产品需要通过无委认证，4G产品需要拿到入网许可证，欧洲的电子产品大多要CE认证，印度要做BIS认证，美国做FCC认证，独联体做EAC认证等。

不同国家不同品类的产品质量规范和认证要求需要我们在产品立项时就需要明确出来，这样硬件工程师和结构工程师在产品器件选型时才有参考标准。

知识产权则是产品合法上市销售时另一个需要重点考虑的因素，小到产品彩盒上宣传文字的字体是否拥有版权，大到产品的设计方案是否已经被其他公司申请了专利。

通常我们会考虑商标、字体、外观、解决方案等，很多野蛮生长的卖家因为对知识产权的淡漠最后被市场重罚的例子不在少数，尤其是在亚马逊上经常有中国卖家因为知识产权的问题货物被全部扣押，账户的资金被冻结。

所以知识产权的问题需要我们在产品设计之初就要充分评估，如果涉及到可能的侵权问题，要想办法尽早规避。

考虑到产品报废，X代表这Environment，即面向环保的设计。产品的选材是否环保，在报废后不应该对自然造成污染。尤其是儿童类的产品，小孩子们特别容易去用舌头舔，在这种情况下是否能达到无毒无害。

不同国家对于产品环保的强制要求不尽相同，但作为产品经理在设计产品时候，要有环境友好型的产品的意识。

除了以上的DFX思维，笔者结合自己实际做产品的经历提出了Design for Failure的设计理念。失败是我们做产品的人最不愿意面对的事情，不愿意面对并不意味着失败出现的概率会变小。

假设这样一个问题：如果你的产品推向市场失败了，最后被当成“电子垃圾”，你还有勇气去让他发挥最后的一点剩余价值吗？

在这里我们提出Design for Failure的设计理念，极面向失败的设计思路，其核心思想是如果产品已经失败了,那么如何提前设计功能让他发挥其剩余价值。

前几年智能音响大火，很多厂家都跟进推出对应的产品，但最后浪潮褪去，很多品牌因为经营不善就关闭了服务，这个时候你就会发现，关闭了云端服务的智能音响成了一个彻彻底底的废品。

虽然看着是个音响，可很多是没有预留音频输入接口的，且只能通过语音交互“打开蓝牙”后连接到手机播放音频，可是当服务器关停后是无法和智能音响再对话，所以造成了一个局面就是你不能把他当作一个音响用，只能当个摆件放在那里。

笔者也曾参与到智能音响的设计大潮中，推出过一款智能音响产品，当在产品设计之初时，笔者就考虑过如果智能音响的智能没有了，那么怎样让他就单纯的当作一个音响？

所以在笔者做的那款智能音响中，我们把“打开蓝牙”这类基本的控制指令，做成了离线的版本。什么叫做离线的版本呢？就是当你设备不联网的时候，你给它说这些指令，它也可以执行。

这个功能在技术上难度不大，但是市面上绝大多数智能音响的“打开蓝牙”指令，都必须是设备联网后进行语音交互才能打开。所以Design for Failure的设计理念是保障产品在主线任务失败的情况下，还能让产品发挥一些余热。

产品立项之处，不仅要召集设计、软件、结构、硬件、项目经理等显性开发人员，也要注意让测试、质量、工艺、生产等相关环节的同事早早接入。充分评估项目潜在的风险点，提早做出预案。

三、MVP 模型

MVP我想大家都听过，而且很多人听烂了，但许多硬件产品经理觉得这个是互联网的东西，硬件产品比较困难，但其实不是的。

你要针对你研究的问题做核心的提炼，然后用最低成本的方式做出来去验证。

我们当时设计一个灯，对于灯的数量大家争执不下，怎么办？我们用A4纸打印出来，折叠一下直观的看看就行，因为我们争论的是灯的排列方式和数量，而不是灯的亮度或其他的，那么我们直接纸质折叠就能模拟验证。

结构化思维在产品经理的工作生涯中会伴随较长的一段时间，在这里我无法一一列举，也不想展开讲太多。这篇文章仅仅作为一个结构化思维的启发，让产品经理在以后的工作中多注意。

下一篇文章，我们来讲讲从PM到GTM的跃迁。

作为硬件产品经理，在寻找或者面对客户时应该怎么洞察客户，抓住商机？这或许是每个硬件产品经理都在思考的问题。这篇文章作者从五个方面对这个问题进行了分析，希望能对你的工作有所帮助。

作为硬件产品经理，我们要时刻去搜索商机、把握商机、最终赢得商机。

但商机不是说，你要找到一个大客户或大订单。这当然是，每个硬件产品经理所神往的，但日常中的商机是一个个小趋势，甚至你不仔细看，它就偷偷溜走了。

这些小趋势的洞察，是硬件产品经理的必修课。

一、订单驱动

这是我们非常喜欢的方式，也是经常遇到的。客户带着订单过来，因果链路极短。只要你帮忙开发出什么产品，就给订单，年订单多少、首单多少。

那我们做不做？

非常简单的方式是，计算下ROI投入产出比，值得就做，不值得就不做，但这是小逻辑。背后的大逻辑是看，要做的产品的商业价值，和客户的商业价值。

产品的商业价值容易理解，如果要做的产品符合产品线Roadmap，那当然要做。但做的时间和节奏需要权衡，此时客户首先不是金主爸爸，是你产品的首个种子客户。

那客户的商业价值如何理解？

如果客户是某个行业大客户，对于公司是有百益而无一害的，比如沃尔玛。那毫无疑问要做，此时做产品的目的是，满足公司战略。

有两方面的价值，一是大客户背书，提升行业影响力；二是未来巨大的商机，可能带来不可估量的订单。

这是在平坦的路面上曲折前行，目的是找到杠杆。

二、竞争驱动

这是硬件产品经理经常使用的方式，也是非常有效的方式。

只要我们找到竞争对手身上的优点，进而复制，我们就有机会赢。但现实是这样吗？这里容易犯的错误是陷入表面，没有深入了解产品背后的本质。

举个例子，06年，大名鼎鼎的微软发布了Zune数字播放器，直接对标苹果iPod。Zune基本是一个仿照iPod的设备，它与iPod有着相似的外观、界面和操作，以及音乐播放和视频功能，最终Zune却输地一塌糊涂。

我认为Zune失败的主要原因是，他低估了iPod+iTunes打造的数字生态圈的力量，它强绑定了客户群体。所以，竞争驱动的商机，不能单单站在产品维度去思考竞争，一定要站在公司层面去思考。

对方的竞争壁垒这么深，有品牌、渠道、供应链、生态、服务，Why us？为什么我们做有机会赢？

二是产品维度的差异化。竞争上对方有什么弱点，是可以利用的？音乐手机、拍照手机就是一个典型差异化产品，通过把产品的某个功能做到极致，然后深挖对此敏感的客户群。

有时候，知道自己不做什么，比能做什么更重要。

三、数据驱动

产品发布后，市场会不断地给予反馈，其中最主要的正反馈就是客户的订单。客户订单下地越多，说明产品成功的可能性就越大。

当然订单数据只是小视角，更大的视角应该是有所发现：

• 一看客户订单的增长率。如果某个客户近期突然订单激增，接连下了好几个大订单。我有一个客户，因为成为了亚马逊的VC（Vendor Central），订单增长很快，那这个就是一个重要商机。接下来的动作，可以是重点支持该客户，以扩大其亚马逊渠道的销售。又或者是找到其他区域亚马逊VC，然后复制它的成功。
• 二看客户画像。如果某一类客户，原本不属于目标客户，突然有订单了，那就要引起重视了。接下来的动作，要去拜访其中几个核心客户，详细了解其业务逻辑、产品逻辑，确认这个新客户画像、新场景的商机。
• 三看新客户。如果某个行业大客户突然下单了，即使量很少，那这也是一个重要信号。这里说一个好玩的事情，就是行业大客户经常会有竞对的危机感，如果他发现他的主要竞对，已经和你合作了，就会引发他开始接触你的产品。

所以攻克一个大客户，往往能有横扫千军的效果。要善于分析数据，不要光看客户怎么说，而是多看客户怎么做，而数据就是客户动作的痕迹。

四、技术驱动

产品经理是创造有利可图的用户价值，哪里有有利可图的用户价值，哪里就有商机。用户价值是满足某个场景下，某个用户的需求。

通常情况下，用户价值和需求是一个平衡关系，平衡关系下是没有商机的，必须打破平衡。那如何打破平衡，得看场景、用户和技术这三个因素发生变化。

场景和用户的变化，如城市化带来居住环境的变化、应届生暴增带来的租房的变化、用户的消费升级的变化、居民收入增加的变化、老龄化的变化等，但这些是长期趋势，我们很难在生活中察觉到，更多的是作为产品佐证的手段。

而技术这个因素是我们唯一可以把握的，利用新技术重新做一遍产品，帮助某个场景下的某类用户，更好地满足需求或满足更多的需求，这就带来了用户价值。

所以，一定要时刻关注新技术及其新应用，更重要的是去购买使用技术的产品，实打实的用钱给它投票。

五、最后

产品经理由于接收的信息众多，过滤商机非常重要。这里提供一种非常方便的商机判断方法，就是看场景化和用钱投票。

那些能把场景描述清楚的需求，和那些愿意给你订单承诺的需求，往往真实性更高。

做产品是产品经理必备的技能之一，那如何做出一款成功的产品呢？做产品时会遇到的问题有哪些？如何解决呢？让我们带着这些问题来看一看作者是如何分析的。

上篇文章我们聊完了产品经理的职业观，这篇文章，我们来聊了产品经理的产品观。

在开始之前，请大家自我拷问，有没有做过失败的产品，现在回想起来当时为什么会失败？

一、 成功多是偶然，失败多是必然

首先我自己做过很多失败的产品。

失败是我们不愿意看到的，但很多产品既然已经失败了，那我们就坦然接受这样的事实，深度去复盘总结，回头看看到底是哪一些地方出了问题。

很多失败的产品放到现在其实一眼就能看原因。而当时限于自己的认知水平，是没有意识到的。而且市面大多数失败的产品，在复盘的时候往往你觉得他其实是必然的。

那有没有一种方法保证我们做产品肯定能够成功了，很遗憾的说是没有。

那这是不是意味着我们做产品经理这个岗位就没有意义的呢？其实不是的。我们做产品这个岗位其实就是为了提高产品面世后的成功概率，将产品在调研、定位、立项、研发、推广过程中不应该犯的错误扼杀在萌芽状态。

下面我以我惨痛的失败的产品经历现身说法。先说下这个项目背景，2019年的时候智能音箱大火，我们也准备做一个这样的东西，经过市场分析我们定位要做一款儿童故事机，就是给儿童的智能音箱。最终结果就是老板定的年销量5万的任务，后来只卖了600台，大多还都是亲戚朋友买的。

现在我们来复盘下这个产品的失败。首先看到这个，我们提炼出的关键词是2个：1是智能语音，2是故事。如果这两个核心不成立，那么这个产品就不成立。

首先是智能语音。当时整个国内的这种语义识别技术还是普遍比较落后，大家应该还记得当时智能音响刚开始的时候大家都调侃它们为“人工智障”吧。

我们的产品也是如此，所以当你和它说话的时候它的回答总是词不达意，尤其面对语言水平本身就不成熟的孩子群体，这个产品的语音体验简直是灾难。但当时团队就觉得好像国内大家都是这个水平，我们做的只要比同行好一点就没啥问题。但现在回头看的时候，绝对不是这样的，用户只关注他用你这个产品时候的体验，既然叫智能，那么对话就必须要智能。

其次是故事内容。我们团队本身是不做内容的，所以就只接入了一些公共的免费资源，抱着侥幸的态度觉得这些免费的资源已经足够多了，不需要掏钱再接入些付费的内容资源，这就导致用户在使用过程中想听的一些东西都没有，如果恰好问了三个资源都没有，用户绝对会失去耐心。

现在想想，为什么有的内容要收费，有的内容要免费，就是因为那些内容是高频热门所以内容提供方才会收费，至于免费的内容大多就是一些比较陈旧的。

现在回头想一想，确实太傻了，不仅是因为在这两个重大的事情上判断错误，同时还把时间花在了很多细枝末节的地方把自己感动。

当时为了给产品调一个即看起来有档次，又能容易透光的颜色，我去工厂反复的调外壳原料不同成分的混合比例，前前后后有三个月的时间。

为了那个故事机的灯效做的更温馨一点，尝试了很多方案，前后又花了两个月的时间。不是这些细节不值得去打磨，而是有点舍本逐末，忘记了重点。

很多产品成功往往属于偶然，因为它有很多因素构成的，有发售的时间，大众当时对产品的一些接受程度，或者就一些爆款的事件把产品拉起来了。但大多数产品的失败是必然的，你回头去看，你一眼就能看到，它其实当时做了很多错误的决定。

二 、资源不足是常态

做产品我们避免不了的一个话题就是资源问题。不管是成熟的大公司还是初创公司，其实资源不足本就是常态，如果有了解过组织行为学的大家肯定知道，就办公室的政治其实就是来源于资源不足。所以不要再去抱怨资源不足了，我们产品经理就是在这种资源约束的条件下做出来优秀的产品。

这里分享两个方法来处理资源不足的问题：

• 第一种处理方式是硬处理。比如说你的产品可以规划两三个阶段，第一个阶段集中资源就去做一两个核心的功能，让产品跑起来，第二个阶段再在完善，第三个阶段去优化，有点类似我们常说的先做一个MVP。或者说通过一些产品的巧妙设计，让本来应该比较复杂的产品变得简单。我记得我以前看过一个产品经理做聊天室的方案，他是怎样巧妙做的？其实聊天室不就是你说一句，我看了再说一句吗。后来他就做了一个类似留言的功能，在比较短的时间内自动刷新一次，然后再把界面改的看起来像一个实时聊天软件的界面。
• 第二种处理方式就是软处理。就是刚刚说的办公司政治，说政治有点严重了，就其实你平时多注意下和同事们的的关系，有意识在关键资源人那边做做功课，倒不用特意做什么大动作，就是交单的时候多聊两句，朋友圈点赞后评论两句，类似这样的渗透到平时的工作中。

所以资源不足一定是常态，不要去抱怨，我们能做的就是去解决问题。

聊完了资源，我们来讲讲权威和数据。

三 、不迷信数据 不迷信权威

先看数据，在现在这种互联网信息发达的情况下，很多人产品经理做出判断的时候，就是依靠一些数据调研报告去直接下结论。这个灯要摆在右边还是左边？它去做一个ab测试，看哪一个点击率高，那就是按照这种方法去做。

这个产品要有什么最重要的功能？发一个问卷，大家投票，投票最高的就先去做。这种方式好不好呢？好，也不好。好的一点是其实他也是一种调研用户的方式，他给出的数据是有一定的参考价值的，但不好的一点是容易陷入数据误区。

幸存者偏差，我想这个经典的例子大家都知道，就是飞机中弹的例子。是二战的时候，美军统计飞回来的残疾飞机中弹的部位，发动机的弹孔最少，机翼的弹孔最多。很多人工程师就觉得应该加固机，但其实我们是多考虑一下，应该加固的是发动机，因为发动机坏了更多的是它就没有就回来。

张小龙甚至更极端的说了一句话，数据产品经理就是个笑话。

所以在面对数据时候，我们要考虑三个问题：

1. 数据的准确性
2. 样本数量的完全性
3. 样本类型的完全性

数据的准确性，可以通过交叉验证的方法来处理。样本数量的完全性，就需要我们样本数量要到达一定的量级。样本类型的完全性，就需要我们的样本覆盖目标客户的各类人群。

同样对于权威也应该是这样的态度。最近几年有一个很流行的观点叫第一性原理，他是将你处理一个事情，应该从他最根本的本源去出发。其中实践第一性原理最知名的人当属大家熟悉的马斯克了。

马斯克造火箭前，大家都觉得火箭太贵，而且技术难度太大，是国家级选手才能玩的东西。但火箭的成本真的那么贵嘛？机身成本高，老马直接用不锈钢，汽车制造工艺繁琐且成本高，Model Y直接上一体压铸结构件。

老马之前如果有人说要用不锈钢做火箭机身，要用一体压铸件制造汽车，可能会被别人看做有精神病，但往往一些划时代的产品就在打破了传统的权威和思维定式。

小米在做他们第一款全面屏手机的，所有人都觉得不可能，但团队里的年轻人觉得这样的产品才够酷，雷总当时说不计成本，不考虑量产，就去研发这样的产品。

我们知道小米全面屏手机出来前，其实小米业绩一度陷入危机，而且手机行业内基本下行的企业都很难起死回生了，但16年他们团队真的把全面屏手机做出来了，足够酷，足够牛逼，下坠的小米一下子就涅槃重生了。

说完了大的案例，我讲一个我亲历的小案例。在安防行业里面，海康威视绝对的是龙头的统治地位，他们做的很多产品是我们后来企业的标准。

我们当时做安防摄像头在决定机器尾线长度应该是多少的时候，也直接参考了他们的标准，从内到外总长40cm。但产品上市后，很多线下的客户反馈这个长度是不够的。

如果你是产品经理，你的第一反应是什么？是不是“人家行业老大这么多年了都是这个长度，我们这么做肯定没问题，一定是客户他使用的不正确。” 可作为产品经理的我就去实际场景看了，为什么用户会提出这个问题，确实在线下渠道用户装机的时候，如果有拐角同时需要把尾线放到防水盒的时候，这个长度确实是不够的。

后来我经过去实际的考量，最终得出了70cm是一个比较合适的长度，后来我们整个系列产品的尾线长度就改成了70cm，从此之后再也没有客户说过我们的尾线长度不够。

所以对于权威的这件事情应该树立一个这样的态度：他是一个标准，可以用来参考，更是一个机会，可以用来打破。有本书叫《创新者的窘境》，里面讲了为什么一些大的非连续性创新总是在小公司诞生了，那是因为小公司没有前面的思维定式，更容易做突破。

在权威的面前，我们谨记鲁迅说的：从来如此，便是对吗？鲁迅真的说过这句话。

四 、不惧怕冲突

最后一点关于产品观想要分享给大家的是，不要惧怕冲突。如果你打算在职场中当一个好好先生，那产品经理这个岗位其实不太适合你，产品经理要带有些偏执甚至固执的，要树立只对用户和产品负责的态度，不在关键点上妥协。

今天的好好先生换不来明天产品的成功，只会造成社会资源的浪费和对团队的不负责。但请注意，我们说的偏执不是为了证明自己而固执己见，不是我要证明我自己所以我坚持，而是这个事情是对的，所以我要坚持，因为坚持起了冲突，但我不惧怕冲突。

聊完了产品观，下一期我们聊聊产品经理最绕不开的词语：需求。

硬件产品经理一般负责产品的整个流程管理，本篇文章介绍硬件产品经理的四个工作流程：产品规划、立项研发、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。

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

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

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