好的产品司理是懂的怎么做信息挑选的，从众多信息中找到自己想要的

好的产品司理是懂的怎么做信息挑选的，从众多信息中找到自己想要的，并完结信息加工，最终经过整理形成计划。

最近在做一个供销授权的产品，其中有一个模块值得拿出来说一说。

背景：自建的电商平台中存在供货商和运营商两种角色，这两种角色在签定授权协议后能够进行产品授权，供货商可向多个运营商店铺授权产品，运营商按照指定的出售价出售，出售成功后可获取抽成，这是一个典型的产品授权案例，普遍问题是：

• 数据量大：电商平台动辄上万的SPU，日常动态更新
• 数据项杂乱：成本价、出售价、给其他途径授权的供货价、划线价、抽成，不同当地所需求的参数不一样，所用到的价格也就不一样；
• 数据流程长：两个主体签约 -> 产品授权 -> SKU授权 每一级的授权及承认，每一级的授权前都答应修改，除正向流程外还有逆向流程，循环往复

最开始的计划是最粗暴的，体系支撑一个个产品的授权，并且支撑批量导表，希望经过导表的方法来解决事务上的杂乱度，用技术手段换取运营方便，这是一种惯例做法，这种做法的优点：

• 体系交互简略：单个产品增加和保护都不会有太杂乱的交互，批量操作经过导表处理减少体系操作杂乱度，大批量的操作交给线下处理；
• 灵敏度高：供货商的运营人员经过线下表格与运营方进行洽谈，敲定出售价和抽成，双方承认后，供货商的运营人员在体系导入表格，运营商的运营人员在体系上架出售

这种做法的弊端：

• 体系数据导出后，在线下修改，确实会存在数据安全问题
• 线下表格在实际操作过程中会有数据格式、数据准确性的问题，给导表操作带来更大的费事
• 线下表格的数据量或许会比较大，相关的数据库表也会比较多，增加数据处理的难度

根据线上单品增加、批量增加导表，所以有了以下规划计划。

这套计划全体来说偏向于经过导入来完结作业，一个个产品授权操作较为杂乱，需求先增加产品，再保护价格，操作不便。

经过讨论，弊大于利，最终还是抛弃这种方法，所以开始了从头规划！

首先就日常场景进行剖析确定下用户进入体系能够进行的操作，大致分为两个【增加产品】【日常保护】。