编辑导读：产品经理每天需要面对各种各样的需求，其中包括来自客户的定制需求。产品经理应该如何处理定制需求呢？本文将从四个方面进行分析，希望对你有帮助。

加完班滴滴回家，司机大哥一路和我聊人生。他说：“我是拆迁户，4套房子，500万存款，我有车有房，有自己的生意，自己当老板，要多自由有多自由，除了我爹谁也命令不了我。”

我说：“前面左拐。”

他说：“好的！”

一、翻车多了就成了老司机

如果把产品经理类比司机，那在开车的过程中最舒服的无疑是，自由自在地按自己制定的路线前往自己规划的目的地。经常开车的老司机就会发现，这几乎是不可能存在的。

一路上总免不了磕磕碰碰推车（MVP）、疲劳驾驶（996）、找不到车位（变现困难）、导航不准（内部掣肘）、绕远路（战略失误）、违章（政策监管）、堵车（竞品围剿）、故障（技术原因实现不了）、没油（迭代延期）、碰瓷（羊毛党、恶意举报）、车祸（服务器崩了、程序员删库跑路）……

说到这里，我突然觉得定制需求也没什么了。老司机去跑滴滴，就像接到了定制需求，被乘客指挥。自己沦为工具人，漂移能力再强也不过是帮助乘客快速到达目的地，或发现走错路完全由产品驱动，就像公交车司机，路线规划好，三年五载不会轻易改动，该走走该停停，开车过程中不能和司机说话。

大多数情况介于两者之间，就像乘客包了你这辆巴士，30人，从目的地A到B，星期天早8点到晚8点到了星期天，乘客们9点姗姗来迟，来了50个人说好的目的地B，又让你再往前开看看，七拐八拐走出好几千米。说好的晚上8点就回，9点半了还没见到人影，打电话也没人接，最后12点才到家。

同等级的（市内交通） 出租车/网约车和公交车，个性化体验和费用成正比；这就是大部分产品经理的写照。

惨一点的就像大巴司机，各种扯皮吃哑巴亏到处掣肘，付出和回报失衡可能是你的善良纵容了他们，可能是你的老板默许了他们。

再高级点，开火车、开高铁、开灰机技术门槛越高，越不会有乘客找司机提建议，教他做事。

再再高级点，太空旅行。

不管花了多少亿的大老板，绝逼老老实实呆着，不会告诉宇航员他觉得应该怎么摆弄飞船。

二、是不是

SAY NO是每一个社畜、每一个乙方的梦想。

某种程度上无论通过何种手段说服甲方放弃定制需求都会显得有能力。

所以大家不免陷入定势思维，只要是甲方提出的，功能清单并不覆盖的功能，就是定制需求，就要尽量拒绝，以暗示自己对于产品的规划面面俱到，专业形象和沟通能力让客户信服。

定势思维背后还有更深层次原因，公司制度不完善或者选择性忽略，使团队没有驱动力（项目奖金，OKR关联等）。

从两个角度来说：功能清单不覆盖的功能不一定是定制需求；企业不在乎你的个人能力，在乎的是通过你的能力为企业获得商业价值。

1. 疑似定制需求的两类情况

常见的2B产品面对客户：

通常是大客户：

• 选择更多：舔狗众多挑选舔的最好的
• 要求更高：嵌入/兼容企业自研内部系统，符合企业文化品牌调性
• 业务健全：触及到很多低频场景、长尾需求
• 组织复杂：涉及到更多协同办公、数据量庞大高并发
• ……

（与之类似的还有2G项目，其中当然存在差异，不再展开）

不易察觉的2C产品的异业合作：

因为供应链的话语权，合作意愿的强烈度的对比，也会使合作伙伴其实是甲方身份的情况。

常规的联合登录等联调、接入开放平台虽然是一次性开发，但是不会觉得是定制需求，因为这些情况天生就是项目制，而且不需要产品经理过多介入。

