数据/2B 产品的设计理念
供企业使用的数据产品可以分类到2B产品，与2C的产品相比，数据驱动、业务流程驱动的大中台岗位（俗称数据产品和2B产品），虽然体验完全不同，深挖下去，原理没太大有差异。
互联网市场进入饱和期，产品设计日渐成熟，产品设计上的创新点难以形成新的业务增长点。企业规模扩大到一定程度后，内部运作的效率和准确性很大程度上决定了产品的用户体验（特别是平台电商），传统的业务流程在这个背景下显得十分笨拙和呆板。
我们发现，即使是内部流程，也是可以数据驱动的，各种服务的触发点完全可以由数据驱动。这是本文希望引出的观点。本文主要讲一些2B和2C的一些区别和联系，下一篇再叙述数据驱动流程的一些背景。
为了表达观点的通用性，本文用2B产品来概括数据产品和内部系统产品。
2C和2C
2B和2C业务本质上并无太大的区别，都是在特定的场合提供合适的服务。只是服务对象，一边是理性的商业人士，一边是感性的消费者。
对B端客户，提供全面可靠的信息，减少信息熵，缩短决策成本；对C端客户，提供刺激感官的信息，在特定的场景提供能带动感官的信息。
因此同样是电商，对不同客户类型的信息展示逻辑大有不同（具体表现在商品信息、搜索、推荐、用户结构），但本质并无太大区别（都是在适当时候提供适当的信息，本质上都是信息的搬运工）。
对内和对外
2B的对外
对外的系统，例如官网，例如商家后台，可以看作是本企业某种能力的打包出让，很有可能会被用户整合到自己的业务流程里面，个性化需求非常多。因此2B的对外业务尽可能要松耦合，可配置，开放化，多做稳固性更新，少做功能性更新（新产品除外），主业务流程做厚做深，体验性功能做轻。
2B对内
对内的系统，例如数据后台、WMS、SCM等，要求上下文清晰，角色分明，能有冗余地支撑业务行动。在业务的各个环节降低①信息获取成本②信息分析成本③协同时间成本④信息留存和追溯成本。
当然，业务总在不断变化，因此遵循的原则是一样的，我们不能覆盖全部业务需求（何况很多业务需求只是一时兴起）， 主业务流程做厚做深，体验性功能做轻。 重业务，轻体验。丑一点，总比不能跑通流程要好。（当然，前提是交互合理，流程顺畅，逻辑清晰）
对内系统有两个主要任务：提升员工工作效率，规范的处理和留存业务细节，替代最优化工作和简单重复工作。（前者需要算力，后者浪费资金）
数据处理和分析
2C
2C业务的数据量通常十分庞大，数据源十分庞杂，十分轻易能达到TB级别，系统性能要求高。要有效运用，依赖大数据数据引擎和高性能数据库的配合才能发挥作用，数据仓库的建设要求十分高，对算力的要求更高。由于规模大，效率高，往往迭代周期很短。ABtest在2C领域是个利器，数据量达到规模以上时，只要数据产品经理洞察准确，即便只修改一个文案也能带来百分之几的增长（不过最近这个形势，能保证流量不流失就不错了）。
2C的数据分析通常服务于售前和付费前（推荐系统、风控系统），因此数据来源通常是售前行为数据或者历史数据，并把数据运用于预测用户行为（然后进行推荐、评估等等）。
2B
2B业务的数据相对比较冷，更加离散，回归周期比较长。另外同等规模下，2B业务链条更长，数据有很大关联性。在使用场景上，通常不要求即时分析（供应链和仓储除外）。所有系统最好搭建在同一个平台。通过统一的数据后台（中心）对其他应用提供服务。（中台和后台的区别不重要，因为业务总在快速变化。）
2B业务的数据分析周期更长，但决策的意义更大（交易颗粒度远大于2C业务）。因此我们分析数据的时候，内部数据只能作为团队内现状的参考。预判和紧盯对手也是重要任务。大样本统计的思路在这里并不适用，更多需要结合行业理解进行推断，在2B领域，更需要行业老手参与数据分析，快速迭代的ABtest很难在2B业务展开。
2B数据分析有比较经典的经济学理论，不过老实说有点过时。2B分析的场景通常是在售中和售后，利用与客户接触的机会和提供服务的机会，不断收集客户信息，不断提供客户感兴趣的信息，并利用强大的供应链能力为客户提供高于对手的合作体验。另外在供应链领域，机器学习也有大量的应用场景。
竞品跟踪
即使是内部系统也是需要竞品跟踪的，当然这难度很高，因为你需要从对手的细微业务调整，反推对手的业务体系调整，从而总结出对手在管理上的转变和业务能力上的转变。比如对手突然支持供应商改账期了，这意味对手的供应链、财务和仓储都有了强大的调度能力。这时候我们就应该反思一下自己是否能做到。
这里用跟踪这个词，每个时间段，由于世界上会发生很多不同的事件，都会对各行各业产生影响，因此跟踪的范围，从定位重合的对手，到上游、再到下游都是观察的对象。由于覆盖面大，响应周期长，所以用需要长期收集和系统地跟进。
设计原则
第一性原则 ：无可参考，从本质出发
关联原则：数据互通，可快速查询和搭建新功能
扩展性：提早考虑未来一年可能出现的场景
协同性：共同信息被有效传递，及时更新
一致性：数据处处一致，外部数据必须经过校验和清洗
可用性：花更多精力考虑系统稳定性
交互原则
收敛：突出此情此景有用的数据和功能，折叠无关信息
可感知：让使用者时刻清楚正在发生的事情，可以准确进行操作
反馈： 让使用者清楚现在需要做什么
低负荷：层次直观，使用者可以清晰知道所处的步骤；不适用过于刺激的配色
低操作：不需要使用者做多余的操作，但需要收集信息时，提供合适的输入口。
场景： 符合使用场景，符合角色定位
不同业务的沟通原则
区别于2C业务跨部门众多，拉会议解决问题，2B业务沟通时，需要更深入某一个业务场景体会问题点。
简练：只沟通有用信息，提供正确的信息。
合时：适当的时候沟通适当的事项。
深入：找到问题的根源。
反馈：反馈情况和进度。
优先级和排期
OKR：按照以下维度决定先后顺序
是否影响正在进行的业务
时间窗口
影响范围（人、系统、情景）
边际效用和长尾效用
短期意义和长期意义
解决问题需要的资源（人、时间、心力、资金、人员配合……）
难度和效用之比
下一篇讲述 数据、内部产品的设计过程管理