我曾经一度对于「平台产品经理」是没感觉的。毕竟大家都是产品经理，做平台有什么了不起的？大家干的不都是产品经理的活么？你有什么差异。
但，后面，发生了一件事，让我记忆犹新，从而对于「平台产品经理」和平台级业务的感知和敬畏加深。
那时我刚加入飞书开放平台，作为飞书开放平台的技术型产品经理，我要去推动一个产品上的 API Breaking Changes。如果在产品发布前就触发了 Breaking Changes，就一定要提前告知客户，不然会直接出现事故，要追责。所以，我就发布了通告，进行客户的告知。
看起来很正常，且做的事情逻辑也对，是么？
但其实那次被定义为事故，事后组织了复盘。
之所以被称为事故，是因为，我的客户告知，进行了一次大面积告知，我的通知告知了所有的开发者客户，但实际上真正可能受影响的客户并没有那么多，我的过度告知反而给平台带来了巨大的解释成本和服务成本。
这个事情很小，但非常明显的体现出了普通产品和平台型产品的很大区别，普通产品大家的影响面可能是非常有限的，但平台型产品，特别是 TO B 的平台型产品，你的影响面可能是数以万计的用户和客户。一个处理不好，可能就是所有人要陪着你一起去跪客户的。
呃感觉你这个例子与敬畏没啥关系啊
根本上是你 做的这个修改 难道事前没有评估影响范围么？ 是产品没有提还是开发没有质疑。。合理的方案都是评估相关改的影响范围，然后根据相关影响程度对影响用户做不同渠道的告知，包括 不限于公告 站内信，短信，电话等渠道。。
而且你这个 标题也不对 对平台存在敬畏 --对 toC 的用户就不需要敬畏么。。这个事情本身和敬畏就没啥关系，，本质上还是自己本身的经验不够丰富 或者说是 自己的水平不够思考不多，对自己的产品以及客户不够重视。。
1. 我觉得是这样；从我过去的经验来看，这个是 breaking changes ；也是影响范围；但这里的问题在于；飞书开放平台的用户不是简单的【开发者】；关键的 diff 在这里；
2. 当然，我觉得确实是那个时刻经验是不够的；第一次做平台型业务。过去做的都是直客。
我想问一下 是不是因为接口的使用者调用方式和次数 目前不会存储用来这类通知和计算
不然似乎可以定向通知？
hhh，细节不完全记得清。但我记得我们当时是改了 Auth 的逻辑。