而相同的合作方式（如H5对接、收银台对接），面对不同的平台产生不同的要求时（小需求如隐藏品牌标识调整页面布局，大需求如全部接口对接），往往会觉得是定制需求。因为一开始是把多种对接方式作为可复用的产品逻辑的，而且有常规对接方式以外的要求时，需要产品经理重新沟通、规划。

因为这里的定制需求是为了满足合作方，所以也归类为2B。

2. 定制需求狭义上的定义

定制需求≈外包产品。

共同点：

• 从0到1
• 一次性开发，缺乏长期价值
• 做起来没有成就感

差异点：

• 定制需求范围可大可小，思考维度更偏离科学，容易抱有侥幸心理或在过程中发觉难度提升
• 定制需求有时不仅是从0到1，如果涉及到解耦，可能是从1到-1再到1，涉及到未解耦的部分要重新调整或通过临时方案过渡
• 定制需求有时要对线上运营情况负责，客户想的可能是这个版本就做好完全准备面对亿级流量的冲击

3. 根据不同颗粒度的描述，会影响该需求是否符合产品规划的判断

在需求澄清阶段，产品经理就免不了需要耗费精力调研、规划、输出Demo而不像内部的常规迭代，团队磨合出适合的沟通方式和颗粒度，越来越有效率在与2C合作方或是2B客户做需求澄清时，可能还会考虑品牌形象、体现重视等因素，在Demo上不可避免的投入饱和资源。PPT、高保真、前端开发介入、造演示数据…

4. 根据交付时间的要求，会影响该需求是否划分为定制需求的结论

即使这个需求符合产品规划，如果按照规划是明年才做，客户明天就要，这个需求也是定制需求因为明年和明天，内外环境无数的影响因素都会完全不一样。

明年和明天做同样的需求，几乎可以确定是两套完全不同的解决方案影响因素如：市场环境变化、业务流程进化、配合模块解耦的临时方案、中台完善程度、其他需求的优先级变化等。

三、做不做

“是不是”和“做不做”之间没有明确的界限。

当你要判断“是不是”、“做不做”的时候，已经开始做了。

其实这也很公平，不是所有付出都有回报。

像中介和猎头一样，如果最终没有签约，这次项目的直接商业价值就为0，但是这个过程中的收获，是会因人而异的。

1. 需求分析

需求分析已经有很多相关内容了，说点方法论之外比较真实的东西。

无论是定制需求还是日常的迭代工作，无论公司内部还是对外。

方法论只是方法论，产品经理的约束条件很多，做决策不能只依据方法论。

而且只是得出你的决策，不同的情况还需要找对应的业务干系人去PK。

在定制需求中更加明显，分析人心可能比分析逻辑还重要，逻辑没有人心复杂和不可控。

1）需求是由谁提出的？

这个人对最后的结论有多少话语权？

不满足这个需求合作还能不能进行下去？

客户方领导、客户方对接人、我方销售等角色，会导致你的老板和你用不同的重视程度去对待。

如果是客户老板提的你没有重视，他很可能直接和你的老板建立联系，到那个时候再争取相对科学的规划需求的几率更加渺茫。

虽然对用户一视同仁对任何反馈都要重视是一个政治正确的说法，但是在定制需求中，我们找的不是用户价值和商业价值的契合点，因为这个时候我们并不知道定制需求的用户价值，要更加考虑商业价值。

同时明确需求提出人，也是我们进行需求分析的必备事项。

面对着需求描述，抱着怀疑去验证。

这个人说的东西靠不靠谱？

需求传达过程中信息有没有失真或偏差？

有些销售因为公司背景或工作方式原因，在供需沟通中始终处于弱势，没办法把公司产品的价值展示给客户，只能靠无底线地满足客户来提升签约机会。

第一次这样做了，以后的合作只会更甚。

销售在意的是这个月、这一天的利益，管你什么中长期价值。

有时候可能是对方领导的一句闲谈，说者无意听者有心。

或者是客户对销售的一次试探。

一些本来无关痛痒的需求，“他想要”变成了非做不可的理由。

2）还原场景

