1.3　从数据技术转型做数据产品经理——从具体到抽象

1.3.1　从数据技术转型的困惑

在写作本节内容之前，我走访了几位符合这种情况的老朋友。

大家的转型原因答案各异，大体集中在两个方向：“写代码写烦了”或者“因为之前遇到的产品经理不靠谱”，并且说过之后都会哈哈大笑。

第一种回答换一个表述就是，“想向另一个方向扩展自己”；至于第二种回答，我会说：数据技术“吐槽”数据产品经理不靠谱，决定自己来做，和算法工程师“吐槽”数据库里的基础数据不好，便决定自己做，有什么本质区别吗？于是大家又是一阵哈哈大笑。产品经理和数据技术之间的“相爱相杀”在数据团队同样存在，既相互“吐槽”又相互合作。幸运的是，在我的经验里，大家在磨合期过后总是能变成好朋友。

至于遇到的困难，答案依旧高度统一：之前没想到数据产品经理这么累心。至于什么叫“累心”，继续聊下去就会发现，仍然是思维方式的转换问题。

我有一位曾经合作过的数据技术好友，具有3年ETL经验，现在转型做了数据产品经理。他讲话非常实在：以前做技术时，觉得需求不明确或者实现太复杂，可以和产品经理吵架（产品经理就是我）。现在自己找业务人员聊需求，再自己定义需求，就发现一颗脑袋很难想完全，有时需求沟通过后以为自己聊明白了，定义过程又发现各种细节需要确认；需求提交之后很快就发现不够用了，又要变更；自己觉得不合理的，或者数据现状实现起来过于复杂的，直接告诉业务人员，居然还被投诉了。后来就只好一遍一遍地来回确认，确认过程中就开始自我怀疑了。

我和他有这么一段对话。

我：你描述的困扰，总结成一句话就是你不咋会聊天？

他：嗯。可是，你也不咋会啊，经常一句话怼死我。有话直说效率高，不是你说的吗？“吵架是最快的产出方式”也是你说的！

我：你聊方案时怎么不这么听我话！那是跟你们磨合好了之后，（我）才会随便挑战。“吵架产出高”有前提条件，就是双方没有认知隔阂。要是你说前门楼子，他说胯骨轴子，吵架除了提升情绪值，没有任何意义。

（友情提示：个人风格，请勿模仿。）

他：哦，那我记得你也会控制不合理需求吧。

我：当然会，但基础是要为对方解决问题。有些问题也可以暂时不解决，但是要有明确的理由和共识。最起码，需求的合理性和实现难度要分开判断。

他：以前产品经理判断需求合理性，我判断实现难度，是因为产品（经理）没有判断实现难度的能力。（坏笑）

我：（白眼）两个判断的能力合并在你身上，不代表可以不区分判断。需求本身的合理性判断是基于对业务问题的解决，实现难度的判断是基于现状和技术难度。你不能说因为代码不好写所以需求不合理。

他：那肯定是。

1.3.2　从数据技术转型的关键点

上面的聊天中我们聊到了两个点，沟通技巧和需求判断。

大家都知道，对技术的充分理解是数据技术出身的人的绝对优势，即在提产品需求之前就可以预先评估可行性和难度。这种判断力对很多做产品的人来说是一个难题，但对这些从数据技术转型做产品的人来说却完全不是问题，甚至可以帮技术人员一起想技术方案。但是与此同时，他们会非常容易在设计还没完成的阶段，就一头陷入实现过程的细节里：有时候需求还没聊完，需求分析和产品设计都还没做，满脑子已经是“这个SQL怎么写”了；甚至会直接告诉对方：这个实现不了。这么做的缺点是：即使判断本身是准确的，但这种反馈信息的方式也只会使对方收到“拒绝”这个信息，因为业务人员通常无法理解你用技术语言描述的原因，因为不理解，就接收不到“实现不了是有原因的”，只接收到“产品经理说做不了”。

这里并不是说所有从数据技术转型的数据产品经理都有这个问题，而是说，技术和产品的团队内沟通方式和与用户之间的沟通方式有很大差异，需要有一个切换过程。这里的用户指数据产品的用户，包括公司高层、数据分析师、运营主管等角色。具体的沟通方式会在第3章详细论述，大概的原则是“需求本身是否合理”和“现状下是否能实现”分开判断。需求不合理的就不实现，需求合理且现状可实现的就是眼下要做的，需求合理的但是现状不可实现的：明确问题是什么？是否解决？大概什么时候解决？图1-3-1描述了大概的判断过程。

与功能描述的具象化不同，业务人员对数据的使用需求，在大多数情况下都很难具象（这和不同的公司、不同的部门处于的不同阶段也有关，数据体系化程度越高，业务人员和数据产品经理之间的需求沟通越顺畅）。对需求的判断基于对业务的充分理解。考虑大多数公司的现状，我相信在数据需求的沟通中很难直接定位到“我要这些指标和这些维度，来解决这些问题”的程度。挖掘业务的真正需求就成了数据产品经理最大的目标之一。

如果我们是数据技术人员，就可以要求：数据PRD（产品需求文档）必须具体到“可以拆解至可执行任务并完全支撑测试用例定义”的程度。但是当我们成为数据产品经理时，则只要求业务方“能讲明白要使用数据解决什么样的业务问题”即可。相关的指标定义和维度定义，均可以由数据产品经理定义并和业务人员达成共识。如果组织里有数据运营的角色，那么指标定义和维度定义的过程可以由运营角色承担，但是共识问题的过程不可缺失。

除了实现需求，数据产品经理还有相当一部分工作独立于需求存在——这部分工作的目标是“客观描述”，而不只是“满足需求”，这一过程需要通过自己对业务的充分了解来抽象出可用性高的数据模型或数据产品。这种工作模式就和一些技术角色的工作方式产生了本质不同。例如，“指标体系搭建”和“数据质量监控”，就是可以独立于“需求”存在的。以指标体系为例，指标体系对“业务”和“业务之间的关系”的描述基于一定的目标和方法论，覆盖但不仅限于满足业务需求（具体过程见第4章）。这种对业务的整体认知不同于任何单独的业务视角，有些人喜欢管这个叫“上帝视角”或者“顶层视角”，而我更喜欢叫“画家视角”。在这样的视角里，既不能受限于需求，也不能陷入具体细节，而是需要“完整且客观”。这就像是一个画家在面对一个客观事物时，目标是尽可能地描绘它，无论怎么画，它都在那儿，不会改变。

图1-3-2描述了指标体系和业务的关系。这一关系意味着只满足需求是远远不够的。

每个需求方都有自己的视角和意志，他们各自的视角意味着任何业务角色都无法对自己的业务做到真正的“客观”，更不用说去关注自己的业务和其他业务之间的关系。所以作为数据产品经理，需要在满足业务需求的同时，保证数据对业务描述的“客观”和“完整”。这不仅包含沟通技巧，还需要依靠自己的能力去顶住一些压力，掌握二者之间的平衡。