数据产品是通过构建数据流对数据的应用和管理，因此从产品的形态、构成和逻辑上会比一般产品更复杂。那数据驱动为什么要基于数据产品？阅读完全文也许你就能明白了。

前两天看到有人在问“数据产品最重要的能力是什么，偏技术还是偏业务？或者其他方面？”

我以此话题作为开篇引入。我们不探讨‘最重要’的能力是什么，这是伪命题会以偏概全，我们把能力问题拆分来看到再决定偏向问题，而说到这就不得不从产品的基本构思和设计来说起。

回归本质，我认为：产品的构建就是数据流的走通，对一个产品的设计构思或者说形成产品的过程，实际上就是构建业务逻辑流程让数据走通。因为产品的目的是让业务实现的，而业务实现就是信息流、物流和资金流。

所以一个产品经理要对数据流或者说信息流有掌控力，对一个产品的迭代就是对信息流通过程和传输逻辑的优化。当信息流通过程清晰简短达到最优这就是一个好的产品，你去看一款好的产品一定是简单、易懂、好用。

像微信，就是这么简单的一款产品极大的降低了信息流通成本，并没有很复杂的机制来提升用户粘性，很单纯。这也是为什么现在的产品要做减法而不是加法。

如果没搞清楚信息流向，就是在给产品挖坑，后期就像随时会崩溃的水坝一样危险。大禹就是个很棒的产品经理，信息流就像洪水，构建的产品就是大禹治水的方式，疏而不堵。

转回数据产品，数据产品是通过构建数据流对数据的应用和管理，因此从产品的形态、构成和逻辑上会比一般产品更复杂，如果在数据层面再加上物流（交换）、资金流（交易结算）的概念，那就相当于把信息流的物流和资金流描述出来。

就像元数据的概念一样，是描述数据的数据，可想机制的复杂。描绘信息流的物流和资金流的过程就很像区块链的概念，因此目前的数据交易大都会涉及到区块链，这是另一个话题以后有机会再聊。大家可能感觉会有些绕，但是理解了便会豁然开朗。

构建数据产品要站在‘数据’管理者的角度去思考问题，不是‘产品’管理者，大部分的通用型产品不会或不用去考虑数据的规范、类型、标准、模型和质量等问题。而这却是数据产品考虑最多的问题，所谓底子没打好，怎么去考虑灵活应用呢？

因此数据产品所具备的不仅仅是数据使用场景，并且产品经理要从数据使用角度切换，这样你才能开拓方向和视野。

当数据基底夯实，就可以依此去扩散应用场景，数据产品就可以朝各个应用方向扩散。很多人可能对数据基底没大有概念，我举个最简单的例子：在你日常工作中肯定遇到一个场景——就是和别人谈论一个指标或者一个KPI名称相同，但说到最后发现算法却不一样。

就拿‘用户活跃’来说，不同业务对其的定义都不一样，到底是按用户登陆来算？还是按用户访问来算？还是按购买来算？

尤其是规模越大的公司这种问题会越大，因为信息不对称，沟通成本也直线上升，公司规模和问题成本成正比。这种常见的问题不用说数据应用了，出现一个指标大家都人云亦云不知其所以然。

我之前了解到阿里近两年开始着重于数据应用的研究，就是因为他们内部经过长时间对数据基底的改造，形成了一套OneData的数据体系，规范了整体的数据标准和管理，最大程度消灭了信息不对称造成的成本。

因此有底气往数据应用方向研究发展，就像那句老话讲的“学好数理化，走遍天下都不怕”。

ps：这里说一下数据使用和数据管理角度的转变所带来的不同，单纯的数据使用会慢慢形成长期的需求惰性，就像流水线生产一样，一直承接需求，生产需求。但是流水线过程中不严重的瑕疵，却忽视而过，只是为了完成。这是人的惰性，不可避免。

管理的监督要尽量减少甚至杜绝，但只对最后的结果检验管控没办法发现其中隐性的问题，那么就需要像6Sigma管理理念一样，层层把控，降低过程失误，提高整体质量率，这样就会引导你往整体和大局方向去思考和规划。

当数据基底夯实后，那么就需要丰富的知识视野和业务场景积累去考虑应用方向，如何应用？如何连接用户解决他们的痛点？

而数据应用不是拍脑袋就可以想出来的，要结合自身数据使用的经历和目前用户及环境的现状来考虑融合。

根据上面所说：如果不懂技术，很难去理解数据管理和信息流（数据流）的规划处置。而数据管理需要，基于你对技术的理解和管理知识、经验（经验除了自身积累，也可通过用户诉求来总结）的结合。

当数据产品的生命周期度过初级阶段，后面就需要和业务强关联。而想要拓展更多的应用和业务场景，那就需要你丰富的视野和知识体系。

因此，当时我的回答是：

“不懂业务，产品无法落地。不懂技术，何为“数据”产品？偏向的话还得看产品所在的生命周期，目前国内的环境来说，还处在产品打磨阶段，所以可能更偏向技术。”

文章至此，或许你也就明白了数据驱动为什么要基于数据产品了。

本文由 @细说猫狗 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自 Pexels，基于 CC0 协议