To B｜做项目的无私与自私
提到产品规划，我们一般都会有惯用套路，比如从行业调研、客户需求分析、竞品摸底、产品价值本身等分别去切入，先发散再聚焦……说起来头头是道，做起来并不轻松。现在换个情境，当你深入到前线做项目时，面对客户源源不断的诉求时，怎么办？注意，此时你不仅是产品经理，你还是项目的核心成员，你该如何去权衡二者的关系？
事实上，做to B产品的团队，大部分在高价值方案的沉淀和复制上都做得不足，很多时候基本都是贴着客户需求做项目，缺少了打磨和沉淀优质产品。于是愈演愈烈，做项目的过程中不仅不够聚焦，甚至动到了其他团队的蛋糕，产品边界没划清，客户方案也频频返工，如此下去，更别提卡位行业KA客户了。
众所周知，任何业务发展都会经历一个过程，面对不同层级的客户也会有不同的策略，你心中要有一把秤，一边是你的产品和业务，一边是你服务的客户。仔细掂量下当下业务和客户的轻重，无法望其项背还是势均力敌？
诚然，早期业务需要求生存，在打标杆阶段，往往需要投入更多来确保项目成功，提供客户全方位的贴身服务，一切以客户口碑为目标；随着产品与方案逐步稳定和完善，服务与管理体系逐步标准和成熟，你可以尝试引入合作伙伴来完成部署实施（若是私有化产品）、集成与交付、定制开发、运营运维服务，再从集成产品过渡到产品被集成，去发展更健康的业务结构。
话虽如此，在真正深耕一个客户项目时，如何权衡客户诉求的合理性，再最大限度地实现完整功能的闭环，并且能做到将项目上的成果复制到其他项目里实现事半功倍，是每一位产品经理作为项目成员时要时刻思考和提升的地方。
1、无私的：锚定客户需求场景的本质
先明确一个概念：什么是客户需求？
无论你的产品处于什么样的发展阶段，一旦它开始有自己服务的客户群，必然伴随着客户的声音。不得不承认一点，客户用得好，大概率不会告诉你；但客户吐槽你不好，不管反馈渠道有多曲折，你总会听得见，甚至是振聋发聩。
而当我们接收到客户需求时，总会下意识去了解这是出自客户侧的什么角色，继而了解需求的紧急程度、预期交付时间等，缺乏对需求本身的进一步探索。
首先搞明白：客户提出的需求是出自什么目的？到底是要解决客户业务上的什么痛点呢，还是要给客户的业务做创新呢？
如果是为了解决业务痛点，不妨去了解客户当前遇到的问题，在没引入新方案之前怎么解决的，现有方案存在什么不足，还可以从哪些维度去改进。
尤其在行业内卷的时代，痛点变得非常隐秘，如果你发现不了，解决不了，那你只能一味地被卷进无穷无尽的需求漩涡里，爬出来的胜算不大。
a. 要解决什么问题？为什么非解决不可？影响面有多大？不解决可以吗?
b. 以前是怎么做的？别的企业是怎么做的？存在什么不足？
c. 这些问题里你最想解决的是哪一点？之前的方案你最无法忍受的是哪一点？
如果是为了搞业务创新，你的关注点就完全不同了。
a. 客户前几年有没有做过创新业务，效果怎么样，有没有用起来？
b. 客户有没有在学习和借鉴的其他企业，对这些标杆企业的哪些业务有兴趣？
c. 客户决策者本人的诉求，是否在事业上有追求，希望能出成绩、尽快出成绩？
理清客户提需求的目的，是业务痛点还是业务创新，我们才能有目的地去拆解需求：该砍的需求就不要手软，该博弈的就和客户磋商，该接受的就组织评估产品方案，再客观权衡新方案相比原有的方案的区别与优势，以此来进一步打动客户。
举个例子，之前我在一个大型政府项目里做过一套轻量的任务督办系统，该产品有强业务属性，但又不全是为了替换政府内现有的督办系统，于是初期我们花了不少时间和客户开展调研工作。经了解，现有方案里客户侧所有的督办任务均由纸质文件盖章审批后逐层流转，定期再由各单位负责人逐一核实任务进度，填报督办任务表，这中间耗费巨大的人力和精力，费力不讨好，数据的完整性和精确性也有待商榷。
于是我们在设计产品的时候，从任务的创建（数据来源可能是客户自身的督查督办系统，或是自行创建任务），任务的办理（包括多人的协同办理），任务的进展反馈、办结等全流程进行梳理，并针对不同版块划分不同的角色和权限。甚至在第一个版本挖掘需求场景时，考虑到在政府内实际办公场景下，不少任务都是委派给各办公室领导，再由领导分发子任务到对应的办理人。
于是我们又基于任务衍生了关联任务，并花了不少时间琢磨不同角色对于不同任务单据的权限，基于各自的权限去看是否能将任务督办集成现有的平台能力，比如快速唤起选人组件，一键发起群聊，一键拉起会议，所有任务流转的进程可快速通知到任务干系人，等等。
我们信心满满，我们斗志昂扬，然后挑了一个良辰吉日给客户鉴定方案，客户第一句话就是：我要的督办一览表呢？
傻眼了。
的确，你的任务督办系统做得挺完善，你自觉把业务的全流程管理考虑得无比周全，但你没解决客户最核心的痛点，那他凭什么来用你的产品？
回归初心，回归产品要提供给客户的本质价值，究竟这个产品是要解决业务痛点，还是想做业务创新？
其次，把握好客户的需求场景，并把握好一个度，在这个场景的弹性区间内去试探客户的底线，试探产品的底线。客户的需求目的搞明白了，基于该目的要覆盖的客户场景是什么，这一点必须反复去挖掘和分析。
记住，客户的需求，不是一个人的抽象需求，而是特定场景下的需求。
我们常说，设计功能之前搞明白客户的需求场景，本质上说的就是这一回事。
还是以上述的任务督办应用为例，客户最核心要解决的是“快速导出督办一览表”的问题，基于该目的倒逼我们思索一个命题：如何快速导出督办一览表？
这个命题里涉及到几个元素：谁能导数据？数据类型和范围是什么？如何操作起来更敏捷？
a. 谁能导出数据：涉及到角色和权限项的设计；
b. 数据类型和范围：涉及到数据来源（与其他系统的集成或是自身系统的数据承载）、数据管理（增删改查）、数据运营（可视化分析）、数据安全审计等；
c. 怎么操作：导出表格、开放api接口等都是可行的办法。
你看，基于目的出发再去分析客户场景，才算得上真正地从需求场景出发。
如果梳理出来的场景较多，能投入到产品研发的资源又少，与其试图去覆盖每一个场景，但又经不起推敲，还不如做深哪怕一个场景，小步快跑，持续迭代和优化。
当然，你还可能遇到一种情况，客户的需求并没有想得那么清楚，在没有明确需求目的和需求场景下，怎么去提炼需求呢？
请注意，即便客户没有明确场景，我们也要创造场景。
创造场景就是给客户定义一条路，给客户递上一个台阶，让他自然地踏上去。
比如电商平台上的7天无理由退换货，很久以前都是由买家自行承担订单带来的不确定风险，自从2008年某电商平台的“消费者保障计划”进入第二阶段，商户一旦选择加入这项服务后，由商户替你承担该风险，免去你的后顾之忧。
都说网络购物是“隔山打牛”，尤其是针对消费者最底层需求的领域，“7天无理由退换货”算是给消费者戴上了护身符，给卖家套上了紧箍咒，创造一个“你放心购买，后果由我兜底”的场景，完成用户价值的创造。
2、自私的：项目复盘与项目复制
前文提到，即便你考虑到客户最本质的诉求，但你依然是在贴着客户做需求，换个项目还要从头再来，这跟我们的初衷背道而驰，不是吗？
当你融入一个项目时，你考虑的是怎么更快更好地满足这单客户的诉求，为此你会分析这个客户的需求，尽可能将客户诉求产品化。这都没错，但摊平该项目到所有的项目大盘里，你再来看这件事，投入产出比就相当低了。
我始终认为，做项目的时候你要夹带私心，跳出来想一想，该项目结束后，你做过的功能、设计过的流程、battle过的方案，是否可以复用到其他项目？
在考虑复制之前，首先要学会复盘项目。
这就好比拉片子，一个学习小组分工合作，逐格、逐句地解读电影和电视剧，通过细致地观摩，全面掌握片中的内容、风格与技巧，系统地分析一部影片。虽说这是影视编剧学习的常用方法，但放在复盘项目的情景下也同样适用。
如果你正处于项目的建设过程中，不妨组织项目核心成员在各自负责的模块里养成随时记录项目笔记的习惯，分阶段去审视，甚至是分化出旁观者的视角去审视发生的事情，比如你在不同阶段下遇到了什么问题，提出了什么假设，与哪些角色进行了什么样的探讨或切磋，最终为什么选定了这个方案而不是其他方案，后续还打算怎么做，原因是什么……
为什么我鼓励你记录这些过程性的客观事实和观点？
翻开你复盘过的项目，发现了没？是不是说尽项目的成果，产品的成功或失败，每个人的功劳与苦劳……这的确是可喜可贺，但这样的复盘对其他项目帮助不大，无法对复制项目提供参考价值。
复盘项目是为了还原项目成功或失败的全过程，而不仅是摆结果邀功鸣谢。这并不是你事后一拍脑袋，问几个人就能整理出来的，这可是“项目的一生”，你要成为它的传记编写者。
如同一个专业画家临摹一幅好画，如果仅仅描绘出轮廓就等于什么也没看到。他应该看到的是构图、色彩、技法、步骤、情感表达方式等大到整体、小到非常具体而琐碎的别人不屑看或看不出来的内容。
你要知道，大到团队、小到个人做的某件事、某个决策的成与败，原因究竟是什么。很多时候哪怕是成功的项目，项目成员也经常不知道究竟是怎么成功的，于是在之后即便是同一拨人交付相似的项目，做起来还是很吃力，甚至很难保持这种成功。
再来说项目复制。
实话说，这四个字本身就是个伪命题。不存在两个完全相同的人，也不会存在两个完全相同的项目。所以与其说是复制项目，不如说是最大限度地站在前个项目的肩膀上，尽可能地重复利用数据和服务。
只要你留心到这一点，很多动作就更有指向性了。
（1）在你建设产品的过程中，你会刻意加强产品功能的延展性，比如接口的开放性，提炼通用的公共组件，适用于不同产品在不同场景下的能力补充。
我在做项目之前，一直都清楚跨产品集成的难度，通过项目的驱动，至少在利益和意愿上各方有相对更强的合作动力。那么接下来的问题就是：
a. 针对本项目，如何区分不同的应用场景更好更快地集成某个产品或平台，补齐产品能力，缩小与实际客户场景的gap；
b. 针对其他项目，如何做到产品集成的流程是清晰的、流畅的，换个项目也能如法炮制，换个集成商也能胜任，你无需额外再去投产品资源。
（2）在你阶段性完成产品建设后，产品标准化也要开始筹备起来，包括：
a. 产品本身能力的标准化沉淀：哪些能力可以原子化，适用于什么场景，是否需要定制开发？
b. 文档标准化：面向内部团队、面向客户和合作伙伴的标准化文档的梳理，比如助销、交付、运营、运维资料等，都会成为后续其他项目学习的弹药库；
c. 流程标准化：项目中涉及到的合作伙伴、合作团队之间的配合机制和流程的标准化，换个项目，换个合作伙伴也可以按照同样的合作模式去开展工作；
d. 项目模式标准化：建团队、定机制、定规范，这三板斧无论在哪个项目里都需要，什么人在什么机制下以什么标准规范去做事，这是项目运作模式的根基，也是最关键的部分。
当然，基于具体项目所做的所有复盘和标准化沉淀，都不一定能有效地解决其他某个项目的问题。
不妨试着跳出某个具体项目，针对核心攻坚的项目，全面做一次复盘。我非常建议团队作战，所有参与过不同项目的同事一起摊平所有项目，整理出最佳实践，分类型分纬度分打法；再来看有哪些共性的部分，可以复用到大多数的项目里，哪些个性的部分，是尤其要注意和规避风险的，以此来形成行业拓展的系统打法。
3、飞轮效应
亚马逊CEO贝佐斯反复强调过一个商业理念：飞轮效应（Flywheel effect)，即：一个公司的各个业务模块之间，会有机地相互推动，就像咬合的齿轮一样互相带动。一开始从静止到转动需要花比较大的力气，但每一圈的努力都不会白费，一旦转动起来，齿轮就会转得越来越快。
同样的，在你做每个项目的过程中，一开始你会痛苦、难受，随着团队建立、资源到位、机制明确下来之后，之后的每一次交付和验收都会更加胸有成竹。非要说这其中的关键要素是什么，绝对不仅是产品或研发能决定的，而是整个项目团队共同的决策与执行。
王俊煜老师打过一个比方，
有时候企业就像一个飞速上升的电梯。电梯里有人静静地站着、有人在倒立、有人在不停地跑圈，最后等电梯上到最高层的时候，每个人都认为自己做的事，才是让这个电梯上来的最重要的原因。
但实际上我们都清楚不是这样的。
那你说，产品经理在这过程中究竟能发挥多大的力量？
可大可小。
你满腔热血拿下这一票，给客户提供周到的贴身服务是很好；但如果你多一分留心和私心，放眼到更长远的利益上，凭借这个支点也能撬起更多的机会，何乐而不为？