百木园
刘润在一篇文章中提到过一个观点，“好产品不是能力内核，做好产品的流程才是”。我很认同这个观点，本文主要分享我对做“好产品”的流程当前的一些认知。
全文共8个部分，总字数超过1万，限于篇幅可能有些内容谈的还不够深入，后续有时间会再做细化。这8个部分是：
一、建立需求池和需求反馈渠道
需求池管理是B端产品进化最重要的环节，它的重要性远超产品设计、开发等其他环节。
维护需求池有主动和被动两种。
主动维护是产品经理在参与售前、迭代、交付、售后、竞品分析、老板沟通等活动时自己发掘、记录需求，主动收集需求的渠道很多，但不同渠道收集到的需求质量有差异。
通常而言，我认为重要度最高的是售后环节，因为此时反馈的需求通常是让客户真正痛的地方；
其次是竞品分析，友商决策并实现的能力通常意味着有真实的客户和需求存在；
再次是售前和交付，这些环节有时候客户期望过高，容易空想不一定真实存在的需求，要慎重接纳；
最后是迭代时开发团队想出来的需求或老板提出的概念性需求，这些需求的真实存在性相对更低。
当然，很多时候，从职业本身的角度，老板需求是重要度“最高”的需求。但一个对产品负责的产品经理，应该通过发问挖掘需求，帮老板“想清楚”，或让老板把自己“说明白”，最终找到真实需求或引导降低优先级。判断需求收集渠道重要度的原则是需求真实性概率，而需求真实性是指需求存在且有普遍性。
被动维护是建立起需求反馈渠道让相关角色(售前、交付、客户经理、客户响应中心等)可以“有效的提需求”。它包括两方面：
业务需求结构化，除了产品、客户、金额、姓名、时间等基本属性之外，更重要的是对需求场景的挖掘。关于需求挖掘，我给售前、交付等职能提供过一个5W3H分析法，具体包括：
- who，谁提的这个需求？最终影响的用户角色是谁？
- why，客户该需求的业务背景是什么？由于什么原因产生了这个需求？
- when，发生了什么事，造成了什么问题，所以有了这个需求？这个需求未实现时，客户是怎么解决这个需求的？过程中有什么痛点（不方便的地方）？
- what，初始需求提出人的原始需求描述是什么？主业务过程什么样？业务过程有哪些异常场景？
- where，如何有了这个功能，客户会在什么场景（什么时候、什么条件）下使用这个功能？功能使用频率有多高？
- how，客户期望产品在哪里做什么功能？功能长什么样？为什么期望功能或交互做成这样？友商是如何实现这个需求的？
- how much，这个需求对客户的业务价值是什么？实现后用户可以得到什么好处？
- how much，这个需求对在该行业或其他行业客户是否需要？是不是个性化需求？
产品经理应该把需求池维护作为自己最重要的工作，需求池决定了产品未来的方向。接到需求第一时间需要将原始需求记录至需求池，定期对需求池中需求进行状态更新。
二、建立走进客户现场机制
在办公室埋头做设计交互的B端产品经理是不合格的，脱离客户现场做不好B端产品。设计交互对B端产品并不是最重要的，更重要的是业务目的、业务过程、使用场景、角色群体和替代解决方案等。
通过非直接用户、客户反馈的需求，通常会有信息过滤。产品经理要走到客户现场，感受用户的情绪，倾听用户的怒骂或赞赏，对自己的产品有客观的认知。倾听用户对功能的使用场景，把这些场景包装成故事讲给其他客户，给客户“懂我”的信任感。还可以验证需求池中的需求，倾听用户对规划中需求的期待和反馈，为后续优先级规划和产品设计做准备。做好B端产品不是跟随友商，而是跟随客户。
但产品经理的时间、精力是有限的，若出差客户现场包含往返在途至少半周，每月也只能安排1～2个客户拜访。所以，拜访客户的选择尤为重要。
选择拜访的客户，应该是“天使客户”。这些客户的大概画像是：属于产品主打行业，处于行业头部地位；已购买且交付产品，在深度使用，愿意每年支付服务费用滚动续签；客户接口人懂业务，对产品有想法，有逻辑、讲道理。当然，很多时候客户不是我们能选择的，只能尽可能选择和产品目标客户相似度高的客户。
售前阶段的客户并不是适合产品经理拜访的客户，一方面此阶段的需求不一定是真实场景下产生的，存在过高期望或主观臆想；另一方面如果客户提了一堆需求，产品到底响应还是不响应，什么时候响应都是难题。但售前阶段的招标文件，产品经理可以作为重要需求收集渠道，有可能会发现影响产品新定位的需求。
“以客户为中心，关注场景和痛点”，不应该只是口号，或依赖每个产品经理自己的主动性，应该建立起机制和制度进行保障，让产品经理不要脱离客户现场做产品。
三、建立需求接纳机制
从多种渠道收集到的需求，并非所有都应该纳入到产品规划中的，毕竟开发人力总是稀缺的。明确需求接纳决策人，建立决策依据原则对B端产品至关重要。
承担需求接纳决策人角色的人，至少应该满足两个要求：
需求决策人通常是产品经理，也可能是业务负责人。如果需求决策的权力，由脱离客户一线，不对市场业绩负责，缺乏产品管理经验的人负责，对产品会是一场灾难。
需求接纳原则，至少应该考虑3个问题，值不值做、该不该做、要不要做。
需求是否接纳通常由产品经理一个人决策，但这会过度依赖产品经理自身能力。建议应该成立需求评审委员会，周期性对产品组合中各个产品经理的决策依据进行评审。
需求评审委员会的成员应该包括产品总监、售前解决方案总监、售后客服总监、研发总监等角色，至少产品总监和售前解决方案总监需要参与。需求是否接纳影响产品组合中各个产品未来进化方向，值得管理者参与决策过程。该会议无需对具体功能方案做沟通，只需要决策需求是否接纳即可。
在需求接纳管理的过程中，可能总存在一些人发出反对的声音。每次产品经理决策需求或设计方案时他总能找到反对的理由，但如果你让他来提该做什么、怎么做，他又提不出有价值的想法，反问一句“这是产品经理的事，你是产品经理还是我是产品经理”。
我们要知道，每一个决策都有利弊，我们只要追求当下能做出的最佳决策即可。如果因为惧怕决策风险，就停滞下来不做决策，做无意义的时间消耗，这才是最大的损失。对于有价值的声音需要接纳，对于没价值的反对，只能练就一颗强大的内心。微笑面对反对和质疑，坚持自己的选择，并能在失败后平静面对他们的嘲笑。
但行前路，无愧于心，足矣。
四、建立优先级决策原则
研发人力和时间总是稀缺的，需求优先级排序直接影响着市场业绩和客户满意度，做好优先级排序对产品非常重要。如果需求收集和接纳决策是对产品经理能力第一重要的考验，那需求优先级决策则是对产品经理能力第二重要的考验。
需求优先级排序的方法论很多，但回归本质是ROI和对比排序。对比排序，即使没有方法论也能做，但有方法论可以让排序有据可依，标准相对清楚，更容易同其他人达成一致。
不同商业模式、不同产品、不同阶段衡量ROI的标准不同，要根据自身产品选择适合的一套或多套组合衡量方法，不要迷信特定理论。
比如，对于内部系统或大客户定制项目，收益主要是关键角色的满意度，其次是次要角色使用价值，更多使用提出人权力/影响矩阵做优先级排序；对于处于0-1打造阶段的产品，收益主要是MVP版本交付与反馈，更多使用KANO或MoSCoW做优先级排序；对于处于1-n阶段的商业B端产品，收益主要是短/长期市场收入，更多使用效益/紧急矩阵做优先级排序。
对于1-n的商业B端产品，我推荐效益/紧急矩阵优先级排序法。既然是商业产品，那就向钱看。效益高且紧急的需求优先级最高，效益高不紧急的需求其次，效益低紧急的需求再次，最后考虑效益低不紧急的需求。看似简单，但如何定义效益呢？
效益是短期、长期经济收益的综合评估，短期经济收益好评估，承诺或完成某个功能就能让正在售前的客户愿意付钱购买。但长期经济收益呢？在没看到项目机会前，是否能绝对预测做了某个功能一定能够带来多少客户、多少收入增长？这个很难，因为决定收入的因素很多。但可以确定的是功能解决的场景价值越大，则产品综合价值越高，特定客户购买概率也更高。
那如何评估场景价值大小呢？一种参考方法是大概估测，没有这个功能时，客户想达到业务目的需要投入多少人、多长时间，这些人需要的薪资是多少，这个事每年做几次，最后大概能评估一个年度货币成本数量级即可。
这个评估不需要精确的数值，这种数值也没有意义，可以拍脑袋估测，只需要能跟需求池中其他需求有个大致对比即可。做这个估测的意义不在于准确，核心是需要产品经理建立起关注需求背后业务价值的意识，而不是关注在功能设计本身。
通常来讲，处于售前关键时刻（客户已完成预算申请且内部立项，正处于确定招标参数阶段）的大金额项目是经济效益最高的，毕竟“百鸟在林，不如一鸟在手”；其次是涉及客户多、业务价值高的普适需求。
对于经济效益在相似量级的需求，可以引入成本作为第二优先级排序考虑因素。成本越低，相对优先级越高。
需求优先级并不意味着绝对的开发迭代顺序，在开发迭代排期时我们还需要兼顾每个开发周期内大小需求的均衡性、市场响应及时性等。可能有些小需求经济效益不高，但成本极低，此时考虑到市场响应和客户满意度，也可以将这些小需求排入靠前的开发迭代。
对于经济效益高但难度大、成本高的需求，不能因为难就一直拖延着不做，我们需要勇于啃硬骨头，在具体推进时可以把这类需求穿插在多个迭代中硬啃，做难而正确的事，我们才能拉开与竞争对手的差距。
五、建立产品设计标准
一个优秀的B端产品除了功能，更应该靠场景打动客户。B端产品设计不能狭义的理解为单纯的功能交互设计，而应该围绕客户业务问题、场景来综合考虑，我们的终极目的不只是做一个漂亮的界面、好用的交互，更是帮助客户解决当前存在的问题。
根据经验，我将产品设计划分为：业务背景澄清、业务过程梳理，流程与角色设计、角色任务设计、功能设计，架构设计、交互设计，平面设计，视觉设计等一系列过程，这个划分方法借鉴了《用户体验五要素》中战略层、范围层、结构层、框架层、表现层的思路。
这些设计过程只是一种知识体系化的拆解维度，划分并不精确，各个过程未完全遵循MECE原则，没有严格的先后顺序。在实际设计过程中，我们可以有意识的注意这些过程，针对具体场景来裁剪使用。以下将对每个过程简略描述：
1. 业务背景澄清
将需求收集时5W3H问题和答案再确认一遍，回顾一下我们核心要解决的问题是什么，业务目的是什么，价值是什么。
2. 业务过程梳理
将客户线下解决问题的方案搞清楚，都涉及哪些角色，每个角色做什么，角色间如何协作，业务涉及多少个环节，每个环节具体做什么。我们要介入这个过程应该从哪些地方介入合适，哪些地方不适合软件介入，软件介入比原有方案增加了多少价值。
3. 流程与角色设计
流程与角色设计是基于原有业务过程，考虑转化到软件上该如何做，每个角色需要设计哪些任务。在设计时我们可能需要打破、调整原有业务过程，以线上更合适的方式来做。
4. 角色任务设计
是基于单个角色设计他的主任务、次任务，该角色在业务中的目的是什么，主任务需要几个步骤，是否可简化步骤，每个步骤具体做什么。
完成主任务涉及多少个核心页面、多少个关键功能，如何保障主任务过程顺畅。分支任务有哪些，如何即能让分支任务为主任务提供便利，又能避免分支任务干扰主任务，分支任务应该有哪些入口，如何即易找又不喧宾夺主。任务过程中可能有哪些异常，哪些应该软件来避免，哪些应该交给用户自己判断避免。
角色任务设计完成，需要什么页面、什么功能基本已经确定了。
5. 功能设计
是确定每个功能实现逻辑、方法，功能设计要基于业务问题和场景，如何设计能带来最大的收益，再衡量如何降低成本获取最大ROI，这个过程中可能功能设计需要做一些妥协，但仍需保障功能的价值度，这个平衡并不容易做到。
另外一个很难平衡的问题是，“追求更完美的方案再开发，还是先有一个简单方案再持续迭代”。首先，我倾向于持续迭代。在实际使用中不断反馈和迭代，要比一直憋方案，迟迟功能推不出来更好。
而且，我们很难预知能设计出一个完美方案，也很难预知我们认为的完美会被客户认可。对于创新型功能设计，有改进、有价值即可，不过度设计、够用即可。
但同时，又需要平衡最低设计标准，不要让产品掉档次，让客户感觉草率、粗糙。起码应该达到让产品经理自己愿意承认，这个设计是出自我手的程度。否则，产品经理就应该有所坚持，不能因老板或大项目压力而妥协，要尽可能在有限时间内追求更好的方案，对自己的产品负责。我们不是为了做功能而做功能，最起码应该保障功能在场景中能解决问题，否则绝不将就。
功能设计推荐4个原则，按重要性排序是，有用、好用、灵活、简单：
功能设计完成后，产品经理的核心工作基本完成。UI/UE设计是专业领域，专业的事情应该交给专业的人做，产品经理更多是配合UX设计师。但公司如果没有专职的UX设计师，则需要产品经理主导设计。
不建议产品经理拍脑袋创新，最好直接向那些有UX设计师的友商“借鉴”（抄袭）。如果友商做的也不好，可以向一些优秀作品学习，如腾讯系的产品，但抄的过程中也需要有自己的选择和判断标准，不行无脑全抄。B端产品最重要的是功能设计之前战略层、范围层的事，产品经理若花过多时间在框架层、表现层则有些本末倒置。
6. 架构设计
是确定不同功能具体在哪个页面，以及用户完成任务需要按顺序使用哪些页面，各页面之间如何跳转。常见手段如：面包屑导航、高级搜索、首页快捷入口、列表或详情页超链接、弹窗、抽屉、返回等。
跳转设计时要结合任务场景来设计，比如，在运维管理的资源设备添加时，如果添加成功应该自动跳转至列表页，因为用户的主任务已经完成，下一个主任务是再新增一个资源或者使用其他功能菜单，所以要自动跳转至列表页；
而如果资源添加失败，则应该停留在本页面，因为大概率是由于账号密码错误造成连接测试失败，这个场景下用户会走入账号密码修改的分支任务，而该分支任务就是在详情页完成，所以不能让用户跳转至列表页，而是留在当前页面增加用户修改的便利性。
7. 交互设计
广义上讲包括了架构、交互、平面、视觉等，狭隘上讲是一组触发点、触发动作和动作反馈，包括控件选择、控件交互及用户操作联动等。控件不建议自己开发，直接采用开源控件库，如element、iview、antd等，这些控件大多数情况下够用了，但也有些需求场景下这些控件无法满足，有人力可以二次开发或新设计。
即使采用标准开源控件，仍需产品经理参与设计。产品经理需要根据需求场景选择最适合的控件、确定控件默认值、确定控件之间的联动逻辑、设计用户视觉及鼠标键盘操作动作、路径等。
交互设计推荐3个原则，少想、少看、少动：
简化设计推荐4个原则，删除、组织、隐藏、转移：
平面设计推荐4个原则，亲密、对齐、对比、重复：
视觉设计需要审美，我的直男审美相对差一些，所以更多追求简单、简洁，在配色、比例、钝锐角、线条、对称、平衡等因素上较多依赖于借鉴（抄袭）优秀友商作品。
最后，在产品设计上我想强调的是，设计只是解决问题的手段而已，最核心的还是理解并解决业务问题。
六、建立产研协作保障
通常情况下，产品经理和研发归属同一个大部门，办公距离相近，迭代过程中有问题可以及时沟通解决，产品经理只需要保持正常的节奏参与迭代规划会、迭代验收会等即可。产研利益一致，协作高效，沟通基本不会出现问题。
但在有些大公司，产品经理和研发可能跨了大事业部，位置也可能分布在不同城市，产品经理的核心工作是市场商业，极难保证跟研发沟通的时间。这种情况下，会出现很多问题，想把产品做好很难。
比如，因组织架构原因，产研利益不一致，产品经理推动力不足；产品经理跟研发沟通时间较少，关系融洽度较难维持，相互信任度低，容易产生嫌隙；迭代中研发有问题很难随时跟产品经理确认，问题被拖延影响开发效率等。
我的应对思路是：
- 惧怕冲突，坚守产品规划不退缩；
- 工作公开透明，把事情摆到桌面上；
- 借助多个相关方力量，共同影响研发接纳需求；
- 多方位影响高层管理者注意到问题，为产品经理争取时间；
- 至少保证迭代计划会、演示会和研发团队有交流；
- 尽量保障定期线上会议帮研发解答疑问。
产研沟通存在障碍不可怕，可怕的是接纳这种状态不做改变。做好产品我们要保障产品经理和研发利益一致、沟通顺畅，让产品经理对产品规划有主导权，有充足的时间完成需求分析、及时解答研发疑问。
七、建立产品验证机制
产品设计不能闭门造车，为避免功能不被客户认可，要频繁验证。尤其B端产品，上线一个功能容易，但下线一个功能很难，需要在很长一段时间承受压力（客户质疑售前时有的功能，为何交付时没有了，这种情况处理很棘手）。
客户定制或内部自研产品需求方明确，相对容易验证。但标准化商业产品的需求方来自多行业、不同规模客户，相对验证困难。
对于客户定制或内部自研产品可以秉持”最低成本验证“的原则验证功能设计是否满足客户需求，必须完成的验证包括：业务背景确认（会议）、核心业务流程确认（Visio）、核心功能确认（Xmind）。
若需求较大，验证手段按成本从小至大包括：纸面线框图、低保真原型、需求概要说明书、高保真原型、需求详细设计说明书。需求验证的交付物并没有实际价值，所以应该根据客户和场景尽量选择成本最低的方式。
对于标准化商业产品我没很好的方法，目前的思路包括：
- 借助PPT跟售前、客户经理等团队做概念宣讲，验证需求普遍性及价值度；
- 借助重大项目售前/售后交流机会做概念宣讲，验证需求期望度；
- 借助交付中典型行业客户，对功能设计方案进行验证；
- 借助公司内部交付专家，对功能交互/UI设计方案进行验证；
- 由产品经理/测试人员把自己想象成小白用户，模拟用户完整业务过程使用体验。
在我管理的产品组合中，有几个需求推动很久了却一直未被研发接纳，但今年通过重大项目完成了一举多得。这些项目金额达到数百万级，售前申请了产线产品经理直接参与。
在跟大客户沟通过程中，我提及了几个功能设计理念（未承诺，以规划中引导），很切中他们的实际痛点，在会议上客户大加赞赏，直言“你们的产品是我看过的所有国内外产品中，做的最好的”。最终，我们既完成了需求验证，又拿下了多个数百万级项目，还成功让研发接纳了需求，提升了产品未来竞争力，一举多得。
当然，标准化商业产品的功能验证并不容易，有很多要考虑的因素，比如：客户过度期望风险、功能交付时间风险、技术方案风险、通用度不足风险等，但我们不能因为有风险就停下脚步，产品经理要有敢承担风险的魄力。
八、建立产品场景案例库
项目成交的关键是客户对产品的认可和信任，产品功能是重要因素。但单纯的功能介绍不易让客户感受到产品的价值以及我们和竞争对手的差异性，所以，我们需要借助客户实际工作的场景故事，让客户更容易感受到价值和我们在领域内的专业性。
通常来讲，优秀的解决方案专家应该对产品特定功能使用场景和价值很清楚，产品案例库也应该由售前解决方案团队来维护。但若解决方案岗位由于各种原因出现缺位，如负责多个产品线精力不足、人员流动率高、工作经验不足等，产品经理需要在这个关键之处做补位，反向培训解决方案专家。
帮助客户发现产品功能更多的使用场景，也是产品经理需要关注的事。因为增加功能的目的是增加产品价值，发掘原有功能更多使用场景也能帮助客户增加产品价值。从场景中来，到场景中去。
坦白讲在产品场景库建设上我目前做的并不好，曾经推动体系化的做行业场景案例库，只输出了一篇，后续由于相关角色配合度不高，自己做又缺少时间，就搁置了。
不过，在特定行业解决方案PPT输出时，我有意识的采用了以场景为线索组织结构，跟客户交流时效果很好，我认为这种模式对今年几个数百万级大项目中标有很大的正面效果。
我组织场景有两个思路：
第一个思路是从用户的实际工作角度出发，拆分多个场景，然后把产品组合中各个产品的功能打散进每个场景中，告诉客户在不同的工作领域中，我能帮你解决什么问题，我是如何解决的。比如：
在讲整体网络自动化解决方案中，我拆分了设备入网、服务请求实施、日常监控与管理、故障响应4类大场景，然后每个大场景再具体细化拆分成4个具体小场景，然后每个小场景采用几页PPT详细介绍我的产品功能是如何在这些场景中发挥作用的。
在单独的IP地址管理解决方案中，我按IP管理全生命周期拆分了IP规划、IP收集、IP展示查询、IP分配、IP审计、IP回收6大场景，然后针对每个场景分析客户现状最大的3个问题，提出针对性的3个解决思路，然后每个解决思路用几页PPT详细介绍我的产品功能是如何一步步使用来解决这些问题的。
这样按场景来组织的解决方案，会给客户“懂我”的信任感。同时，也通过在场景中的功能演示，增强了客户对产品实际落地的信心。
第二个思路是从产品功能角度出发，挖掘功能可以响应的特定场景。
比如，对于IP地址管理查询列表页，我会跟客户讲的场景是，“在交换机故障或报废下线时，需要确定该交换机影响的具体业务或IP，此时，可以通过该设备IP可以直接查询到所有接入IP，大幅减少了人工确认工作量”，“在对一个IP地址做故障分析或安全回溯时，通过IP地址可以快速查询到这个IP是通过哪个交换机、哪个端口入网的，具体使用人是谁、用途是什么、近期有哪些安全告警等信息，辅助快速定位故障、审计使用记录”。
你看，仅仅一个列表页，就可以讲出很多使用场景。
另外，一些高价值场景比如，“投入上百万建设CMDB，但仍不敢保证IP不遗漏，此时，可以通过IP地址管理的CMDB校验能力，帮助发现CMDB中缺失的IP地址”；
“安全准入系统只能管已经安装了客户端的终端，但真正的非安全终端没有安装客户端难以发现，此时，可以通过IP地址管理对终端准入系统中IP进行校验，辅助发现那些安全威胁”；
“网络中IP冲突可能会造成关键业务断网，此时，可以通过IP地址管理做IP分配集中归口，减少IP冲突风险出现”；
“每年要做业务扩容时，哪些业务需要新采设备很多时候靠人拍脑袋，此时，可以通过IP地址管理自动查询各业务设备接口使用率情况，通过数据很快就可以确定具体扩容业务和设备量”。
类似场景故事还有很多，正是这些贴合客户业务的真实场景，会让客户更有体感，也更容易体会到产品的价值。
最后，我想说，一个优秀的产品经理非常重要。在业务上，他可以给客户创造很大价值，给公司带来长期收益；在产研协同上，他可以帮助研发少走很多弯路，大幅提升研发产出效率。
但是，好的产品经理可遇不可求，从公司角度需要有一套机制来保障产品经理不至于做的太差，才能保障公司正常发展。正如亚马逊贝佐斯所说，“仰仗别人的善意来完成工作不是长远之计，公司的运作需要依靠完善的机制”。
作者：李晓杰；微信公众号：产品晓说（ID：pmxiaosi）。10年以上产品、项目管理实战经验，近7年服务大B端客户运营商（移动、联通），核心产品为企业信息化与协同，包括研发管理、财务管理、办公自动化OA、数据可视化等。喜欢读书、分享，希望与同路人共同探索产品经理成长之路。
本文由 @产品晓说 原创发布于人人都是产品经理，未经作者许可，禁止转载。
题图来自Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
来源：https://www.woshipm.com/operate/5663764.html
本站部分图文来源于网络，如有侵权请联系删除。