看到不少同学咨询如何入门数据产品，例如数据产品入门应该学什么、解决什么问题、发展方向如何等。作为专职从事数据产品岗位快三年的同学，对上述问题感同身受。本文从内容型或业务型数据产品实践的角度浅谈下数据产品岗位能力模型、进阶难点、进阶技巧，希望能对有相同疑惑的同学提供一个视角。
数据作为一种生产要素，基于数据的业务应用和服务工具得到不断地延伸，在业务应用上经常会遇到这样的困境：用数据的角色很多，但是都是负责各自的模块，业务应用缺乏有效的数据规划，容易造成业务和数据团队各玩各的，数据烟囱化严重，老板层面更是不清楚相信谁，一个指标多个口径。
在服务工具上经常存在：面向谁做什么样的数据工具能最大化服务边界，缺乏面向一线使用的调研和规划，容易造就千奇百怪的轮子，上报SDK轮子、BI轮子、计算平台轮子层出不穷，但是都较难全面满足业务的诉求。从优化数据角色分工和提升数据效率角度，数据产品岗位应运而生。
1、能力模型
数据产品和传统产品策划一样，首先是一个产品，只是解决的对象和手段与数据强相关。成为一个合格的数据产品依赖很多能力项，我仅列举六条必要不充分的能力项，分别是数据规划、业务应用、平台建设、工具方法、技术理解、综合素质和能力，这些在个人实践中感觉比较重要。
1.1 数据规划
数据规划以最大化业务价值为目标，规划数据的指标体系、数仓分层、数据上报等，制定整个产品具有可复制性的数据规范并且可持续优化，我个人理解最重要是要深刻理解业务和数据链路。
理解业务才能制定完善的数据体系，指明大方向。理解数据链路包含字段上报逻辑、底表ETL规则、指标技术口径，都能极大地保障规划执行的程度和数据的可解释性。
基于数产团队、数产工作内容、数产具体项目的数据规划侧重点不同。
※ 基于数产团队的数据规划，需要通盘考虑业务规划、数据中台规划、团队成员的规划，以确保三方共赢。业务每个季度或者半年会有重点产品，要保障数据产品团队在重点产品上支撑到位。
数据中台是数据产品的协作方，数据规划的落地依赖数据中台协助，因此适度了解协作方的规划以便于在资源调配上达成双赢。团队成员的规划则更多是人尽其才。
※ 基于数产工作内容的数据规划，我归纳为业务应用、服务工具两大类。业务应用包含短期和长期，短期是支撑业务的数据体系搭建，包含从0到1的数据规划、数据上报、指标体系及业务洞察。
长期是优化业务的数据治理，这部分需要长线投入，属于重要不紧急的事情。服务工具则包含两种，既有的平台工具优化和数据需求产品化，后者对数据产品的价值更大一点。
举个例子，搜索业务的需求来源是用户输入的Query，产品同学有各种各样基于Query的分析需求，但是获取Query集合则是靠临时跑数。例如长链条的产品，用户路径点有哪些，分别消费情况如何，要分析每次消费行为的具体路径非常麻烦，重复性需求模板化，再产品化。
※ 基于具体项目的数据规划，我认为更多是了解和洞察产品对数据的需求层次，以便于抓大放小，实现有限时间范围内数据产品的工作价值最大化。需求层次可以从「底线需求」、「够用就好」、「越多越好」、「制造惊喜」四个角度考虑，例如从0到1的项目，底线需求是要有准确的数据，有数据是底线，准是不断调优的过程。
对于数据上报，不是上报内容越多越好，把指标体系抽象出来的有效统计参数完整上报就是够用就好，上报内容越多意味着ETL成本和解释成本越大，出错概率变大。
而对不同角度的产品洞察，越多越好，给产品提供input形成决策参考。但是制造惊喜则是非常稀缺的，通常满足前三者也是一种惊喜。
小结：数据规划上，做到对不同产品、业务、行业有较好的认知和理解，并且提供整体的数据流和解决方案。关键字：业务认知、数据认知、协同能力。
1.2 业务应用
业务应用以为致胜目标达成提供解决方案为目标，需要洞察业务机会，设立业务目标，推进业务问题解决，我个人理解最重要的是保证业务结果可解释、业务过程可跟踪。
数据规划是“抬头看路”，业务应用则是“低头苦干”。从解释结果、跟踪过程来看，不同角度搭建完善的指标体系是其中最重要的途径之一，例如从OSM角度定义及拆解北极星指标，从UJM角度拆解用户路径，从AARRR角度拆解用户构成，为同一个目标的不同团队提供完整的目标，保障业务策略是为同一个业务目标服务。接下来，分别从创新产品、成熟产品就如何保障业务应用效果讲下我的体会。
创新产品，从0到1，快速验证产品收益是重点，而验证收益的方式通常是小流量实验。因此数据产品的工作包含两部分：搭建数据流，参与实验分析。在实践过程当中，经常发现很多新产品的小流量做多次，过程当中排查出多个原因，其中不乏补充上报，修正口径，调整实验方案等。
如果在实验之前，实验相关数据分析如果能够通盘考虑在数据规划中，能在一定程度上提升实验分析效率，至少不会出现返工。
成熟产品，从1到10，保障业务数据稳定是重点。作为数据产品，在成熟产品中的工作主要是数据治理。厘清业务指标口径，梳理指标技术口径，重新设计数仓或者上报，都是数据治理的工作范围。
数据治理的成果要在较大程度还原成熟产品的原貌，但是也要保障业务指标数据稳定，由于治理一轮导致DAU降低或者提升10%，这很可能会导致业务目标要重新制定和数据刷新。
在年中或者年底阶段对成熟产品的数据成果进行切换会比较好一点，确保不同业务的改动是一致的，减少数据的重刷工作。
小结：业务应用上，数据产品与数据科学的工作侧重点不同，数据产品重点考虑各角色如何使用数据，并且提供对应的解决方案，做到前置洞察业务的机会，解决潜在的系统性问题。关键字：以终为始、分析思维。
1.3 工具方法
数据规划与业务应用，强调把握过程与结果落地。工具方法、技术理解、平台建设与综合能力则更多是强调过程与结果需要依赖的能力。数据产品有产品P序列、数据科学D序列甚至技术研发T序列，无论是哪个序列，实际工作与数据分析密不可分，因此数据分析工具和方法都值得数据产品好好重视。
例如负责实验平台的平台型数据产品，需要对实验原理和数据科学有一定了解，实验平台的产品设计是科学实验规范的产品化，一个科学的实验流程是：
- 选择实验类型，层域AB实验、单层AB实验、Interleaving实验等，以AB实验为例。
- 创建实验名称，确定实验强相关指标，例如期望提升指标、防御指标、观察指标等。
- 选择对应的流量层，是做反转实验还是普通AB实验，不同实验类型对应不同的层域结构设计。
- 计算样本量和选择流量大小，在这里就涉及到样本量计算工具怎么设计，要包含样本量计算的哪些条件，例如指标均值、标准差、相对检测差异等。
- 样本量的计算结果，帮助产品选择实验时长和流量占比。
以上是一个简单的实验创建流程，覆盖了实验原理和实验统计，已经不是一个简单的交互产品了，其背后每一步都是将实验科学产品化。
例如负责业务应用的内容型数据产品，需要对数据链路和数据分析有一定了解，数据链路指数据生产、加工、消费的过程，个人经验是理解生产就多做上报设计和体验，理解加工就多看指标的技术口径和数仓上下游依赖，理解消费就多关注产品场景和分析方法。
在非标准AB实验实践简单介绍数据产品视角是如何分析标准AB实验的，数据产品在以业务应用为致胜目标时的常见的思考：
- 该项目的业务效果最终以什么方式实现，例如AB实验形式，产品自助分析决策。
- 数据产品在该项目的角色是什么，要负责做到什么程度。
- 如果是AB实验形式，AB实验如何设计，看什么指标，指标是如何产出的。此处就是要深入理解和参与该产品的AB实验方案，数据链路是否能复用，不能复用怎么处理等。
- 如果是产品自助分析决策形式，产品最终要看什么指标，指标是如何上报的，新页面模块的数据是否能融入到现有数仓，是否要搭建旁路数仓支持短期决策分析。
以上是一个简单的业务应用项目，根据不同的目标，提供不同的数据解决方案，产出形式不限于原型图，也可以是抽象的数据流，可以是抽象的实验转化链路等。
通过以上两个例子介绍，在工具与方法的能力项上，不同类型的数据产品的相同点是要理解：数据分析方法、实验科学原理、数据链路，下面列举的更像是一个数据产品招聘JD的描述。
- 常用分类方法（lr、决策树、svm、等）、聚类分析、多种统计检验方法（卡方检验、f检验、正态性检验等）、时间序列分析等。
- 精通多种统计分析软件及数据处理技能（如Excel、SPSS、R、python、spark等）
- 实验方法论：理解实验原理和实验方法和实验的分析思路，并可以独立完成实验需求。并且在充分理解业务的情况下，可以寻找最有机会的路径进行假设和实验。
- 熟悉数仓分层和数仓设计，不同产品的数据上报方法，埋点设计规范。
数据产品道、术、器的修炼，没有多少技巧，就是实战。平时工作当中遇到工具与方法相关问题有意识的去积累，日拱一卒还是会有提升的。
小结：数据产品是产品策划，也是数据分析，要具备一定广度和深度。关键字：统计、代码、分析方法
1.4 平台建设和技术理解
如果是中台的数据产品，平台建设的要求会很高，工作重点是策划和营销平台。除了要建设一个能用、好用、爱用的平台，还要想方设法的去推广平台，扩大平台服务边界。
如果是业务的数据产品，更多是站在使用方的角度，推动平台的优化。业务的数据产品在平台建设上有一些需求洞察的优势，能收集更多关于平台建设的痛点。
技术理解是数据产品入门的门槛，在查异动的时候，需要盘点数据研发的代码。在设计上报的时候，需要与前端、终端对齐技术方案和影响路径。如果与搜索、广告、推荐相关的数据产品，对搜广推的技术还是要稍微了解一下的。
数据产品的背景基本上分为三类：技术研发、数据分析、产品策划。技术研发转行数据产品，在技术理解和技术实现上有优势，关注实现。
数据分析转行数据产品，在数据分析与业务应用上具备优势，关注数据应用逻辑和业务应用效果。产品策划转行数据产品，在产品体验和规划上具备优势，如果是平台产品，易用性会得到保障。
小结：数据产品算半个技术产品，技术理解的入门门槛，能将技术和产品结合，做成通用的平台产品。关键字：技术、产品、数据
1.5 综合素质
综合素质这块没有硬性要求，我个人体会是耐心和靠谱很重要。数据产品的工作很琐碎，随时接锅，每天要回答和解决很多数据问题，耐心是一种品质也是一种修炼吧。靠谱则是体现在每次交付、每次询问、每次争论中，注重交付质量比较重要，这里想强调数量和质量的关系，两者不是不能兼得的，可以参考需求层次「底线需求」、「够用就好」、「越多越好」、「创造惊喜」进行精力分配。
一般的项目排期中不会特地排入数据产品的工作量，属于穿插在项目进度条中，因此数据规划与项目协同格外重要，前者是明确要做什么，卷入什么角色，后者是更好的推动落地。综合素质提升没有终点，不同公司文化背景不同，成事的方式也不同，我也还在不断学习当中。
1.6 我的看法
在上述六个条件后，想补充下自己对数据产品成长的一些看法，仅指内容型或者业务型数据产品。数据产品像一个全科大夫，要提升能力，前提是见过很多和很难的数据问题。没有复杂的数据，只有复杂的业务。因此对数据产品而言，业务产品SKU多和业务链路长，有利于打磨数据产品能力。
产品SKU多，意味着产品类型多，例如一个产品有图文、视频、直播、搜索等品类，不同产品类型对应的业务逻辑和业务目标通常不一样，有利于数据产品延展对业务理解的广度，同时也能较快找到不同产品的数据规划的异同点。
例如图文关注时长，视频关注PVVV，直播关注访问人数和时长，搜索关注搜索次数等，不同的北极星指标都有特定的指标拆解逻辑和数据上报方案。如果这些品类都关注时长，如何设计一套对各品类都适用的通用时长上报方案。如果要追踪用户在这些品类中的流转，如何设计一套session机制将用户路径串联起来。
链路长，意味着一次成功的消费路径包含环节很多，对数据产品而言，如何将消费路径的各节点串联，如何搭建有效的漏斗指标和异动框架，都是有不少挑战的。
以打车工具为例，用户输入一个打车定位，匹配路线，选择打车类型，完成叫车，等待交易引擎匹配订单和司机，用户路径比较明确，但是某滴是典型的双边市场，数据产品考虑用户侧、司机侧，也要考虑平台侧。
以搜索产品为例，用户点击框，体现出主动搜索意愿，接着用户如果不输入，有推荐词、搜索历史、猜你想搜等内容帮助用户澄清和激发搜索意愿，如果用户输入，有联想词帮助用户澄清搜索意图，或者直接出现搜索结果卡片满足用户需求。
搜索结果的产品形态随着用户需求变化，例如教育、问答、医疗不同意图的需求满足形式各不相同，这就导致了产品是非标准化的，产品的种类随着用户需求变多了。
不同的产品形态，数据产品要关注的点不一样，总的来说数据是围绕需求、生产、销售三个方面展开，打车需求端围绕着POI，搜索需求端围绕着Query。生产即供应端，打车围绕着司机供应，搜索围绕搜索生态资源。
销售即产品，产品作为一个媒介，将供应端资源通过匹配或者推荐方式销售给用户，保障用户效应最大程度的满足。
好的数据规划是三面一体甚至多面一体，不能只看需求端或者销售端。产品类型越多，产品链路越长的业务，对数据产品的诉求越多，体现在抽象出产品的数据流和可复用的数据规范。
所以数据产品要思考的问题是：你服务产品，需求类型复杂吗？产品品类多吗？交易模式复杂吗？如果都是yes，恭喜你，找到了一个很好的锻炼机会。
2、进阶难点
数据产品作为数据岗位细分方向，不像DS/DA/DE有明确的岗位职责、能力模型、晋升通道，数据产品是一个典型的“三不沾”岗位。
2.1 岗位职责
从岗位职责来看，DS/DA的交付物可以是分析报告，DE的交付物可以是数仓模型，而数据产品的交付物是什么呢？很难用一句话快速来描述数据产品的交付物。
高情商描述，数据产品是数据岗位的门面，相当于全科医生，要懂各个数据方向的解题思路，再将数据问题条件转移给专科医生。低情商描述，数据产品是数据岗位的夜壶，没明确在DS/DE/DA职责范围内的数据问题都可以让数据产品去解决，模糊地带找数据产品，难背的锅找数据产品。
因此，从岗位职责来看，数据产品是指哪打哪，产品和技术都是问题发起方。一名内容型数据产品的岗位职责就是一根线，串联产品从设计到实现的各个线孔，串的不好要挨打，串的好是理所当然。
2.2 能力模型
从能力模型来看，数据产品具备技术或数据分析背景可能会有一些优势。从过往招聘上来看，这个岗位很少对应届生开放，对候选人的工作经历要求比较高。由于这个岗位经常要与技术打交道，因此也常被认为是技术产品。
内容型数据产品面临的问题涉及产品、数据、技术，从产品角度规划形成完善的数据规划，从数据角度思考交付方案，从技术角度考虑串联和实现。
- 产品包含两个方面，一是业务产品理解能力，具备一定的业务sense，能很好地站在业务层面理解产品。另一方面是产品策划能力，能够规划产品的数据和推进落地。
- 数据包含两个方面，一是数据分析能力，数据分析是数据产品必备能力模型，另一方面是数据方案设计能力，这里的方案包含数据治理方案，数据上报方案，A/B实验方案，数据产品方案等。
- 技术能力也包含两方面，一是动手进行数据分析的能力，例如写模型跑数据，能独立不依靠DE自己产出和验证数据能力。另一方面是理解前后端技术及通信过程，从技术角度理解参数的流转。
因此从能力模型来看，内容型数据产品岗位是容器，核心是解决数据问题，手段和交付没有严格规定。
2.3 晋升成长
最后从晋升成长来看，数据产品的从业背景很多类型，有产品P族，也有数据科学D族，还有数据研发T族，数据产品放在上述任一方向都不合适。按数据科学通道晋升，缺少数据科学建模和洞察的深度。按数据研发通道晋升，缺少数据研发的一线代码工作。
按产品策划通道晋升，则是缺少用户洞察相关一线产品的经历。之所以与上述三个方向不完全匹配，主要还是因为数据产品的工作内容决定的，做了很多数据工作，锻炼了一些能力，晋升缺失一点标准。
就这样的一个岗位，如何展示工作难点，如何展示思考过程和能力模型，如何展示岗位长期价值是每个数据产品晋升要面临的问题。
3、进阶技巧
数据产品晋升能否成功的影响因素很多，场内与场外因素都很重要。场外因素包含个人影响力、专业影响力、项目影响力，这些是长期积累的结果，在晋升前没有多大优化的空间。
场内因素包含重点工作复盘、晋升材料编写、临场发挥表现，在晋升前是可以冲刺一下的。回想我两次答辩多轮材料修改惨痛的经历，收获感最大的是准备阶段。
一是集中精力对过往工作做了大量的归纳和提炼，点状经历串联成线，对岗位和能力模型有更深的理解。二是有机会对过去一年的挑战做完整的回顾，提炼解决问题的方法论。从准备过程来看，项目复盘+材料编写，比较重要，这两部分准备充分能在一定程度上提升答辩通过的基础概率。
3.1 项目复盘
项目复盘是晋升材料准备第一步，选对复盘方式比较重要。在晋升这个场景下，复盘公式=能力模型+材料框架。不同晋升通道都有对应的能力模型，在罗列项目时，有必要与能力模型做一下匹配，看下是否都体现了。
根据前文的数据产品能力模型，数据规划、数据分析能力、业务应用效果、技术理解能力都很重要，内容型与平台型数据产品在工具及产品规划能力上会有侧重点。
成为一名五边形战士很难，但是明确的长板优势有助于体现材料中的亮点。这里想着重强调下数据规划和技术理解能力，数据规划能力有助于建立个人在项目中的影响力，技术理解能力有助于体现个人专业能力。
通常在项目kickoff阶段，各方向都会有人来leading项目落地，数据产品通常会承担数据方向的接口工作。数据产品岗位算半个技术产品岗，新技术方案可能引入数据问题，但是需要数据兜底，因此理解技术并且从数据角度去解决也是能力模型的体现。
晋升材料框架则是围绕一个完整的故事展开，典型的框架是What+Why+How。
1. 做了什么？梳理历史项目，A4纸思考法，将过去项目都手写出来，列出难点，解法，收益，方法提炼。强烈建议脑暴梳理阶段用笔和纸，不要用电脑。
2. 为什么做？建立项目与业务关系，数据产品工作主要是围绕数据展开，但是评委不一定是数据同行，直接讲工作可能很难有代入感，但是讲业务逻辑中遇到的数据难题和数据解法，是可以引起评委共鸣的。
数据产品工作支撑的业务和项目很多，讲清业务、产品、目标、数据飞轮之间的关系是第一步，这一步帮助评委建立框架，同时引出数据团队及数据产品工作的重要性。其次再是对数据产品工作中的重点项目进行描述。
3. 怎么做的？拎出重点项目，找到一个或者多个项目，一是有业务收益并且具备一定难度和影响力，二是自己在这个项目中充当了主力并且解决了核心问题，围绕这样的项目进行晋升材料编写。
方法论的提炼大体围绕了类似场景、类似问题可以复用的数据解决方案，例如新产品从0到1、成熟产品从1到10的数据体系搭建和数据治理方法等。
3.2 材料编写
材料编写是晋升准备中最重要的一环，最耗精力和时间。晋升答辩是典型的评委视角，因此晋升材料不要围绕我想呈现什么，而是评委看到什么更好理解展开比较好。从与评委交流来看，评委更倾向于看到一个故事完整，逻辑自洽，结果量化的陈述。
材料编写参考先搭框架后补细节的顺序进行，框架是外在逻辑，帮助答辩建立框架。细节是内在逻辑，帮助答辩厘清疑问。在着手写材料前，可以研究下其他人怎么写的（强烈推荐揣摩学习别人的思路），大体是“比学赶超”的思路进行材料编写。
这里有几个常见误区：
- 为了炫技而炫技：不考虑评委是否清楚自己业务或者技术，把自己认为炫酷的地方大讲特讲，自己体验感拉满，实则隔行如隔山，评委云里雾里。
- 不讲人话讲黑话：通篇都是描述性词汇，缺乏思考过程和难点介绍，项目成功不是一个人的功劳。
- 只讲战功不讲武功：战功包含项目成果、个人成果等，但战功不等同于武功。项目成果汇报与晋升答辩材料的逻辑不一样，前者着重强调目标与成果，后者强调挑战与思考。
- 脱离业务的数据产品答辩：我最开始很苦恼的一点是做了很多事情，但是与业务有什么关系？我后来总结了一个通用模板，比较适合数据分析与数据产品方向的材料编写。
简单来说是：先讲业务背景与业务目标，其次是量化业务目标与指标拆解，最后是所有的数据工作都是围绕着业务的北极星指标达成、业务过程指标的优化和提升展开。
材料编写的技巧很多，第四点我认为是数据产品晋升材料准备的核心，一是建立了框架，讲清了数据在业务中的角色。二是建立了目标，讲清了数据工作的价值。
4、结尾
数据产品是一个相对小众的岗位，但是在每个业务或多或少都有几个做数据的产品同学，大家面临的问题都不太一样，以上是从业务型或内容型数据产品视角浅谈下我对这个岗位的理解。刚接触数据产品工作，收获了不少数据、产品、技术相关的经验，把经验分享出来也算是回馈吧。一家之言，多多交流~
作者：makinochen，腾讯PCG产品策划