上面也说了，定制需求通常指2B的场景。

2B产品，产品经理不能通过同理心或常识经验去判断，2B的场景是真实存在有章可循的。

最好可以找到业务流程中的全部角色进行沟通，争取最真实的还原场景。

这个理想化的调研流程可能会因为客户配合度不高、时间紧急、需求描述的逻辑合理、一些场景通过类比可以通过常识经验判断等情况缩短路径。

3）理解业务

使用需求分析的相关方法论，梳理出闭环的业务流程，流程中的各个场景、角色和对应的需求。

乙方判断做不做的节点：

核心依据：我们能否拿出解决方案（有很多人，只能看到白盒里的东西，以为线上做个功能就可以了）。

4）解决方案

除非是需要软件系统以外的技术方式和设备配合的方案，否则这个时候不需要考虑具体的交互。

重点考虑解决方案前后的差异，能否满足需求，哪些角色增加的工作量，是否有动力去执行，除了软件系统以外，还需要客户配合做哪些动作才能让解决方案实际产生效果。

甲方判断做不做的节点：

核心依据：甲方老板的判断、是否对解决方案满意、与其他乙方的解决方案对比。

2. 需求澄清

当一个新需求由客户提出时，产品经理是无法事先把控结论的，只能通过若干轮口头沟通、功能描述、Demo演示等使双方认知和结论达成一致。

还有一种更绝望的情况，客户还有客户，当前能接触到的人没人能拍板，只希望我们先做，然后拿去演示，再看反馈。

3. 需求输出

1）可以在演示Deadline之前完成的Demo方案

要提前确定一些细节，确定Demo演示中比较看重什么。

Demo里涵盖不了什么效果，提前周知。

很容易背锅，一些本来是产品经理质问别人的“做成这样也能给人看么？”，得到回复“先上先上”。

Demo交付时候产品经理就被质问“做成这样也能给人看么？”。

2）完整解决方案的需求描述

乙方判断做不做的节点。

核心依据：乙方老板的判断、需要哪些成本、能获得哪些收益。

工作量评估、排期、（报价）。

甲＆乙方判断做不做的节点：

核心依据：排期、（报价）是否达成一致。

4. Demo交付

根据不同情况，通常签约和这个阶段的工作是并行的，开发进度不会死卡合同审批节点。

会存在签约时间在Demo交付前或交付后。

甲方判断做不做的节点：

核心依据：对演示Demo是否满意or拿去投标、路演是否达到预期效果。

1）正式Deadline之前无尽的修改

根据需求范围，甲方会在项目的不同进度提出不同颗粒度的要求。

产品经理要验证甲方描述出来的内容是否合理。

如果不合理，拒绝需求或者给出合理的解决方案进行新一轮的沟通说服，逐渐消除信息差直到得出结论。

如果合理，要补充完善需求描述背后的逻辑和细节。

5. 如果可以发表意见，如何做(给)出相对科学的决策（建议）

虽然很有可能你一顿操作最后结果不尽人意，但是了解一些其中的逻辑，起码有利于调整心态。

不要因为事情的结果不理想，就理所应当地怀疑过程。

不要把这一次的不理想，当做下一次不尝试的借口。

以下的因素无法形成一个象限，也无法有一个if else的公式让你去套，用心感受。

1）客户属性：可交换价值

我们要付出什么？

• 人力成本
• 时间成本
• 机会成本
• ……

我们能得到什么？

• 品牌背书
• 商业回报
• 潜在机会
• ……

2）公司价值观：管理层认知

有些公司不琢磨怎么建立核心价值和竞争壁垒，把做大做强的希望寄托在一味地满足一个好不容易攀上关系的客户。即使根本没有合作契机，也要勉为其难地完成一个所谓的项目。为了能在官网加个Logo，为了到处吹逼。

有些公司濒临倒闭，好不容易抓住一个大客户，无论怎样先活下来最重要。

不要执着于说服老板，列出已知信息，说明利害关系，给出自己的结论和理由，让老板决策。

