对于产品经理而言，考虑的多，不如考虑的少。一旦陷入细节，就无法抽离出来；作者这篇文章就是一个现成的例子。

最近，我在做付费通用课程收款功能时，陷入了循环。

对于产品经理而言，考虑的多，不如考虑的少。一旦陷入细节，就无法抽离出来，仅以次功能来警示大家，多方的涉及或者到自己不熟悉的领域时候及时收回思维，思考第一步的实现。没有功能能一步完善，尽善尽美，如果不动第一步的话，这个功能始终是需求阶段。完成第一步功能，才能考虑后面的细节。

具体例子：

需求背景：目前在做的项目，有一个增收的指标（需要售卖课程给所有开放平台的租户），目前所在的系统为开放平台下的课程系统，开放平台允许各租户入驻。关于课程内容的管理，有一个统一的元租户，元租户可以管理通用课程，通用课程可以下发到各个租户下的课程系统。

• 第一点：租户内的课程系统，独立运营，租户内创作者可以登录，可以上传课程。租户内的用户可以查看课程，用户和创作者都在本租户内有登录体系。故租户内的收费课程，只考虑两个收益分成方：创作者和本租户平台。例如用户购买一门10元的课程，可以设置分成比例，创作者能获得8元，本租户平台为2元。
• 第二点：租户可贡献本租户内的课程到元租户，元租户审核后，可变为通用资源，下发给其他租户。免费课程，不涉及付费，直接下发给其他租户，或者由元租户定义权益包，100门免费课程多少钱，其他租户只需要付权益包的钱而不需要租户内用户付费。这种相当于买断权益。
• 第三点：租户贡献课程，付费课程。付费课程那块目前涉及：元租户，创作者所属租户，创作者，购买者所在租户，4方参与分成。同时考虑不同人创作者，不同的租户有不同的议价权，不能通过单个课程设置，需要根据多种方式设置分成比例。同时还需要考虑财务公对公转账及代缴税的问题。

目前是我这边想到的，但是几方分成和财务问题这都不是我能决定的，陷入了困境，因为具体的原型流程都已经出来。用申请成为公共资源就要展示分成比例，还有线上协议的显示，到最后的分成提现，都做了具体细化的需求。

目前看考虑的流程都是没有问题的，只有解决了财务和分成问题，才能实现付费课程申请为通用资源。

为此，我陷入了死胡同，一直想的是：成为付费通用课程在售卖前必须明确这门分成收益，把这一步前置到了功能里面。导致解决不了后面分成收益，就一步都做不了，整个功能搁置，而跨部分的协助有比较难控制。险入循环。

自己在这个牛角中很难剥离出来，因为需求中原型细节，整体的文档都已经写完。这时候就要感谢我的领导，向上管理，及时汇报的重要性。在我说明这个需求后，领导里面指出了关键点。只要能支持付费通用课程就能产生收益，收益是第一前提，收益可以全部收到元租户所绑定的商务号。分成收益都可以往后置。

豁然开朗！！！立马完善需求，需求就只需要明确收款方，和元租户能查看订单收益，关于前期贡献课程的协议之类的实际上通过公告或者宣传都可以实现，前期不在系统中明确没有一点影响。关于财务扣税分成，完全线下进行，或者后期明确了再设置都行。回归到功能的第一步，通用付费课程可售卖。

自我学习和分享：及时汇报，回归原始功能。