tob项目是做什么，tob的项目为什么做不大

来源：网络浏览：81 2022-11-10 04:33:01

编辑指南：产品经理在进行产品规划时，需要考虑很多方面。在客户层面，产品经理必须洞察客户的真正需求，解决客户的核心问题；而在团队层面，产品经理考虑如何调整员工分配，降低项目开发成本，降低插件总结一下作者的经验，可能会对你有所启发。

说到产品计划，一般有行业调查、顾客需求分析、竞争对手的判断、产品价值本身等惯用手段。先发散再聚焦……

说起来有道理，但做起来并不轻松。现在改变情况，上前线做项目的时候，面对客户不断的诉求时，该怎么办？

此时，你不仅是产品经理，也是项目的核心成员，你该如何权衡两者之间的关系呢？

事实上，制作to B产品的团队大部分都不足以沉淀和复制价值方案，往往缺乏紧跟客户需求进行项目，打磨和沉淀高质量的产品。

结果愈演愈烈，在项目过程中不仅焦点不对准，还移动到了其他队伍的蛋糕上。产品界限不明确，客户方案也频繁修改。这样下去，信用卡行业的KA顾客就不用说了。

众所周知，任何业务的发展都有一个过程，面对不同层次的客户也有不同的战略。你的心需要秤。一边是你的产品和业务，一边是你提供服务的顾客。仔细衡量一下现在的业务和顾客的轻重，是看不到那个项目，还是势均力敌？

确实，初期的业务是求生存，在做标杆的阶段，往往需要更多的投入来确保项目的成功，提供客户全方位的贴身服务，一切都是以顾客的声誉为目标的；随着产品和方案的逐步稳定和完善，服务和管理体系的逐步标准化和成熟，从引进和实施合作伙伴(对于私有化产品)、集成和交付、定制开发、运输服务运营，以及从集成产品到产品集成，发展更加健康的业务结构

尽管如此，在真正深耕一个客户项目时，如何权衡客户诉求的合理性，最大限度地实现完整功能的闭环，并且能否将项目上的成果复制到其他项目中以达到更多的成果，是所有的产品经理

一、利他：要固定客户需求场景的本质，首先要明确概念。什么是客户的需求？

不管你的产品处于什么样的发展阶段，一旦它开始拥有提供自己服务的客户群，一定会伴随着客户的呼声。不得不承认的是，顾客使用得很好，很大概率不会告诉你；但是，客户抱怨你是不好的。不管反馈路线多么曲折，我总是能听到。你聋了也能听到。

一旦我们收到客户的需求，就无法时刻有意识地了解它在客户方面的作用，了解需求的紧急程度、预计交货时间等，进一步探索需求本身。

首先，请理解客户的需求是以什么为目的的。是解决客户业务上的什么痛点，还是对客户业务进行创新？

要解决业务问题，您可以了解客户当前面临的问题、在没有引入新方案之前是如何解决的、现有方案有什么不足，以及可以从哪个维度进行改进。

特别是在行业内卷的时代，伤害是非常隐秘的。如果发现不了，解决不了，只会卷入无限需求的漩涡，爬行就没什么胜算。

解决什么问题？为什么必须解决？影响面有多少？不用解决吗？以前是怎么做的？其他企业怎么样了？缺什么？这些问题中最想解决的是哪一点？前面的方案中最不能忍受的是哪一点？如果是为了业务革新，你的关注点完全不同。

客户几年前做过创新业务吗？效果怎么样？有用吗？其他供客户学习和参考的企业对这些基准企业的哪些业务感兴趣？客户决策者本人的诉求，对事业有追求，是否希望做出成绩，尽快做出成绩？只有弄清楚整理顾客需求的目的是业务上的痛点，还是业务上的创新，我们才能有目的地分解需求。应该切断的需求不要手下留情。应该玩游戏的人与顾客协商，应该接受的人有组织地评价产品方案，客观地权衡新方案与传统方案的区别和优势，可以进一步感动顾客。

例如，以前我在某个大型政府项目中创造了轻量级的任务监管系统。该产品具有很强的业务属性，但不仅仅是为了取代政府内部现有的监管体系。因此，初期花了很多时间与顾客进行调查。

据了解，在目前的方案中，客户端所有的监督工作都是在纸质文件盖章批准后，逐层转移，定期由各部门负责人逐一确认任务进度，制作监督工作表，过程中耗费大量人力物力，精力不够，不满意，无法完成