结论确定后，自上而下贯彻执行，履行职业义务。

3）公司发展情况＆产品生命周期

2B公司发展情况通常与产品生命周期成正比。

以SaaS产品为例：

有清晰的规划，可以更明确【客户属性：可交换价值】中的问题也有利于判断【组织架构】的规划

4）组织架构

很多企业强调学习华为的狼性文化，选择性地忽略华为给到的待遇和福利。企业间的职能细分程度不同，通常来说，职能划分更细，代表着公司发展情况更好、对业务的认知更清晰、每个人的工作内容更专注效率更高。

面对定制需求，想要达成理想效果的组织架构排序依次为成立专项小组>成立虚拟小组，制定项目奖励计划>给员工插活，增加工作量。

5）双方对接人的职业素养

能否形成良好的合作关系达到共赢的目的，在前期（判断做不做）主要取决于双方对接人的职业素养。这个要求并不会很高，能完整地明确地完成信息交换足矣。但是现在的奇葩太多了，有搞不定老板自己乱拍板的，有领会不了老板意图自己乱传达的，有get不到内容让你给做汇报PPT的，这些情况通常不会直接影响你老板判断“要不要做”。

但是需要你注意，降低以后扯皮的风险，在合作以后几乎100%会存在的情况，三番五次反复无常的新增需求＆需求变更，合同上的文字描述永远无法避免歧义以及不同人的不同理解。

在需求澄清和输出解决方案时，我们通常会计划达成这样一个闭环：

客户会反复提出在这个闭环间游走的需求，听起来确实有道理，也不容易通过合同内容、优先级、数据＆市场＆用户反馈等原因直接拒绝。

如果乘客坐你的顺风车，并且在你的规划路线和他的目的地最近的节点上识趣地下车，并且表示下次请你吃饭，这样的客户为他们做少量的新增＆变更我们也是心甘情愿的。

现实场景中通常是有职业操守的产品经理越做越伤心，那些不靠谱的产品经理和不靠谱的客户互相伤害。

我曾经遇到过一个产品视觉层面的需求叫“从美学角度调整到最佳状态”，我很伤心，因为我的愚钝。

（我是先敲的文字后找的这张图，她的话时隔数月我记得一字不差）

6）客户成本

我们给出的解决方案是否能覆盖客户需求覆盖不到的地方，客户是否有认知及对策乘客要去泰国，你只能把他送到灰机场。

四、怎么做

1. 建立标准对接流程

内部教育：

• 产品培训
• 操作手册
• 培训考核

售前资料：

• 产品介绍PPT
• 功能list
• Q＆A
• 演示环境＆标准数据

需求管理规范：

• 形成文字，减少歧义
• 区分【规划需求】和【定制需求】
• 产品经理是唯一需求（具体需求）来源
• 完整记录
• ……

两个强调的点：

1. 内部该撕就撕，提升无脑需求的提出门槛
2. 多用分支开发＆灰度发布

2. 养成规避风险习惯

保留证据：邮件、聊天记录、电话录音；形成文字可以帮助对方把思路梳理得更加清晰，减少歧义。

保留记录：特殊处理记录，方便追溯产品逻辑和定位bug。

3. 要不要做成通用配置

基于客户调研＆反馈：

基于产品架构：

这部分内容主要为技术驱动，下面的例子只是粗浅地做个类比。

当然前提是建立在要规划一个高拓展性的解耦的架构上：

• 个性化配置：主题色（按钮、特殊文本、选中样式）、图片（banner）、标题文本
• 流程配置：如钉钉自定义审批流程
• 表单配置：如问卷星自定义问卷
• 产品配置：如支付宝自定义首页应用
• 产品拓展：如微信公众号支持二次开发
• 数据开放：提供数据查询、建模能力

#专栏作家#

紫原新之助，公众号：小紫原产品手账，人人都是产品经理专栏作家。长期关注＆不定期输出互联网商业、产品、运营、增长思考＆实践。

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

题图来自Unsplash, 基于CCO协议。