当前银行信用卡业务的同质化现象严重，如何拓展新用户、促进新用户转化、深挖存量客户价值、提高客户质量，对零售业务的稳定发展至关重要。以大数据分析和人工智能为支撑，构建一套网络化、标准化、精细化、智能化的互联网客户运营平台，是信用卡业务的发展关键。
我参与某公司营销平台产品的设计和建设工作。这里面有很多产品坑和复杂人际关系，我觉得挺有价值的，于是我写一篇与你分享！
01、洞察需求
1、识别干系人。
在收集需求之前，有个非常重要的环节是——识别产品的干系人和明确干系人对产品的期望。
为什么要识别干系人？这至少有三个非常重要的作用：
一、确保收集需求的全面性，避免在产品开发甚至上线阶段，由于关键干系人的反对影响产品上线。
二、在需求排期阶段，干系人的关注程度是需求排期的重要参考项。
三、在产品从开发到上线阶段，可以通过关键干系人的认可，获取推进项目过程中必要的资源。
以营销平台为例，相关干系人主要包含以下三方：
第一、业务方。
主要指前端营销部门，如市场部、产品部、直销部门、线下营销团队等。由于平台的建设主要用于支持业务开展，业务方对平台一般都是积极且正向的，但有时也会有负面影响，如业务由于市场或领导压力，不得不逼迫平台快速上线某项功能，如果不符合平台定位或平台建设规划，在没有充分考虑的情况下匆忙上线，容易导致平台大量私搭乱建，边界模糊、功能冗余且复用性低，平台负担越来越重将不可避免走向消亡。
怎么应对呢？
平台方要对平台定位、功能有明确的规划和清晰的实现路径，不能被业务方牵着鼻子走。当然，在规划过程中也要考虑一些“后门”，用来支持紧急活动的上线。
第二、技术方。
主要指的是技术部门领导，他们能够从技术角度对平台建设提出建设性意见，并协调需求、运维等各个不同团队的力量支持平台的建设。
但有时候也会出现一些负面的影响，如技术部门往往希望摆脱业务支持部门的角色，希望能够引领业务发展，在这个过程中，就会提出各种各样的概念和思路。如何理解领导的思路，并转化到平台建设上是很大的挑战。比如为了汇报重新做一个大而全的超级模块，上线周期可能就直接从一个月上升到半年，业务也就不了了之了。
怎么办呢？
第一，要善于包装，便于汇报；第二，功能设计上尽可能合理清晰，方便领导理解，最重要的一点就是，要学会与领导沟通，取得领导的理解和做必要的妥协。
第三、上下游系统。
如短信平台、语音外呼平台、APP等，这些是平级的系统并不存在上下级关系，在技术领导的管理协调下，能够很好地进行协作，但有时候也会出现一些利益无法协调的情况。
比如边界情况，双方都能做的情况下，为什么对方要支持你？很多事情做了之后，都由你汇报，支持系统一点都没有机会抛头露面，那也容易让对方产生多一事不如少一事的想法。
怎么办呢？
对于这类问题可以通过第三方团队进行协调，如需求团队、架构团队等，当然，作为牵头方，需要学会利益分享，让上下游系统也有机会获得好处，这也是产品经理软实力的考验。
2、收集需求
需求收集的方法主要有：文档收集、深入访谈、头脑风暴等，建议根据实际需要灵活组合。
通过需求文档收集需求成本最低，可以先通过文档法集中收集一批需求，结合平台特点，让需求方按照规范填写必要的信息，如需求场景、需求描述、需求原因、验收标准、重要程度、期望上线日期等等。
通过将收集到的需求文档归类，复杂的需求可以通过找需求方进行深入访谈，深入了解需求背景，部分需求涉及相关方较多的，可以进行头脑风暴，通过集中讨论的方式推进需求收集。
我提炼出来收集需求的三个重要原则：
第一、倾听原则。
要善于倾听需求方的需求，让需求方完整表达自己的需求，如果用户表达得不够清晰，可以适度引导，但不能带入太多主观想法影响需求方表达。
举个例子，为了提升客户体验，作为一个营销平台需要考虑避免对客户过度打扰，在沟通过程中，项目组为了达到客户触达渠道的全面控制，设计了包括APP弹屏、微信推送、支付宝等各个渠道的触达控制，但事实上，业务的诉求更多的是对主动触达类渠道的控制，以APP为代表的自助服务是用户发起行为，不需要过于严格。而正是过度设计，导致功能过于复杂，考虑因素过多，影响了项目的快速迭代。
第二、接近原则。
有效收集需求的重要原则就是要接近需求方，从对方角度考虑问题，比较好的方法就是在沟通前了解对方的KPI和负责的业务环节，这样在沟通时才能更好地理解对方的立场和处境。
举个例子，负责某项小额贷款产品的市场经理希望快速上线一个智能外呼的功能，通过实时将客户信息推送到外呼平台，通过语音的形式触达客户。这个场景平台之前没有接触过，而且上下游链路比较复杂。
同时，这是一个非常典型的场景，很可能其他产品也会使用这个模式进行营销，在没有考虑充分的情况下匆忙上线，会影响后续功能扩展，因此，项目团队决定充分调研各业务场景需求，着手设计通用解决方案，同时，与该需求方深入探讨，对方的目的是希望通过这种新形式达成当月业绩指标，于是项目组通过新增客群，通过微信和APP两个渠道加大推送量进行支持，帮助该业务完成指标，为项目组争取了时间。
第三、目的原则。
针对线下深入访谈和集中头脑风暴，必须带有明确的目的，不能聊到哪算哪，沟通前可以先进行文档梳理，讨论必须有明确的目的性，攻克重点问题，会后要有相应的记录跟踪。
比如有些失败的会议经常发生相关方会前对会议内容不了解，会上花费大量时间交待背景，会上想到的问题点很发散，会议时间一延再延。
当我们在发现这些问题后，项目组后续在开类似会议的时候，先把相关背景、紧急程度，项目组的思路、期望上下游系统支持的工作、时间点都通过邮件的方式发给相关方，并要求相关方在会前必须反馈相关信息，在会前就确定会议的主要内容和参与的人员，比如寻求大方向的一致，能拍板的领导必须到场，如寻求的是落实的细节，则执行人员必须参会。
02、合理定位
通过洞察需求环节收集大量需求，明确了各干系人对平台的期望，在这个环节，最重要的就是要明确平台的定位，平台的定位决定了平台的方向、边界和优先级，是需求收集、项目开发、上线验收、持续迭代各个环节的评估标准， 可以说定位是建设一个平台最核心的因素。
经过梳理，我对营销平台的定位就是：用来支持业务做客户经营活动，本质是大数据营销决策中心，利用大数据海量数据和强大的算力，为前台业务提供有力支撑。
基于营销平台的定位，我梳理了业务对平台的核心诉求：
1）基础诉求：
a）要能上线活动，这是营销平台最基本的诉求，经过需求梳理，要实现上线活动的功能，我梳理三大核心环节：
数据源：支持接入实时/离线数据，支持数据源的拆分或合并（拆分指将一个数据源拆分成多个数据源，如一个客群拆成多个细分客群，合并则相反）；
策略：支持低门槛灵活配置活动策略；
渠道：支持通过文件、接口等多种方式与下游系统进行对接。
b）稳定准确，简单来说，就是能做到稳定不出错、出错有预警、预警能定位、定位能解决，针对不同场景建设完整的应急预案。
2) 高阶诉求：
数据驱动，事前能洞察问题，事后能高效复盘，这涉及指标体系、ABtest等功能。
要能够支持各种各样的活动，如APP弹屏、个性化推荐、二次经营、达标活动等各种各样的方式，需要在主干功能的基础上进行扩展，丰富主干流程的功能但不能打乱主干流程。
操作便捷，主要遵循两个原则：1.主干流程要清晰，2.能用技术解决的问题就不要增加业务负担。
03、高效迭代
1、以业务价值而非功能点交付
开发过程的重要原则，交付的内容必须能快速让业务使用，产生业务价值，这样做有两个好处：
第一、实际的业务价值是支撑产品向前发展的重要推动力；
第二、快速交付价值快速验证，灵活调整，支持高效迭代。
营销平台一期上线功能非常简单，就是对接离线客群，配置策略，以文件的形式产出给短信平台发短信，业务流程简单，但是解决了业务的痛点，能够自动化每天产出名单进行营销活动，这是手工作业阶段无法实现的。随着平台的扩展，要对每个阶段的重点和交付方向有清晰的规划，以下是我对平台做规划的部分截图。
2、收集反馈意见
每个阶段产品交付后，要尽快收集用户的反馈，可以是定量效果也可以是定性的结论，准确衡量是否满足达到了预期的效果。除了需求方满足之外，平台方也要搭建客观的衡量指标：
如营销平台最核心的衡量标准就是，业务的使用量，可以通过每天运行的策略数来评估，笔者经常问自己的几个问题是：
有没有覆盖公司最核心的业务？还能不能多覆盖一些新的场景？
是否实现了原本无法实现的新玩法？新玩法是通过什么方式支持实现的？
上线一个活动的周期是否更短了？用户咨询的频率是否更低了？
业务的效果有没有提升？是否有足够的增量价值？
平台的稳定性怎么样？近期是否出现造成了公司声誉或财务损失？
04、我的思考
在平台建设过程中我遇到很多困难，主要分享两点思考：
1、要有主见，但也要知进退。
比如对于一个企业核心平台，相关方众多，几乎不可能将个人意志凌驾在最高处。很多同事就会出现两种选择，要么坚持己见，不同意我就是没水平，此处不留爷自有留爷处；要么随波逐流，完全沦为执行工具，领导或业务说什么，就是什么，只要做出来就行，至于平台长期规划和发展的方向完全不考虑。
我曾一度在两种心态间摇摆，经过长时间迭代和复盘，我觉得更合理的做法应该是对平台有清晰的主见，勇于表达，但如果事情还在发展过程之中，难以快速分辨对错，一时存在争议，完全可以让子弹飞一会，多观察多思考，结果会慢慢自然呈现，如果时间证明你是对的，那是你的加分项，若相反，更可以审视自身的问题。
2、要多思考，但不要想太多。
在平台发展的过程中，有一个很大的挑战就是在做任何一个功能时，究竟应该是做成通用的功能还是定制化开发。通用功能的好处是扩展性好，覆盖场景更丰富，缺点就是前期规划阶段考虑因素众多，落地较慢；定制化开发的好处是快速上线，实现价值，缺点缺乏整体规划，容易埋在细碎的需求中无法自拔，平台功能混乱。
经过实践，我觉得要多思考，但不要想太多。对平台主干流程和功能有清晰的认知，不同场景的覆盖面和每项功能的投产比要有基本的判断，每次在考虑功能的时候，可以多想，但也不能没有边界，如果投入 60% 的力气可以覆盖 70% 的场景，决不能投入 20% 的力气满足 10% 的场景，当然也没必要投入 90% 的力气覆盖 80% 的场景，凡事过犹不及。
写在最后
产品是需要持续打磨的，过程很辛苦，既是打造产品，也是打造产品经理自己，持之以恒的付出，相信终有回报。