因此，我们在设计产品时，从任务的创建(数据源可能是客户自己的审计监管系统，也可能是自己创建任务)、任务的处理(包括多人协同处理)、任务进度反馈、结算等全过程进行组织甚至在第一个版本中挖掘需求场景时，考虑到政府内部的实际办公室场景，许多任务被委托给各办公室的领导，领导将子任务分发给相应的处理者。

因此，我们还花了很多时间根据任务派生相关任务，思考不同角色对不同任务文档的权限。根据各自的权限，看看任务监督能否整合现有平台的能力。例如，迅速唤起选择组件、启动群聊、一键启动会议、所有任务流进程可以迅速通知任务相关人员等。

我们信心满满，我们斗志昂扬，随后选择了一个好日子给客户提出了鉴定方案。客户的第一句话是“我想要的知事一览表是？

吃了苦头。

确实，你的任务监管系统做得很完美。你自觉对业务的全流程管理考虑周全，但没有解决客户最核心的痛点。那么，他用什么用你的产品？

回归初心，回归产品为客户提供的本质价值，到底这个产品是解决业务的痛点，还是想进行业务创新？

其次，要把握客户的需求场景，掌握一次，在这个场景的灵活区间中探索客户的底线，探索产品的底线。我知道了客户需求的目的。我们必须反复挖掘和分析基于该目的涵盖的客户场景是什么。

请记住，客户的需求不是一个人的抽象需求，而是特定场景下的需求。

我们常说，在设计功能之前了解客户的需求场景，本质上就是在说这个。

还是以上述任务监管的应用为例，客户最核心要解决的是“快速推导监管一览表”问题，基于这一目的，我们不得不思考一个命题。如何快速导出监管一览表？

这个命题包含几个要素。谁能引导数据？数据类型和范围是什么？怎样才能更敏捷地操作呢？

谁可以导出数据：涉及角色和权限项的设计；数据类型和范围：如何操作涉及数据源(与其他系统集成或自身系统的数据载体)、数据管理)、增删审核)、数据运营)、可视化分析)、数据安全审核等：导出了表单看，只有有针对性地分析客户场景，才能真正从需求场景出发。

整理好的场景越多，可投入产品开发的资源就越少。与其试图覆盖所有场景都推敲不出来，不如加深一个场景，小步快跑，继续迭代和优化。

当然，也有可能客户的需求没有被考虑得那么清楚。在需求的目的和需求场景尚不明确的情况下，如何提取需求呢？

请注意，即使客户不明确场景，也会创建场景。

创造场景就是给客户定义道路，给客户一个台阶，让他们自然地去踩。

例如，天猫淘宝7天无理由退货，之前是买家自己承担订单带来的不确定风险，2008年淘宝“消费者保障计划”进入第二阶段后，商户选择加入该服务后，商户

网购被称为“隔山打牛”，尤其是在满足消费者最底层需求的领域，“七天无理由退货”是给消费者戴上护身符，紧箍咒，“放心购买，结果我兜着走”

二、自私。项目的再生和项目的复制如上所述，即使考虑到客户最本质的诉求，你依然在贴近客户制造需求。改变项目再从头开始，这违背了我们的初衷。

在致力于项目的时候，我们在考虑如何更好地满足这位顾客的诉求。为此，分析该客户的需求，尽可能将客户诉求产品化。这没错，但是把这个项目拓展到所有项目的大盘子里来看这件事，投入产出比会低很多。

做项目的时候请夹杂私心，跳出来想想。那个项目结束后，我想你做的功能、设计的流程、battle的方案能复用到其他项目中吗？

在考虑文案之前，首先要学好播放项目。

这就像牵一张电影，一个学习小组分工合作，通过逐帧、逐剧解读、细致参观，全面掌握电影的内容、风格、技巧，系统分析一部电影。这是电影编剧学习的常用方法，但放在播放项目的场景中也是如此。

如果你正在建设一个项目，你可以组织一个项目的核心成员，养成在各自负责的模块中随时记录项目笔记的习惯，分阶段看，或者分成旁观者的角度看发生了什么。比如，你在不同阶段遇到了什么问题，提出了什么假设，与什么角色进行了什么探讨和切磋，最终为什么选择了这个方案而不是其他方案，之后打算怎么办，为什么……

为什么我要鼓励你记录这些过程中的客观事实和观点？

