如何建立自己的销售数据库（如何接手数据产品）
如何建立自己的销售数据库（如何接手数据产品）这种情况实际上为最优的解决方案，原业务负责人的存在会给你流出充足的适应期，保证你在接手业务的时候可以得到足够的背景和知识储备支持。同时，最好要求原业务负责人发一封变更通知，这会帮助stakeholder快速和你建立关系，以便接下来工作的开展。这点很重要因为这个业务是从别的负责人转给交给你，那么他一定已经建立了一个较为稳定的合作伙伴，那么你需要快速的找到这个原负责人，并将他的知识储备进行转移。其中需要快速搞清楚以下几个事情：那么如何能够快速的了解自己所不熟悉的产品业务并保证最小程度上影响产品交付，这对产品经理来讲是一个非常大的挑战。笔者希望分享个人最近的经验，来分享一些实操过程中碰到的问题以及解决方法。希望能够帮助大家快速将一个看似杂乱无章的新的业务数据产品，进行结构化的梳理并快速接手并建立高效的工作模型。作为数据产品经理接手新的业务时，首先你需要知谁是你的stakeholder。 把这个问
当数据产品经理中途接手一个新的业务数据产品时，如何快速理解产品内容以及产品逻辑，并做出结构化梳理，快速接手建立高效的工作模型呢？笔者将为大家介绍一些方法，希望对你有所帮助。
背景
数据产品经理在实际工作中需要支持不同的业务线，这其中存在着很大的业务隔离。
然而由于各种原因， 比如公司的组织结构变动，人事变动或者个人的职能变化，公司和团队会要求产品经理们快速接手一些新的业务数据。
那么如何能够快速的了解自己所不熟悉的产品业务并保证最小程度上影响产品交付，这对产品经理来讲是一个非常大的挑战。
笔者希望分享个人最近的经验，来分享一些实操过程中碰到的问题以及解决方法。希望能够帮助大家快速将一个看似杂乱无章的新的业务数据产品，进行结构化的梳理并快速接手并建立高效的工作模型。
01 谁是key stakeholder（利益相关者）？作为数据产品经理接手新的业务时，首先你需要知谁是你的stakeholder。 把这个问题搞清楚了之后，你其实已经完成了50%的业务交接。因为只要清楚你的客户是谁，其实就锁定了你的范围。
02 如何快速定位业务的核心stakeholder呢？a. 自下而上——找到业务的原负责人，询问他所掌握的业务知识
这点很重要因为这个业务是从别的负责人转给交给你，那么他一定已经建立了一个较为稳定的合作伙伴，那么你需要快速的找到这个原负责人，并将他的知识储备进行转移。其中需要快速搞清楚以下几个事情：
- 谁是主要的合作伙伴?
- 每个合作伙伴的主要职能?
- 每个合作伙伴的主要诉求？
- 他们接下来的长期目标是什么？
- 我们的team在为这个长期目标中扮演着一个什么样的角色？
- 他们接下来短期的目标是什么？
- 有哪些重要的产品我们在为他们维护以及主要的问题和挑战？
- 我们已经承诺的近期高优先级的产出列表？（这点很重要，这是快速和stakeholder建立关系的重要指标）
- 已有的合作模式（周会/月会/计划会议等）
- 已有的合作中存在的问题。
- 索要已有的业务/产品文档。
这种情况实际上为最优的解决方案，原业务负责人的存在会给你流出充足的适应期，保证你在接手业务的时候可以得到足够的背景和知识储备支持。同时，最好要求原业务负责人发一封变更通知，这会帮助stakeholder快速和你建立关系，以便接下来工作的开展。
b. 自下而上——缺少背景
如果原负责人已经离职，那么在完全没有背景的情况下，所有的情况将变得复杂的多。
笔者这次的情况就是原业务负责人和原开发团队已经全部离职，笔者接手的时候发现原有的所有连接已经断开，需要重新来构建合作模型。
下面介绍了在这种情况下笔者如何获取所需要的信息完成业务梳理：
- 你需要获得新的开发团队的大力支持。通过接手已有的产品，尽快理清产品线。 这点非常重要， 因为如果原团队的代码维护得当， 从开发代码中以及维护历史中可以得到大量的线索，并猜测重要的产品。
- 快速掌握已有产品并了解其核心价值。 这点无需赘言，每个经理都需要先了解自己已有的产品。
- 寻找原负责人的邮件，查看收件人并提取可能stakeholder列表。 这点在实际操作中帮助笔者以最快的速度，确定了第一轮的会议列表。笔者通过原同事的离职邮件，寻找到了非本组的同事，将其所有人的只能部门于产品进行交叉比对，锁定了第一轮的接洽以及主题。 事实证明，这个在非常大的程度上帮助我们锁定了主要的合作伙伴。
会议， 笔者在完成上述三项后，很快的和主要的stakeholder开始了第一轮会议，笔者的主要问题会包括：
- 介绍本部门的变化
- 了解其所在部门业务
- 了解过去的合作模式
- 了解本部门的业务需求
- 管理好用户的期望以及确认最高优先级（这点非常重要，因为在接下里的2-3个星期， 团队的所有侧重都会在熟悉接手已有产品， 产品经理很重要的职责是告知相关方接下来的产出会受到影响）
- 咨询是否已知其他stakeholders （很多时候， 需求的stakeholder可能为多个人，而了解到这些人很大程度会帮助你安排接下来的会议）
- 下一步计划 （笔者在这里不建议在第一次会议室就确定合作模式， 因为当你没有一个完整的业务理解的时候，过多的承诺合作会导致过量的会议，很大程度的影响你的工作并吃掉你的资源。 这里建议承诺一次性的follow up meeting，时间大概在2-3 周后， 因为那时你会有更好的业务理解并定义合理的合作模式）
- 文档分享 （年度计划， 业务介绍， 过去的邮件等）
整理并理解本团队核心价值，并确认下一步计划。完成第一轮的会议后， 笔者了解到stakeholders的需求会有很大程度的重叠，理解后发现需求会落入横向的基础支持以及纵向的业务专门支持两个维度。 而这个模型实际上会有很大的扩展可能，所以有和更多的业务方团队进行沟通的必要。
扩大会议。 笔者通过于第一批用户进行沟通后， 锁定了未在名单上的更多参会者， 对只能的解读和产品的匹配，确定下一批会议的参会着名单。于是重复上两步的操作，直到完成了所有的产品矩阵和核心stakeholder的匹配。
收敛 x 高效。 在完成了对主要的stakeholder的收集后， 需要确定接下来的产品方向以及合作模式。 笔者最近经历的这个case有15 主要的合作伙伴， 如何能高效的管理关系并实现已有资源的产出最大化而不是迷失在海量的需求中，这个会在下一篇文章中讲到。
c. 自上而下 – 如果你在这次业务转移时，完全没有任何线索，那么如何能够快速关系？
这个时候笔者建议关系的建立需要选择自上而下。产品经理需要快速的将产品情况整理，并信息提供给领导层，让其帮助你快速与合作方领导层进行对接， 确认对方组织内的沟通负责人。然后可进行如上的对接。
这个方法的好处是很高效的实现需求的对接，但是同时你实际是将所有的压力推给了你的上层，可以适当使用。
d. 被动型 – 等待需求来临
这个场景有些风险，但是笔者确实是见过很多这类的案例。 实际上就是等待stakeholer持需求来找到产品经理，这个时候产品经理与其进行对接。
这个方法的好处在于复杂的沟通成本使得找到你的客户都是真正的需求方，但是同时如果沟通成本过于高昂，可能会失去一些潜在的客户机会。 团队层面的话，业务方也会认为该团队在这次组织变更中缺少存在很大的管理疏漏，没有明确的负责人，过于混乱等一些负面评价。
下一篇文章会主要聚焦在当你已经找到主要的stakeholder后，如何能够快速建立高效的工作模型，以及其中会碰到的主要挑战。
该文章主要为个人实践中的心得，如果有什么问题的话欢迎交流 pm_stanley@163.com。
本文由 @Stanley 原创发布于人人都是产品经理，未经作者许可，禁止转载。
题图来自Unsplash，基于CC0协议
