各位前辈好，我之前提问了一个问题，关于初级产品经理如何提升产品思维与产品能力

今天我与公司中的产品前辈在闲暇之余沟通闲聊，并请教了一些问题，但是在沟通中，我发现了我自己存在的问题，或者说是，我觉得我产品思维薄弱的问题之一

那就是过于主观化-没有考虑好边缘场景

还是以一个发生在我身上的事情作为案例：

我在某一日工作中设计某一个模块，业务是：教务老师会给学生配置导师，一个学生只能配置一个主导师和多个副导师，这个是业务定死的，于是我设计了一个功能，并且根据业务而定死。

当我去把原型兴致勃勃的交给甲方产品的时候，甲方却要求，可以添加多个主导师，我很疑惑和甲方询问，业务上明明定死，为什么系统要给用户操作范围扩大？甲方没有回话。

那么我对于此次事件的复盘加上我与前辈的沟通，我发现了一个问题

甲方产品为什么在系统中要允许老师为学生配置多个主导师？业务都定死了，为什么系统要放开?

我的复盘的结论是：边缘场景也可能会变为核心需求/业务！！！这个是我复盘出来的关键点，我觉得是一个核心思维

虽然业务上一个学生只能有一个主导师，但是难道业务会一直这样下去吗？业务不会变？会不会有万分之一的概率，在某一天，某一个学生所学习的课程，校方发现一个导师不够用 于是特批2个导师去为一个学生服务？？

这是一个边缘场景，但是随着时间的推移，会不会某一天校方发现，2个导师的效率更高，于是业务调整，允许学生有多个导师，这就是边缘场景进化为核心需求/业务（我的看法，如果不对，希望得到各位前辈的修正与指点）

我一直以来的观点是能限制就限制，限制死用户的操作范围，以免让用户因操作失误而避免后期结果的错误

但是我今天发现，我限制死可以的，没问题，但是我的产品支持后期业务的迭代吗？能否实现某一个新的核心业务，也许这个新的业务就是从边缘场景进化过来的。

公司前辈和我说的是：用户防呆校验还是要做的，但是不影响最终结果和影响业务的操作可以不加规则，能简单实现是最好，方便后期迭代（方便迭代是我自己理解的，如不对，期望得到各位的纠正）

于是我进入了深度思考，作为产品我不能只着急满足现有业务，我更应该去想一下业务的边缘场景，和边缘场景发展的可能性并为之提前铺路，要做到现有的我可以实现，未来的我也可以实现，我能兼容！而不是真的到了业务变更的那一天，发现我设计的产品无法支撑起新的业务场景，无法落地，甚至避免开发团队大改。

就好比我为A企业去做系统，A企业的业务就是加法，但是在同行业里，其他企业都是乘法

那我是不是在设计A企业系统的时候不仅仅要满足加法的业务流程，更要想一下，A企业会不会在后期也会进化成和其他企业一样的 乘法业务？我设计的时候要不要为后面的可能性铺路？

这个是我的总结复盘：

1.考虑边缘场景，不能过于信赖或肯定现有业务的稳定性

2.边缘场景也有会发展成核心需求/核心业务场景的可能，要做到考虑到，覆盖到，并未未来发展铺路。

以上是我的思考和复盘，希望能得到各位产品前辈的指点和教导，我本次复盘是否正确？如果有其他建议补充，能帮助到我的，也跪求各位前辈能在百忙之中指点辈，感激不尽！