18个月数据产品设计和运营经历的思考

我的职业生涯中，很长的一段时间是从事数据产品经理的工作，而数据产品经理粗略可以分两大类：

1、面向产品运营的，通过数据分析、运营指标和数据采集规划、市场研究等，数据驱动产品增长的产品经理。这类产品经理本质上还是数据分析师，只是在产品意识上较一般的数据分析师更强，在算法和代码能力上较数据分析师弱一些，这类产品经理一般在业务部门办公。

2、面向系统设计的，围绕数据能力自动化和智能化，设计、运营与数据全流程系统相关的产品经理。这类产品经理一般在支持部门（如数据部门）等工作。

什么是数据产品？

我认为，艾达在《数据产品设计》书中说得比较透彻：

“可以认为数据产品就是一个广泛意义上的软件产品。如果硬要把整个数据流通价值链中的各个阶段都包括进来，那么它就是一个数据解决方案了。在此认知基础上，从广义上说，可以发挥数据价值辅助用户做更优的决策或者是直接行动的一类产品。”

大约在一年半前，我是第一类数据产品经理，已经做了好几年。当时负责一个数千万DAU级别的产品（包括国内版和国际版）的数据工作，每天的指标监控、异常分析、月报、专题分析和数据治理等工作，把人填满。我可以预感未来一两年内，没有太大的提升，所以做了决定，要拓宽技能板块，到数据中心做第二类数据产品经理。

2019年12月从支撑部门回到业务部门，今天对这段经历做个总结，谈谈这一年半以来的感受和收获。

一、业务部门和支撑部门的工作模式差异

1、有序VS无序：数据中心属于支撑部门，工作内容更有序，大家按时完成排期内的工作，相对而言，突发性和临时性的问题比业务部门少。

2、技术导向更强：技术大咖有更高的地位，大家经常讨论算法、模型等原理。所以，我个人也加强了算法的学习，希望更好地理解算法技术，甚至参加了公司内的推荐大赛，获得初赛第12名（当时用的是最简单的热度模型）。

3、功能的通用性压倒个性化化：如果你设计的系统，通用性不够，会很难获得支持，因为支撑部门支持的是多个业务，首先需要较通用的模型能力，然后在基础模型能力上，实现个性化的定制开发。举个列子，如果我们要做智能化的报表系统，我们需要输入标准的数据格式，然后系统自动生成基础的核心指标（如DAU、MAU、人均时长等），至于个性化的指标（如某个活动的漏斗模型等）需要拉通其他业务来一起考虑。

二、用户需求优先，还是我们的技术追求优先？

做数据产品经理的第一个月，我主要的工作，是和不同的业务负责人吃饭，了解他们对数据的需求，然后抽象成能够系统解决的通用方案。但是技术开发团队、数据产品经理、业务部门对需求的理解其实是不一样的，特别是开发技术团队和数据产品经理要求需求的通用化、而业务部门更希望个性化，三种角色之间，在需求的一致性和优先级方面，是很难达成一致。

总体而言，支撑部门的技术和产品团队，需要优先满足业务部门的需求，再追求技术深度和创新。但是，很多技术部门的员工，也是需要晋级（升职）答辩的，这时，评委往往挑战的是技术的深度和创新。这种机制下，导致技术团队与需求部门存在比较大的目标鸿沟。这种目标的不一致性，让我在推行项目时，感到很痛苦，至今，我也没有找到很好的解决方案。但我觉得，彻底的解决方案，需要把技术团队和业务团队的利益考核捆绑，同时，要调整对技术人员的晋升考核标准，比如，对于技术人员，可以选择通过技术创新来晋级，也可以选择通过业务效果提升来晋级。

三、为什么大家都吐槽数据产品的体验？

以前我曾经负责过CRM系统需求管理（该系统管理几百万VIP用户，用户每年近百亿的收入），在业务团队也设计过一些数据治理的系统，对于用户的体验非常重视，那是因为曾经有业务团队的负责人当着面说：“你系统的体验做不好，我们就暂时不用你的系统”。对系统操作体验的重视，这一切都是被用户逼出来的。

