数据产品，顾名思义，是将数据作为主要的展示形式，用于帮助业务做决策的一种产品。不论是Excel，还是自助取数平台，都可以称之为数据产品。由于产品本身的服务对象是人，因为需要通过非常直观的形式来快速了解数据价值，这就使得数据可视化的能力显得尤为重要。
在业务发展的初期阶段，数据产品的目的是先让业务看到我们的数据，因而这个阶段对于报表类的需求会非常旺盛；当报表产品基本成型，明细数据都支持了下钻之后，通过数据分析拆解指标内涵，将决策的结果直接告知用户，就成为了主要目标；最后就是要把分析的结论和决策的方法下沉到业务中去，做一些行为预测、实时推荐等方面的内容，就成为了这个阶段的目标。
以上提到的三个阶段，是数据产品发展过程中不可缺少的过程，尤其是报表类的看板，更是整个产品搭建的基石。由于其能够直观、便捷的展示数据的价值，帮助业务快速试错，理清业务流程和价值，所以其变动也是非常频繁的。
我们需要新的迭代思路。
既然我们了解了数据产品的价值，那么怎样搭建一个合格的数据产品呢？
是业务方把提出的每个需求都想的清清楚楚？
还是分析师们把口径定义的标标准准？
亦或是产品把Demo稿画的无限保真？
或者是数据的同学把数据的逻辑都想明白，一点问题都不出？
顺着这个节奏，这个产品就没有风险，用户口碑就不会炸裂。
但是，市场的变化风云莫测，人的想法也是日新月异，从来没有一成不变的需求，有的只是快上加快的节奏。
过去我们技术手段没有沉淀的时候，每个报表都是技术团队排期来做的，虽然质量有保障，但是排期从来没有宽松过。后来我们萌生了搭建Cube模型、搞自助取数平台的想法，一定程度上解放了生产力，也提升了分析师和运营同学的想象力。
但并不是每个团队都有能力和精力来做一些平台化的事情，因此用成熟的工具就成为了一种必然的选择。例如BI工具，配合Hadoop生态，就是一种非常不错的选择。最常见的商业产品就是Tableau。
但这种方式也有一种弊端，就是随着"人人都是分析师"思维方式的普及，导致大家针对各自业务场景搭建的数据孤岛越来越多，业务也就成了一盘散沙…… 也许分析小站的生命周期结束了，但底层的数据存储和计算资源却仍然在浪费……
从技术选型上看，Tableau、DeepInsight等大数据可视化平台已经能够满足大多数需求，Hadoop生态也解决了计算能力的问题，架构和性能不是制约产品发展的主要问题。
但是，我们还需要新的产品设计方法论。
让业务看清数据的真相，与业务一同快速迭代，是数据人的基本职责。业务发展有其自身的规律，都是从某个Idea开始，一步一步通过迭代，最终形成体系化的产品运营。
产品设计，首先要能够快起来。快的基础，就是数据要清晰。因为BI工具是解决可视化问题的，并不能解决数据孤岛的问题，因此数据团队在应用层数据的搭建上，就要有完整的体系：既要反应业务过程，又要统一维度指标，让报表搭建的同学，直接面向已定义的数据模型进行开发，减少数据准备中对原始数据的预处理工作。同时，业务、产品与数据，是相互之前可信赖的对象，业务思维如何培养、数据口径如何定义，都是整个Team要共同思考和讨论的。可以说，信任是效率的第一保障。
产品设计，其次要培养用户心智，即便是内部产品，也要打出品牌的号召力。最典型的方法，就是用户看到XXX数据，就想起了XXX产品，这样的思路。业务发展到一定阶段，过去的报表体系就会面临不断下线、不断重整的问题，这既是一种挑战，也是一种机遇，因为迭代可以让产品逻辑更加清晰，也是过往业务经验的沉淀，这就意味着经验可以被复用了。当用户看到某个数据，就可以想到在哪个模块能看时，用户的心智就培养成功了。
产品设计，还需要有规范化的体系。虽然BI工具能够简化工作量，但如何让我们的报表更加的容易被解读，依旧是一个不小的挑战。例如每个人对于报表的配色、图形的选用，有自己的偏好，就非常不利于搭建统一的产品。因此规范化的体系，就包括了四个重点：
配色统一，视觉上要有连续感，避免视觉疲劳；
组件统一，分析类似的场景要选用相同的组件，简化使用成本；
视角统一，口径的名字怎么定、如何加注释、排序是怎样的、日期范围如何，都是规则；
模块统一，相同的分析内容放到同样的模块中，同时名字还要简洁易懂。
报表搭建，也搞出了工程的味道了，人人都可以是分析师，但不是人人都能成为产品。
数据产品本身的输入，是数据分析的价值，是对于数据的规律、趋势的总结；数据产品本身的输出，是数据洞察的价值，包括决策、预测等结论。数据产品的迭代是一个持续的过程，需要时间来沉淀。当一个个模型、一行行代码、一篇篇文档、一句句总结，能够让你的思维体系化起来，就能够让技术找到实现价值的窗口，得到正向的业务反馈。
数据有用吗？其实没用，只是一堆数字而已。数据没用吗？有用的，看你通过什么方式呈现它的价值。
在技术发展的路线上，为自己补全业务思维的那一部分，其实很重要。
