最近给几位数据开发转数据产品经理的同学做相关辅导，发现研发转产品在需求挖掘和产品思维方面普遍是短板。对于研发转产品顺利上岸后，如何才能提升产品能力呢？

　　一、首先是关于产品思维的刻意训练

　　数据产品经理毕竟也是产品经理，所以不管数据基础怎么样，掌握产品的流程化思考方式，开展工作会更加顺畅。虽然说产品思维这个词非常老套了，但它的确是会指导你开展工作的通用方法。这里讲的产品思维是作为产品经理的一种思考方式，工作流程和方法论。比如，初入职场，当你还没彻底搞懂什么是指标和维度、数仓模型、字段时，就被安排去承接业务的数据报表需求了，你准备怎么去做呢？

　　1.学会用产品经理的思考方式去做需求

　　产品经理的主要职责就是每天对接和处理各种各样的业务需求。拿到新需求，怎么做？

　　为什么要做这个需求

　　充分了解已有的背景信息，有的老板常提一句话需求，因为自己不懂而不敢去问，吭哧吭哧做完了老板说不是自己想要的，耽误了时间，出力不讨好。

　　用户是谁？

　　每一个产品都有明确的用户群体，数据产品也不例外，而且相较于C端产品的普适性，数据产品的用户还要做个三六九等的划分，谁是核心用户，谁是覆盖用户，谁是潜在用户？

　　解决什么问题

　　作为新人肯定对业务了解不深，知道了用户是谁了，结合有限的背景信息，这个时候就要充分发挥产品经理的沟通天赋了，找业务沟通调研其工作内容，遇到了哪些痛点和问题，期望这个数据产品解决什么问题。

　　需要什么功能（指标和维度）？

　　对于偏工具类的数据产品，如CDP、大数据开发平台等，一方面是结合对用户的需求场景的调研确认目前他们的诉求，另一方面是结合竞品分析，确定产品的功能规划。很多新人往往只是按需实现需求，而在高阶产品的成长道路中，产品规划能力是明确要求的能力维度。所谓的产品规划，主要就是结合产品的定位，确定产品要包含哪些功能要点，再根据当前业务痛点，确定各个功能的优先级，形成短中长期不同版本迭代的计划或者roadmap。然后明确的告诉老板说，我们这个产品要包括ABCDEF的功能点，但是考虑开发资源和时间现状，MVP版本优先做ABC功能。

　　关于需求分析的模型与方法论有非常的多，看些文章了解下四象限、ICE排序、KANO模型就可以了，重要的是要把需求处理的流程先固化下来，然后拿着工作中的具体的需求实践总结，有人说产品经理能力的高低和悟性有很大关系，这个悟就来自于不断的实践和刻意的复盘总结。纸上得来终觉浅。

　　二、其次项目管理推动产品落地流程和方法

　　在敏捷项目管理理论当中，把70%项目失败的问题归结为流程的问题。经过多年的实践发现的确是这样。因为产品经理是依赖于他人完成产品方案的落地。协调和管理跨职能的项目团队是日常工作的重点之一，否则设计的方案再好，上不了线也是尴尬，没有业务价值的输出。

　　在项目管理领域有专门的PMP或者敏捷开发的ACP认证。所以想要完全学习完所有内容还需要花很多时间的。但是掌握最核心的流程和要点就足够日常使用，加上自身项目的实践总结，沉淀出适合自己的项目管理方法。

　　如何管理需求

　　面对各个业务部门的各种数据、产品需求，要避免忙成陀螺但还被业务吐槽。所以，要学会利用需求管理工具，把接收到的需求统一管理起来。很多项目管理软件比如Trello、Ones、leangoo等，最次的就是自己用excel了，团队共享不太方便而已，但自用足够。目标是自己清楚地知道有多少需求待处理，优先级是什么，何时需要找业务沟通确认，已经排期或者上线的需求定期做好信息反馈，避免等着业务来问排期。出现延期更要做好沟通，这样才会成为业务眼中靠谱的人。而不是提了需求石沉大海。

　　怎么跟项目？