打开你播放的项目，找到了吗？项目的成果、产品的成功或失败、每个人的功劳和辛苦……这确实是可喜的，但这样的重生对其他项目没有什么帮助。对复印项目没有参考价值。

再生项目是为了恢复项目成功或失败的全过程，而不仅仅是结果感谢。这不是你能事后拍脑袋，问几个人整理的。这是“项目的一生”。我要成为传记作家。

就像专业画家临摹好画一样，只画轮廓什么也看不见。他应该看到的是构图、色彩、技法、步骤、情感表达方式等整体上大而小、非常具体琐碎的别人看不见或看不见的内容。

从团队，到个人所做的事情，一个决策的成败，都需要知道是什么原因。在很多情况下，即使是成功的项目，项目成员也往往不知道是如何成功的，之后，即使同一个人交付了类似的项目，要保持那个成功也很困难。

谈谈项目的复制吧。

老实说，这四个字本身就是假命题。没有两个完全相同的人，也没有两个完全相同的项目。所以与其说是复制项目，不如说是最大限度地站在上一个项目的肩膀上，尽可能地重用数据和服务。

只要注意这个，很多动作都会产生指向性。

1 )在你建设产品的过程中，你会有意增强产品功能的可扩展性。例如，提取界面开放性、通用公共组件，应用于不同产品在不同场合的能力补充。

在做项目之前，我很清楚产品之间集成的困难。通过项目的推进，至少在利益和意愿方面各方都有比较强的合作动力。那么下一个问题是：

针对本项目，如何区分不同的应用场景，更好更快集成某产品或平台，弥补产品能力，缩小与实际客户场景的gap；相对于其他项目，如何实现产品集成的过程清晰、顺畅，可以改项目也可以炮制，可以改集成商，不需要额外投入产品资源2 )在你逐步完成产品建设后，产品标准化也要开始准备。包括：

产品自身能力的标准化沉淀：哪些能力可以原子化、适合哪些场景、需要定制开发的文档标准化：为内部团队、客户和合作伙伴组织标准化文档，如销售支持、交付、运营、运输资料等。在后续其他项目中学习的弹药库流程标准化：项目涉及的合作伙伴、合作伙伴团队之间的合作机制和流程标准化，即使改变项目、更换合作伙伴，也可以采用相同的合作模式开展工作；项目模式标准化：建设团队，定机制，定规范。这三把斧子是每个项目都需要的，谁以什么样的机制、以什么样的标准规范来工作，是项目运作模式的基础，也是最重要的部分。当然，根据具体项目进行的所有再生和标准化沉淀，并不一定能有效地解决其他某个项目的问题。

不妨跳出一个具体项目，对核心攻坚的项目，做个全面的再生。

我强烈建议你在队伍里战斗。所有参与不同项目的同事一起拉平所有项目，整理最佳实践，按类型按纬度划分做法。哪些共性的部分可以在很多项目中重用，哪些个性的部分可以通过特别注意和规避风险，形成行业拓展的系统打法。

三、飞轮效应亚马逊CEO贝索斯反复强调一个商业理念：飞轮效应( Flywheel effect )，即：

一个公司的各个业务模块之间有机地互相推进，就像啮合的齿轮一样互相推进。一开始从静止到旋转需要比较大的力，但每转一圈的努力没有白费。旋转时，齿轮旋转得越来越快。

同样，在进行每个项目的过程中，一开始会有痛苦、痛苦。随着团队的建立、资源的预留、机制的明晰，每次后续的交付和验收，都会更加令人心潮澎湃。这些重要因素是什么，不仅是产品和研发，而且是整个项目团队共同的决策和执行。

王俊煜老师讲过一个比喻：

有时企业就像一部快速上升的电梯。电梯里有静静地站着的，有倒立着的，还有转圈的。直到最后电梯上了顶楼，每个人都认为自己的所作所为，才是让这部电梯上去的最重要的理由。

但我知道实际情况并非如此。

那么，产品经理在这个过程中能发挥多少力量呢？

小也可以。

你最好满腔热忱地拿走这张票，为顾客提供周到的贴身服务。但是，如果你能多加注意和私心，着眼于更长远的利益，在这个支点上创造更多的机会，何乐而不为？

#专栏作家#健康姐姐，微信公众号：健康姐姐( ID: is_strong )，每个人都是产品经理的专栏作家。腾讯高级产品经理专注于To B服务项目管理和行业分析，欢迎各路好汉一起探讨。