作为乙方的产品负责人，应该如何更合理地挖掘新版本需求，让客户接受这些功能范围，从而为后期的迭代申请更多资金、资源支持呢？本文针对定制化产品，对此进行了分析，一起来看一下吧。
临近年末，开始做下一年的产品规划了吗？本文分享了一些在客户定制化产品中，做新功能规划与挖掘时的流程和建议，希望我们都能做好挖掘和推进，更快实现客户的业务目标！
转眼又要到年底了，很多产品工作者都在着手进行下一年度产品规划，我也看到了一些相关文章，而今天重点总结分享的，主要针对于定制化产品（外包类、合同制合作模式）
作为乙方的产品负责人，应该如何更合理地挖掘新版本需求，如何让客户接受这些功能范围，从而为后期的迭代申请更多的资金、资源支持，让这个产品更好的达到客户预期，最终甲方好、用户好、乙方也好。
全文概览：
首先，我们主动推进的需求一定不是凭空来的，也不一定完全是基于业务场景，用户反馈而来的。或者说，我们梳理了100个功能点，具体下一期做哪些？怎么筛选？
所以在真正思考新需求，或者向客户介绍时，要先明确本产品的业务目标是什么。我们大多数新的功能一定要紧紧围绕客户想通过此产品优先达成的目标来讨论。
为什么要重点强调“优先”两个字。因为客户的业务目标可能很多，但是有些属于中远期目标，做长期规划可以，但在短期规划上，目标也要排一个优先级。
比如一期产品上线之后，二期的研发阶段正处于一期业务的推广阶段，那么也许二期的目标是如何更好地获客，让更多用户进来，优化核心业务场景和体验。而相较于平台精细化的数据分析、可视化报表等功能，可能优先级就要往后排了。
我们往往在向客户介绍新功能时，习惯性的站在自己的角度、乙方公司的角度，这显然是不正确的。
比如我们在客户B那里做了一个B功能，在客户C那里做了C功能，然后就“不假思索、顺其自然”的向A客户也推荐B、C功能。这种方式就缺少了对A客户业务目标的分析把握，除非BC功能很有吸引力同时贴合A客户的业务目标，否则这些功能最终被砍掉的几率是非常大的。
把握好业务目标后，我们所有的新需求都要围绕下一阶段的目标来制定。而在拆解业务、深挖功能的过程中，不能想到哪写到哪，东一榔头西一棒子，这样容易让新需求不成体系。
所以我们依然要通过体系化的思维来分类整理。
因为不同的产品、不同的一期建设范围，新需求的挖掘侧重点不同，本文仅分享几个通用方法，希望能帮助你更好的梳理。
1）场景化
通过业务场景自始而终梳理现有功能，感受哪里不顺畅、哪里有缺失、哪里可以更好一点，从而记入迭代需求池作为备选。
2）角色化
代入不同的角色视角（用户视角），站在不同类型用户的角度换位思考，如果我使用这个产品，我更希望能达到什么目的，我更希望自己的哪个痛点可以被解决。
3）模块化
一个产品可能会区分多个渠道、多个入口，同一个应用可能分为多个一级模块，按照产品现有的模块进行整理是我们常用的思路。同时结合场景化和角色化的方法，探讨是否要增加新的渠道、新的一级功能。
其实三种方式有相通之处，一个成熟的产品经理是可以做到多模式切换、混用，最终以模块化需求池、功能清单的形式对外展示，再进行筛选以及确认。
当然，场景化和角色化分析还有一个好处，就是提前通过这些切实的思考来权衡新功能的必要性、重要性。
因为我们最终产出的需求清单在和客户确认的过程中，势必会被问到“为什么要做这个功能”“这个功能是干什么的”“这个功能能解决什么问题”之类的疑问。
从业务场景和用户角色角度进行解答，更能增加说服力，让客户的接受度更高。
上面介绍的是自己“主动”挖掘需求的方式，对于已经上线的产品，也会有很多“被动”收集的需求。
这些需求要不要做，怎么做，会不会引申出新的业务问题或者系统改造难点，则是我们需要全面考量的。
我们其实也很清楚，不是用户提出的任何问题都要通过平台功能层面解决。对于各方反馈的需求，基于内容、通用性、影响力等方面进行梳理，区分重要、紧急、不重要、不紧急四个象限排列优先级，最终筛选出哪些内容可以放到新的需求范围中。
当然这里可能会遇到一个问题：用户的反馈属于一期遗留问题，还是二期新增需求？
这里要结合反馈内容的具体情况来分析，还要涉及到和客户沟通中的技巧，本文不做过多衍伸，后续会单独整理相关内容。
需要明确的一点是，同一个反馈作为一期遗留问题和二期新增需求，演变出来的改造点和具体方案，一定是有较大差异的。至于为什么，你猜猜看~
如果确认是二期新增需求，在形成功能方案时，需要深入辨别本次改造的严谨性，尤其是对于存量功能、存量用户的影响度。
对于已上线运行的定制化产品，我现在更偏向于“宁可不改，不能乱改；宁可曲线救国，也不伤筋动骨”。尤其是针对关键功能、关键数据。
毕竟生产问题无小事，我们要对生产环境、用户数据始终存有“敬畏之心”。不能因为测试环境、或者不规范的管理、或者长期的不重视而埋下一个个风险的种子。
当然，如果针对重要诉求，或者真正需要大修大补时，我们更需要拿出严谨的方案，并结合团队缜密的评估、测试之后再进行变更升级。
我记得几年前一位甲方的领导说过：没上线，再多的问题也是小问题；上线了，一个小问题也可能是大问题。（领悟精神、莫抠字眼）
所以如果我们筛选出需要做的反馈需求之后，对于影响较小的内容，可以在工作量允许的范围内尽量优化，对于风险较高的内容，则需要会同客户方的各个角色一起评估、商讨是否要纳入二期需求范围。
我们都有切身体会，有些功能听起来简单但真正做起来会很复杂。当然我们在作为产品人给自己的开发团队提需求时，也经常被吐槽这一点，现在只是角色换了。
在和客户商讨新需求之前，先要自己和技术同事一起把问题分析清楚，即便说改造起来很复杂，那么具体复杂在哪？为什么会造成这样的现象，这些真实原因要了然于胸。
然后再思考如何向客户汇报、解释这个问题，这里面又会牵扯到甲乙双方的信任关系，双方的认知和组织背景等等，也是一个讲究“艺术”的过程。其中可能会有很多你“单枪匹马”无法解决的问题，所以可以会同技术同事一起汇报。
我们一定不要向自己提需求时那样，也觉得这个需求简单，粗略的和客户“一拍即合”，最终把困难留给了自己的战友们。
产品的迭代从宏观上可以简单分为两部分：“更精”“更全”。
更精，则是要在核心功能上做的更有优势，如果现在处于业内领先地位，那下一步就要做到“绝对领先”，让用户体会到“惊喜感”和“爽点”，从而在产品推广阶段能够更快的占领市场、圈入用户。
因此在新需求商讨前，我们要明确自己产品的“拳头功能”是什么，现在还存在哪些优化空间，是否可以有“颠覆性”的创新。
作为产品人，当自己有幸涉及到这些内容时，我相信我们内心也会激情澎湃。带着这份感受向客户介绍时，把积极的情绪传染给客户，也能够提高对方的认可度。
更全，则是不断基于核心场景向外拓展业务边界，为用户提供更全面的服务。但这里又不能盲目扩展，新的场景也要和产品本质相结合，做到适度扩张，并守好自己的“产品边界”。
功能并不是越多越好，尤其是真正面向用户的产品，更多的功能代表着更多的学习成本，更复杂的配置过程，更容易产生“用户实际诉求和产品功能不贴合”的问题。
市场上有很多“大而全”的平台，要么不满足用户的实际应用，要么满足多种场景但针对具体用户使用时又需要复杂的配置，很难做到“开箱即用、即用即灵”的目标。
所以这也是我们在迭代自己的产品时，需要和团队，和客户持续探索，持续验证的重点内容。
当然，对于一些连接性较为紧密的新模块，尝试着向客户介绍，并且介绍重点聚焦在功能对于用户现阶段使用价值，以及业务目标更好达成上，从而尽力推进此需求的落地。
这两个问题都是圈定完范围后，进一步推进过程中经常遇到的问题，里面将涉及到商务、项目负责人、公司领导与客户方协调交流，每个公司、每个客户都有各自的行事作风，本文不再展开描述。
作为产品经理，或者现场的需求分析师，我们需要做的是做好客户沟通、功能介绍，讲明白功能的必要性，工作量的合理性。当然如果领导给予你更多的授权，那么后续推进的事，也可以更多的参与。
比如领导想主推A功能，客户那边没兴趣；客户想做B功能，领导出于其他考量不太想接。这些也都是经常遇到的问题。
这时我们需要主动和领导沟通，说明客户的实际想法以及我们后续的可调整空间，或者由领导给出新的挖掘思路。
也要切实站在双方的角度考虑为什么会存在这些矛盾点，是自己没介绍清楚，还是把功能想简单了？
总之不要只当一个传话筒，带着自己的理解平和沟通，并从中寻找双方可衔接的契机。当然了，最终可能更多的是乙方做出适应性调整，但调整的程度也不能一味被动适应。
当你自信满满的拿着100个功能点向客户介绍，结果讲一个不做、讲一个不做，最后被砍掉了一大半，这时怎么办？
首先不要气馁和自我怀疑，因为这种情况依然时有发生。可能是因为前期我们对客户的了解不足，也可能是功能的价值确实思考不够，不足以满足客户的下一步业务目标。这些自己身上出的问题，要自己认真分析总结，同样的坑避免下次还掉进去。
其次，客户选择的功能中，是否可以有深入的、可拓展的场景？或者在和客户沟通的过程中是否可以敏锐的捕捉到他对某个功能的渴求？而这个功能没有在这次的清单里，那我们可以加进去。
同时我们列了100个功能，但是脑子里不能只有这100个，起码需要有150个。当功能被砍了一部分之后，就要开始闲聊似的刻意引出另外50个，说不定会有意外惊喜呢。
虽然新需求的挖掘可能关乎项目组未来的发展情况，关乎团队的业绩指标，甚至关乎自己的“梦想和价值”，但是这些都应该反映在事前准备、分析等工作内容上。真正和客户介绍时，则要以松弛的心态“有理有据、娓娓道来”。
毕竟建立在一期成功的合作基础上，相互之间存在一定的认可度，更应该把气场调整的像“洽谈会”“讨论会”，各抒己见，灵活应变。
一旦自己在心态上出了问题，可能有价值的信息无法捕捉，也可能自己的感染力不足导致需求被砍严重，最终在最重要的环节出现漏洞，那才是真正的得不偿失。
当然，但凡涉及到类似的沟通，无论是售前、演示、需求评审，还是后续的需求挖掘、新需求确认，都需要我们“内紧外松”，松弛的状态也是建立在足够的准备、足够的信心，以及反复的历练才能达成的一种“进阶模式”。
以上，就是我针对定制化产品在二期、三期等新迭代时期，挖掘新需求的总结，希望能够对有缘读到这里的你，带来一点帮助~
任何一个新需求的推进，或者新需求的被拒，都不在于需求本身，而在于产品人对于客户的了解、业务的目标感知、场景的深入、用户的关注，以及在这些之前，一期产品建设过程中的很多细节、信任程度、客户关系、团队战斗力、人情世故等综合汇集的结果。
所以我一直坚信，好的产品经理一定是一个“艺术家”，掌握沟通艺术、聆听艺术、情绪调节艺术、谈判艺术、心理艺术等等多方面的“复杂共生体”。
我们不要仅仅看到现实的结果，更多的去思考产生的原因，才能从点滴中逐渐扭转形势，让自己逐步掌握主动，或者不至于那么被动。
最后，愿我们能够顺利推进新需求的挖掘和落地，愿我们负责的定制化产品尽快实现客户的目标。
专栏作家
不想延期，公众号：不想延期，人人都是产品经理专栏作家。半路转行的B端泛金融产品，坚持“以实践验证理论，以输出倒逼成长”的目标。点滴珍贵，重在积累
本文原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自 Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。