　　产品一旦排了开发资源后，就是日常的项目管理和开发跟进工作了。澄清需求几乎是每天都会遇到的，除此之外。要学会在一些关键节点组织会议，并且利用透明的力量同步项目进度、问题及风险。

　　项目启动会

　　重大项目需要单独召开启动会，务虚为主。主要目标是获取授权，抢占资源，有时需要打鸡血，比如这个项目是公司战略重点，多跟开发“洗洗脑”，做好了大家一起吃香喝辣。

　　需求评审会

　　产品经理不得不开的会议包括：和业务的需求确认会，和开发的方案评审会，和团队的需求排期会。很多产品经理最怕开需求评审会，因为怕被老板、被开发、被业务Diss。首先从心态上，要做好准备，评审会的目的就是要找出需求不明确和不合理的地方，在方案环节尽可能考虑周全，避免上线之后不满足需求，如果评审会一团和气，出事后甩锅于事无补。其次，要在每一次被Diss之后做好总结，为什么我设计方案的时候没有想到，没有想清楚。下次要尽可能规避，就像高中时有些数学题经常有陷阱，有了错题集不断强化后，下次就不再犯同样错误。此外，在产品方案设计环节，可以提前和业务沟通，和开发提前讨论技术方案，问题前置化，减少评审会上的问题数量。最重要的一点，就是自己在设计产品方案和PRD时，要不断问自己问什么需要这个功能，这个按钮，为什么放到这里，而不是其他位置，自己先Diss自己，减少被别人Diss。知彼知己百战不殆，还要吸收竞品分析的结论，有的时候你的一句，这个方法竞品是这样做的，但是有123个问题和缺点，是不是比其他的解释更有说服力呢。最后，能用数据量化分析的就要用数据说话，毕竟是搞数据的嘛。

　　项目站会&周会

　　敏捷开发中，团队成员会有每天的站会，主要目的是沟通和澄清问题，说下主要进展和计划，提高团队成员沟通的频率，互通有无，及时发现和解决问题。切记不要沦为形式。

　　项目汇报的频率与技巧

　　常规汇报：对于重点项目（老板们都非常关心）尤其要做好向上的汇报和信息同步。如果周期2周内，可以每天汇报关键进展，IM群或者邮件均可。3周及以上的长周期项目至少要按周汇报。这样老板就很放心，不管他关不关注，至少你主动沟通，不仅曝光度高，而且老板会觉得你非常靠谱。

　　问题汇报：做项目有风险在所难免，尤其是项目初期不确定因素非常多，出了问题首先自己要快速搞清楚大致问题，初步判断严不严重，如果觉得对项目进度、项目范围有影响，就要及时向上反馈，老板最不喜欢的就是别人都知道出问题了，他却是最后一个知道。提前沟通可以获取相关的资源支持，哪怕是准许延期的许诺。

　　需求变更管理

　　唯一不变的就是变化。作为产品经理不管是和业务还是和研发沟通，切记一句话的口头需求和随意的变更。尤其是开发过程中，涉及到业务流程等内容的变更一定要记录存档，对主流程和研发进度有影响的，严格遵循变更控制流程。否则，一旦项目失败或者出了问题，产品和开发扯不清楚。研发说产品让我这么改的，产品说我是让你那么改的。

　　产品上线运营及推广

　　项目测试开发工作完成后，在正式上线之前，找核心用户或需求方做好用户接受度测试，避免上线后，用户大面积吐槽，到时候就晚了。另外，产品上线前，需要考虑数据埋点，统计功能上线后的使用效果。一方面是证明你这次迭代的价值，用数据说话，另一方面就是用数据驱动产品迭代了。同时，要记得收集用户的正向反馈，毕竟季度述职有的时候需要用户视角说你做的好不好。

　　三、总结

　　想成为业务、研发眼中优秀的数据产品经理并不容易。不仅要产品素质优秀，还要有扎实的数据能力。具备其一，可以做数据产品经理，但只能称之为靠谱或者技术能力比较强。而两者都不具备时，不仅自己上班如上坟，还要饱受领导、对接研发、业务的各方吐槽和Diss。