注：这里的所有内容都直接截取自我在团队内的发言。
“以用户问题为中心”，而不是“以解决方案为中心“。这句话听起来好像是一句废话，但却是整个团队在持续犯错的。
我们内部在讨论问题的时候，也是经常性的提想法、提方案，但没有考虑清楚到底是要为用户解决什么问题，这个问题定义清楚了吗，是否有现成的解决方案，用户对当前的解决方案哪些方面是不满意的……
这是因为提想法、提方案其实很简单，每个人都可以拍拍脑袋提个想法，但考虑清楚问题、并进行准确定义和描述却是很难的、是反人性的事情。
比如 AI 的例子：现在做 AI 的公司一大堆，但大部分都是拿个方案出来找用户，而不是提前思考清楚用户的问题到底是什么。但用户从来需要的不是 AI，而是需要在某个场景下解决什么问题，AI 只是手段，不是目的。
比如API 项目，其实我们也没有认真思考过为什么海外用户都想要 API？他们是为了获取用户线索？提升转化漏斗？提升用户活跃时长？还是出于什么需求？更多时候是一上来就在内部讨论采用什么样的解决方案。
比如管理制度，我也习惯性的和HR直接讨论制度的细节，但其实对当前团队面临的核心问题、为什么要用这样的制度，我们之间没有过多的讨论。这可能导致某些制度出发点和形式都是好的，但不符合当前的团队阶段。
接下来的具体做法是，在内部但凡我们在提出解决方案的时候，我们都相互追问下：你要解决什么问题？这个问题的准确定义和描述是什么？相关的用户调研和数据支撑是什么？至少我会提问。
这个观念很难短期内改变，但现阶段可以僵化的相互提问，最终形成团队共性思维。
和业务团队谈：工作时要写文档，而不是 PPT
亚马逊里强调“写详细文档，而不是 PPT”——如果我们对一件事考虑的很清楚，往往我们就可以把它书面化出来。如果觉得书面化很难，往往是因为没考虑清楚。
对于现在的核心产运人员，我们一直在强推书面化，目前情况看产品和运营落地的都还不错。因为产运作为火车的车头，如果考虑不清楚、跑错路，对其他人的危害是极大的。
但也遇到一些落地的问题：“书面化”是一个要求，但核心还是自己思维的过程。部分人在书面化的时候其实还是很随意的写，并不是深入思考之后的书面化。
人事部门和我正在做的事情是：我们会把团队做的好的用户调研、投放测试、版本分析、竞品调研、业务复盘等做成案例的形式，让其他人去观摩和学习。其实就是要倒逼整个产运团队培养深入思考的习惯。
最终达到的目的是：让产运团队在考虑问题的时候，都是能够系统性的、全面的、深入的思考后，提出方案。而不是动动嘴、拍拍脑袋就提出想法。
正所谓“产运无能，累死研发”。
这个方式会不会很浪费时间？——非常多人都会这么质疑，但实际的情况是：这种工作方式极大的减少了不合理项目、不合理需求的出现，是真正意义上的提升了产研团队效率，节省了公司的时间；
项目通常的死亡模式是：一上来没考虑清楚针对什么人群、解决什么问题、采用什么打法，一上来就开始做，结果做到一半发现问题，最后耗一段时间，直到死亡。
和产品团队谈：对用户要有深刻理解
亚马逊里有句话“伟大的产品来自于对用户的深刻理解”，这句话其实是和整个亚马逊的工作法一脉相承的。
乔布斯曾经说过非常相似的一句话：“伟大的人还会继续向前，直至找到问题的关键和深层次原因，然后再拿出一个优雅的、堪称完美的有效方案。”
所以最终决定我们在行业内胜出的两个核心内部因素：一是有一群价值观相似、能力互补、各具擅长的人；二是我们能够对整个行业的用户进行持续性的、深入的研究和洞察。
和管理团队谈：不同业务阶段要有不同文化
我自己信仰的是苹果、Google、Netflix这种公司所提倡的自由、开放、自驱、高效的团队文化，所以团队内的协作模式、管理方式都是基于此建立的。
但目前情况观察下来，这种方式的利弊很显然：好处是对于自我要求和自驱力强的团队成员，这种方式能够充分调动一起奋斗的积极性；问题是对于自我要求没那么高的团队成员，过于宽容的环境，反而在纵容“躺平“和”不努力“的行为，虽然这种行为在内部的占比并不高。
团队管理是要考虑集体利益的，奶酪不是无穷尽的，被吃完的那天所有人都将受到影响：我们团队在当前阶段到底需要什么样的文化？需要什么样的价值观？以及配套的协作、管理制度？
——这些不应该是固定的，而是基于当前的业务阶段和目标来的，这也是我最近在重新思考的问题。
我们内部的管理者们也可以做一些思考，年底我们进行讨论。
和人事部门谈：对周报的思考
前段时间我建议让大家写周报用邮件——这个思维方式本身也是错的。
邮件还是飞书，其实都是手段，不是目的。包括周报也是手段，而不是为了写周报而写周报。
核心我应该考虑的是：不同的人写周报的目的是什么？是能够对业务带来哪些提升？什么方式能够达到目的？然后再确定具体的方式，而不是一上来要求用飞书还是用邮件。
所以这周我先对客服的周报进行变革，让客服周报直接用 Slack 写，对应的负责人必须回复和推动解决。其他人的周报我没想清楚，就先不做调整。
和老板谈：逆向工作法+第1性原理
最近对“第1性原理”和“逆向工作法”有了全新的认知和理解：我发现它不仅可以用于解决业务问题，也可以用于解决管理和团队问题。
我举几个例子：
AI 业务方向——AI 本身只是手段，用户不会需要 AI，他需要的是 AI 来解决某个场景下的问题。那么需要解决用户的什么问题？用户解决问题有哪些方式？他在什么场景下会用到 AI。这样才能避免本末倒置，做出无用的 AI产品；
管理制度、考核制度：实际上我们在制定这些制度之前，应该先内部讨论我们当前遇到的团队问题和管理问题，然后再讨论到底是 360 考核解决、更改制度解决、贡献排序解决、文化建设解决还是其它解决方式。
现在我的感受是：我们还是一上来太喜欢先提方案，而忽略了问题本身。比如 360考核里面有一项下属对主管的评价，要解决什么问题？需要这项吗？
现在几个业务主管都是按照我的思路在贯彻业务方针，他的下属可能并不理解和认可，但只要能达到业务目标，我就支持他们。所以360考核这种方式本身就不是为了解决问题，而是因为别人在用，我们也搬过来用。
我们以后可以坚持这个方式：先提出问题、定义问题、清晰问题，再考虑解决方案和应对策略。
我们要坚持“逆向工作法”+“第1性原理”，这样才能让我们的思维立于不败之地。
和老板谈：要不要让团队听培训课程
现在 HR 那边每周都在组织培训，出发点也是好的，希望提升团队素养和能力，但我观察非常多人这周不去听了。
我分析的背后的逻辑是：培训课程需要针对当前面临的问题来，比如团队面临的问题、业务面临的问题、运营面临的问题，那么大家可能都愿意去听。这周的主题是《如何在关键时刻做对决策》，非常多人估计觉得跟自己的关系也不大，就逐步的不去听了。
按照“逆向工作法”+“第1性原理”来思考：
第1步：当前业务和团队面临哪些问题？
第2步：这些问题是通过制度、管理、培训、绩效等什么方式来解决？
第3步：如果需要通过培训解决的，那么就需要调研大家的预期和希望培训提升的方面；
第4步：培训完及时搜集效果反馈和跟进。
——这种针对性的培训，效果就比较好。现在每周让大家固定时间去听，时间长了就感觉像在完成任务。
和运营团队谈：客服与产品的协作原则
我这里定几个“从客服反馈到产品解决”之间的协作原则：
一是对客服的预期：尽量反馈问题，不反馈解决方案；
这也是“逆向工作法”的最核心要求。比如在玻璃瓶子里增加液体，这是一个解决方案，并不是用户的问题。用户在什么情况下需要增加液体？增加液体的目的是什么？如果不增加对他的设计造成了什么影响？——尽可能的说清楚用户在什么场景下遇到了什么问题；
这种方式其实是在倒逼团队回到用户的使用场景和问题中，从“第1性原理”的角度来思考问题。而不是被既定方案所框定；
其实也在反向要求客服团队：见到用户提出的想法后，多问几个为什么。
二是对解决方的要求：不要直接回复做或者不做，而要给出分析和判断过程；
如果直接回复做或不做，这种思维是很可怕的，代表用户说什么我们做什么，长此以往必定摧毁业务的根基；
对解决方的要求是：需要对用户问题进行理清，能够清晰的调查清楚到底要解决用户的什么问题。然后再判断要不要解决，以及当前解决还是未来解决；
优秀的产品团队共性是：通过严谨的分析和调研来否定大量的不合理需求，而不是见到一个需求、做一个需求。
三是权责的划分上是：客服团队的职责放在用户问题的提出、理清、搜集上，而决定做或者不做、什么时间做、以及后续的跟进解决，由产品和设计团队来决定和完成。
因为产品决策是一个系统性、综合性、全面评估的过程，唯一的决策权只能放在产品团队；这个中间，产品团队需要及时做好信息同步。
上面提到的原则很难快速都做到，但我们要内部坚持往这个方向努力。
作者介绍：服务电商类产品经理。文章转载至公众号：杨杰出海笔记，作者：旺仔九号，大数跨境经授权转载。
