吴晓波的《大败局》介绍了许多著名企业在“花样年华”的日子里突然灰飞烟灭的故事。创业九死一生，我们往往看到成功者并总结成功的经验。但成功并不一定能复制，而失败却能为我们提前预示很多坑。本文从这本书中获得灵感，描写了我在火花中遇到的一些小失败，并附上自己的反思。我将反思总结成了一个Learnings List，希望能帮助自己和朋友在未来规避类似的问题，减少试错成本。
备注1：什么是“失败”是我个人的主观判断，并不一定是项目彻底失败了，它有可能做得更好，也有可能是惨胜。
备注2：Learnings也是我自己的思考，可能片面，可能不全，欢迎评论补充。
备注3：站在现在看过去，毕竟有事后诸葛的成分，所以并不是说当时的参与者或决策者做的不好。
0 Learnings List
- 如何选择发力点
- 增长能解决大部分问题，在资源有限的时候，优先要做增长。
- 人特容易选择处理表面问题让自己忙碌起来，而没有触及到根因。
- 做事情前先搞清楚这件事会影响多少人，盘子有多大，天花板有多高。
- 做事情要选择timing，想清楚当前的主要矛盾是什么，这件事情是否能解决主要矛盾。
- 有舍才有得
- 想清楚一件事情我们是要追求100分，还是80分，还是60分。
- 创新业务为了跑得快，就要简化流程
- 产品设计
- 怀有敬畏之心去学习友商。
- 听到一个结论后，要批判性地去看是否适合自己。
- 在方案确认后，要列出实现模型和心理模型之间的差异。
- 这些差异就是方案需要妥协的部分，其中有部分差异可能是无法接受的。
- 所有C端产品都需要考虑多端适配。
- 考虑到SOP的变化是常态，应该尽量将SOP的工单进行配置化落地，比较初级的是内容的配置，比较高级的是流程、触发条件、关闭条件的配置。
- 做看板类、数据类产品的时候，写清楚数据延迟多久，写清楚口径。
- 做工单、自动消息类的功能，要考虑总量、频次、并发值。
- 做工单类功能，开启条件、自动关闭条件、手动关闭条件等，逻辑要完备。
- 在选项中，尽量不要有【其他】，除非是当你没想明白选项，需要发散收集信息的时候。
- 闭环
- 运营活动类，需要明确项目成员的职责，并达成一致，并确定谁作为大Owner为最终的结果负责。
- 产品上线后要去看数，要拆开了看，能发现问题。
项目1：System Automatic Messages to Users
项目概述
Vispark US项目在2022年9月初收到内外部用户反馈称系统的通知邮件和消息内容不够专业。为了解决这个问题，项目团队梳理了所有发送给用户的内容，包括通过短信、邮件、语音电话、App Push等多种渠道发送的内容。这些内容按照登录注册、试听课、支付、教务、学情、供应链、转介绍和服务这八个模块分类，共梳理出80条系统自动发送的消息。与US、SEA和海华三个业务团队协调，明确了发送的触发节点和内容，并协调翻译团队明确了详细的陈述文案。
为什么说它是失败的
在不恰当的时间点做了当时不关键的事情，一个创新业务遭遇了成熟业务才有的流程冗余病。
- 过程及其痛苦：VISPARK消息通知涉及北美、新加坡、海外华人几个业务部门，每一条消息内容的确认都需要经过不同业务部门内多个角色的确认，之后还要走翻译团队，哪怕是native speaker产出的内容也需要过翻译团队。
- 收益不明确：改好了，然后呢？提升了新签单量还是提升了留存率还是降低了退费率？
- 反复拉抽屉：话术是仁者见仁智者见智的，A产出一版，给到B后，B想改改，给到C后，他又会有一些建议。
Learnings
- 在资源有限的情况下，增长能够解决大部分问题，所以要多做增长。
- 在做事情之前，要思考现在是否是好的时间点，想清楚当前的主要矛盾是什么，然后判断该事情是否能解决主要矛盾。
- 在做事情之前，要想清楚自己的目标分数是100分、80分还是60分。
- 为了做到快速发展，新业务需要简化流程。
- 不同业务中类似的功能需要做到战略层、范围层、结构层和框架层的复用，表现层要解耦，多做配置化，以节约成本。
- 话术和展示都是属于偏表面、主观性的问题。因为很多人都喜欢从这些入手，这些地方虽然正确但并不重要。
如果再来一次
- 降低项目的范围、预期、优先级，只解决明显有问题的话术问题。
- 坚持要求产研团队做不同业务团队间话术的配置化功能。
项目2：时间展示的时区信息混乱问题
项目描述
系统内有许多地方需要展示时间信息，例如：
CRM内的沟通时间、注册时间、课程开课时间和订单支付时间；
官网用户自助订阅时，需要展示课程档期的时间；
此外，还有一些时间信息是隐式传达的，例如：
用户在Landing Page内留资后，系统会根据IP地址解析时区信息并返回。
为什么说它是失败的
由于低估了问题的复杂性，导致上线后信息混乱，并且一些问题隐藏了一段时间后才被发现。
- 员工在 CRM 内为用户安排预约时，不确定展示的时间是基于用户所在时区还是基于销售所在时区。
- 系统会向用户发送短信，提醒用户的课程计划将于***时间开始，但这个信息可能是错误的。
- Landing Page 传递给系统的用户时区有一些错误，导致 EC 认为用户可以通信，但实际上是用户的午夜时段。
后面如何解决
- 在CRM内展示员工所在时区信息，并支持员工修改。
- 在CRM内展示用户所在时区信息，及用户当前时间。
- 在CRM内支持Switch开关一键切换用户时区视角和员工时区视角。
- 给用户发送的通知中，包含时间字段时，都附带上时区信息。
- 用户登录学生端/家长端/官网时，读取设备时区信息。如果发现与系统记录不符，提醒用户是否修改。
- 如果系统记录的用户地区与用户时区信息不匹配，给员工提示信息，去与用户确认。
- 修改Landing Page根据ip自动解析用户时区的逻辑。如果是美国的手机号，通过区号确认时区。
Learnings
- 怀着敬畏之心去学习友商。
- 上线后，查看数据以发现异常。
项目3：用户自助预约试听课
项目描述
在Vispark官网上，有一个自助预约试听课的功能。用户留下联系信息后，可以无缝跳转到自助预约试听课程。
Vispark家长端也提供了自助预约试听课的功能。
为什么说它是失败的
上线半年多以来，自助预约试听课的用户量一直很低。许多新入职员工在体验流程中提出过此功能的改进建议，进行了多次迭代，耗费了大量资源。
以下是几点问题：
- 错误的战略选择：官网只有几千个月活跃用户，未付费用户也没有动力下载家长端。因此，其实拉新的主战场是在Landing Page上，而在官网和家长端上添加此自助功能是浪费资源。
- 没有考虑端的适配：最初，自助预约试听课只支持PC端，不支持移动端；而活字平台（Landing Page制作工具）也不支持移动PC自适应。
- 轻信结论：在US项目初期，有人说过US用户更喜欢自助服务，但我们并没有深入研究在什么场景下用户喜欢什么样的自助服务，也没有探讨是否有好的自助服务案例可以迁移到我们这里。
Learnings
- 开始项目前，先想想他能影响到的用户量级有多大？用户都在哪儿？
- 所有to C的项目都要考虑端适配。
- 听到一个结论性的陈述后要批判性地思考。
如果再来一次
不在官网和家长端上做自助预约试听课的功能。
项目4：区分公海线索和新线索
项目描述
线索可以分为两类：新线索和公海线索。新线索是指新注册的线索。公海线索则是指一段时间之前注册的，但由于之前跟进后没有办法转化，被销售放弃到公海里的线索。过一段时间后，这些线索将被重新分配给销售进行跟进。本需求的目的是帮助销售区分新线索和公海线索，帮助销售进行优先级的划分。
为什么说它是失败的
功能上线后，我们发现有些新线索被标注成了公海线索。比如，线索新注册后被分配给A销售，A销售离职后，线索被转分给B销售，这时候线索就被标注为了公海线索。但是从业务角度来看，它其实是个新线索。原来研发在实现时，把逻辑写成了更换过销售的线索就是公海线索。
我们修复了以上逻辑，但销售的指标并没有出现明显好转。虽然我们将这两类线索划分清楚了，但这不是告诉销售：“这是公海线索，你不用跟进”嘛？这并没有解决问题的根本。因此，我们需要思考：线索应该如何被分配？分配后销售的跟进节奏是怎样的？这两个问题还没有得到很好的解答。
Learnings
- 产品应该善于发现心理模型和实现模型之间的差异点。
- 不解决根本问题的方案只能起到隔靴搔痒的作用，大概率会失败。
如果再来一次
- 确定如何将公海线索和新线索分配给销售人员。
- 确定销售人员在获得线索后的后续跟进SOP，并确定该SOP是否已准确地完整地在系统内实施。
项目5：CRM短信模板功能
项目描述
员工可以在CRM内向用户发送短信。但由于合规性要求，短信内容必须采用模板+变量的形式，而模板可以进行多种配置。
为什么说它是失败的
上线后没有人使用，原因有两个：
- 员工觉得模板不够灵活，无法自己修改内容。
- 收不到用户回复的短信。
Learnings
- 当一个需求很难完全被满足时，需要了解清楚需求方的底线在哪里。如果无法达到底线，那就不做。
如果再来一次
- 不再在CRM内提供发送短信的功能。
项目6：Holiday Seasons团购活动
项目描述
每年11月至12月期间是美国传统的购物旺季，包括感恩节和圣诞节。希望在这个时间段内开展促销活动，以提高潜在客户数量和订阅用户数。
为什么说它是失败的
- 目标是招募10个团长完成50单，但实际达成为0团长0单。
- 最开始未支持多端适配，分享流程也不够流畅。
Learnings
- 缺乏一个能统筹全局的owner或设定PMO的角色，导致产品只关注产品本身，marketing只管提出活动，而中间的关键角色还经历了leader的更替。
- 运营动作不够清晰，只是设定了目标，但是该目标下每个人应该做什么并没有讨论清楚。
- 所有to C的项目都需要考虑端适配。
项目7：员工数据大盘
项目描述
在CRM系统内展示关键业绩数据可以帮助员工更好地了解自己的表现和业绩，从而采取更有针对性的行动。同时，这也可以帮助管理者更好地监督员工的工作表现和业绩。
这些数据的准确性和实时性都非常重要，因为它们直接影响到员工的薪酬。因此，员工非常关注这些数据。如果这些数据不准确或者延迟，员工就会对系统产生不信任。
为什么说它是失败的
一开始做得不好，但是后来改进了。存在以下问题：
- 实时性问题：数据来自数据仓库，有几个小时的延迟，导致即使用户已经成单，达标率数字还没有变化；所有用户的消息都已经回复了，但是还显示有未回复的消息。
- 口径不一致问题：业务逻辑非常复杂，在定义口径时需要考虑补差、退款重买、不同学科、不同课时属性、多孩家庭等多种场景。往往业务计薪口径已经变化了，但是系统内展示的还是旧的、错误的口径。
Learnings：
- 在制作看板类或数据类产品时，应该清楚地标注数据的延迟时间和口径。
- 必须与运营部门协作，员工所看到的系统数据应该与运营数据保持一致。
项目8：SOP系统化
项目描述
CRM内的工单是员工SOP的系统化落地。SOP内规定了员工需要在什么时间做什么事情，就需要生成对应的工单，提醒员工去完成任务。完成任务后，员工需要将结果回填到工单内。
为什么说它是失败的
SOP系统化是一个历经多个迭代、持续了两三年的项目，存在以下问题：
- 业务侧的SOP一直在变动，但是系统端的SOP功能没有抽象成乐高积木式的，导致系统内的SOP始终都慢于业务侧，不在一个频道上。应该将触发节点抽象、工单能力抽象，做成配置化的。
- 没有考虑员工的实际工作量：在SOP第1版中，有一项需要员工完成的任务叫做“课后沟通”，即学员每节课后，员工需要与学员沟通上课感受。但是实际情况证明，这项任务是不现实的：一个员工需要负责200名学员，其中90%的学员在班上，每周上2节课，因此每天的课后工单就有72条，员工无法完成沟通任务。
- 没有考虑工单的并发问题：在第1/2版SOP内，有一项任务叫“专题沟通”，学员每两周学完一个专题，专题学完之后，员工要去沟通本专题学习状况。但是每个专题的末节课都是在一周的后半周生成，所以专题沟通工单也都是在后半周生成，导致并发过高，员工来不及处理。
- 没有考虑超期任务的自动关闭：每个任务都有一定的时效要求。比如，首次联系任务，如果学员报名后一个月才处理，就没有意义了；专题沟通任务，如果专题B已经学完，再去处理专题A的沟通也没有意义。因此，需要增加任务自动关闭的逻辑，避免系统内历史未处理信息的积压。
- 没有考虑关闭任务时的系统校验：比如有一项任务叫”确认进班“，要求员工与当前不在班学员的家长沟通，安排学员尽快学习。如果学员不进班，要选择一个原因。在最开始的时候，没有增加校验机制，导致员工瞎选也能正常关闭任务，比如：员工选择”学员年龄过大“，实际上系统内学员的年龄只有4岁。
- 在选项中增加了”其他”：当有这个选项的时候，50%以上的人都会选其他，哪怕其他选项里有符合的，他们也懒得去查找。
Learnings：
- 考虑到SOP的变化是常态，应该尽量将SOP的工单进行配置化落地，比较初级的是内容的配置，比较高级的是流程、触发条件、关闭条件的配置。
- 做工单、自动消息类的功能，要考虑总量、频次、并发值。
- 做工单类功能，开启条件、自动关闭条件、手动关闭条件等，逻辑要完备。
- 在选项中，尽量不要有【其他】，除非是当你没想明白选项，需要发散收集信息的时候。