智能客服，做深还是做广？

语料运营过程中，逐渐遇到深度和广度的问题。团队为此沟通了十万八千遍，天天开会，始终无解。
当时就是思维形成了两大派：
1、认为应该做“深”，只解决用户80%高频问，对这部分语料做精做细，但放弃20%，直接兜底回复；
2、认为应该做“广”，尽可能覆盖用户100%的问题，让用户觉得我们无所不能。

根据个人的经验和逻辑判断，我站1。但因为刚进组时间不算长，还没摸清战势，不好轻易发声，先旁听为主。
于是，我就被拉去开了一场又一场会议，感觉浪费了大量时间，一直没有定论。有天我实在没忍住，在会议上开了口，就是那场会上，对方直接被我的话怼了个哑口无言……

简单总结，我当时辩论的核心点是：
1、二八原则的合理性：目前时间和人力有限，我们项目又要出结果，只能聚焦；
2、围绕核心目标来讲：准确率、匹配率，其实都已经划定了明确的知识范围界线；
3、【关键反转，彻底定局】抓住对方逻辑漏洞：对方认为没有客户真实数据，不认可“到底怎么界定哪些就2哪些就是8”的逻辑，那我就反问，“如果连2和8都难以界定，又怎么去界定10？盲目全面覆盖，真的可能做到100%全面？”

那场会我应该是直接得罪了一些人。但是不管怎么说，项目方向是终于明确下来了。拖泥带水真的不是本人性格能容忍。

做产品要放大人性的善意

人性存在善恶，做产品不能放大人性的恶：有时候，引导实际就是引诱，你甚至可能都不知道自己做的产品在逐渐引诱用户的恶性。
做产品应该思考“让用户感受到什么”，而不是“我们想要用户干什么”，有时候做产品太多“想要”了。
举例：短视频，充斥大量虚假信息、信息茧房、浪费用户大量时间，变得失去思考能力，对世界存在错误认知。

一定要浪费大量的图纸

开发评审，产品会遇到很多阻力，比如开发喜欢挑战说这个设计方案不够有前瞻性，要为后面的规划考虑整体架构设计。
所以要提前准备好大量设计，然后又告诉开发说，“这些、这些和这些都不用做，我们目前只需要做到xxx程度，真正的MVP版本”。
千万不要吝惜自己多画的图纸，“浪费”的力气，实际上都不会白做，都是有潜在价值的。

职场基础能力不容小觑

有一些基础能力，是即便在职场摸爬滚打了很多年的人，仍然没有学会的能力。
比如：能够讲清楚，自己或者小组到底在做什么……

公司产品答辩的问题

参加公司的产品经理答辩会，记录了在场评委们提出过的问题：

• 产品线的定位是否清晰？是什么？
• 产品谁用过？受欢迎和不受欢迎的功能点的相关数据、比例？
• 为什么不用xxx产品形态？而是xxx产品形态？
• 用户定义是谁？他们到底在哪里？核心痛点是什么？
• 多少资源投入，是否合理？多少产品、开发、测试？够不够？产品输出进度结果，是否可控？
• 你们产品对自己的产品是否满意？为什么？
• 用户是否对产品满意？怎么定义的？
• 有多少用户在用？
• 目标是否拉齐了？
• 如何佐证，这个功能需求做了就能给业务方带来很大的影响？业务方催得急，如果上线了，效果不如预期，谁来背这个锅？“你们产品都认可这个需求做了就能带来效果，那如果最后没有效果，不就是你产品做的不好吗？”--- 明确告诉业务方效果要一起担责的
• 数据效果？没有数据等于没有结果
• 工时用了多少，占总规划的比例是多少？
• 如何量化自己的产品是否成功？