我个人也曾经体验过神策和growingIO等业内新兴的数据产品，觉得体验算不错，但还没有到达优秀的程度。对于这个问题，我深度思考了几次，觉得可能是这几方面原因：

1、分析方法和用户操作行为的多样性。如果你要设计一款具备自助分析功能的工具，当你去调研用户，你问怎样设计，他使用起来才最方便（或者说最符合的操作习惯），你一定发现100个人，有100种想法。同时，分析方法本身也是多样性的，每一种分析方法，后面涉及的系统逻辑和架构，是不同的，开发起来也是很复杂的。

2、开发资源不足，优先功能的完整性。从现实来看，其实数据产品经理也知道产品操作体验的重要性，但现实通常是功能开发都基本完不成，很难留足时间做体验优化，特别是一些大系统，底层框架定了之后，一旦UI重构，需要花费巨大的底层改造成本。为此，我跟负责企业云的同事沟通过，他们也经常遇到这种工期紧张，无法保障体验设计的问题，他们一般的处理方式是保障关键路径的体验达到可用性，优先完成功能开发。

3、开发模式落后。我真正找到数据产品体验设计差的根源，是参加一次公司内部的战略解读会，里面说到开发模式，解读专家介绍了很多互联网巨头,花巨资收购一些互联公司，而这些公司的员工都很少。比如，2012年10月25号，Facebook以总值7.15亿美元（约48亿人民币）收购Instagram，员工只有13人。你很难想象，13个人的公司，能够产生这么大的价值。就算13个人是开发，让他们独立开发所有的功能模块，那也是不可能完成的。这些小而精的公司（市值却巨大），所使用的开发模式都是PaaS（Platform as a Service），在云的基础上，借用平台提供的通用组件和能力，构建自己的业务基础服务能力，一旦发现已有架构老化，马上可以借助云生态上的能力，升级系统框架。这种模式，是站在巨人的肩膀上(我称它为1到100的模式)，组装式地构建新的系统，它的效率比传统的开发模式（传统模式都是开发同事从0到1的开发设计）高太多了。

4、数据产品经理比较少从事过业务部门的数据分析，对业务的需求理解有偏差。面向系统设计的数据产品经理，有一些是从开发转型过来的，有一些则是直接从事系统设计的，所以对于业务的需求理解，并非很深刻，很难站在业务的利益和商业模式出发点去思考问题。

四、如何改善数据产品体验设计？

上面说的四个原因，我认为根源是开发模式的落后造成了开发周期的紧张，从根本上改变开发模式，才能治本。然而，这种新的开发模式，需要投入不少成本，这可能并非所有公司都愿意承担的。

如果还是沿用旧的开发模式（从0到1构建），那么我们需要优化对开发人员的考核，需要把业务和开发的利益捆绑，定义好最小颗粒度的功能体验标准（比如一个搜索功能，它最小的标准应该包含精准匹配、模糊匹配、搜索词关联等），在流程上需经过用户体验验收环节（研究表明5个人以上的体验测试，能发现80%以上的可用性问题）等，会有助于提高数据产品的用户体验。

五、数据产品的未来趋势

艾达在《数据产品设计》书中，把数据产品产品分为两类

1、辅助决策型数据产品：通过对数据的挖掘分析和展现，帮助人们进行业务分析、辅助决策的一类数据产品，比如我们常用的报表、经营分析系统、神策等。

2、智能决策型数据产品：可以根据数据分析结果自动执行决策和行动的一类数据产品，比如个性化推荐系统、人工语言智能系统（智能语音客服）、无人驾驶汽车系统等

随着大数据、人工智能、云的发展，第2类的数据产品所能发挥的作用越来越大，也可能是未来的发展重点。

凡是过往,皆为序章，这一年半来的实践，让我对数据产品设计和运营有了新的认识，感谢那些支持和帮助过我的人，期待未来，我能够设计出一款让我感到满意的数据产品。