面对产品的重构，希望每个产品经理不是通过无效的业务沟通去燃烧自己，而是通过靠谱的数据分析达到产品与个人的涅槃重生。
“我不想奋斗了，给我几个富婆的联系方式吧，这20多年我真的是奋斗的够了！”
深夜11点29分，来自我旁边同事阿良的呐喊。
阿良与我皆是产品经理一枚，从业数载，每日既要承接老板的KPI压力，又要处理好与各路开发，UI，业务端的大佬们的需求对接。终日战战兢兢，如履薄冰，产品上的需求总是会触发各个端之间的矛盾，我们夹在中间去做权重平衡。需求提出，产品先行，加班已然是常有的事情。也难怪阿良深夜低吼。
阿良阿良，人本纯良，为什么会被逼成这样呢，一切还要从我们的业务端产品重构开始……
一、产品重构，从燃烧自己到涅槃重生
相信有很多产品人跟我和阿良有过这样的相同经历，进公司的第一个工作就是产品重构，原来的产品烂的不忍直视，还要做产品的整容师，完成产品从凤姐到志玲姐的转变。所以首先我和阿良就要把以前产品的资料整理处理出来，包括PRD和所有能获取到的资料。
不得不说，PRD这种东西掺杂产品经理个人习惯的东西太多，有的产品经理离职了，导致很多功能点都需要自己去找业务和开发验证。
就这样我和阿良把现在的产品功能都整理的差不多了，就要撸起袖子加油干了，这时，我俩都遇到了一个相同的难题：需求很多，先做哪个？这个问题看上去比较简单，只是选择题而已，然而对于产品重构，任何一个小功能的增减都要慎之又慎，如果这次重构失败，对公司，对产品团队的影响都将是无法接受的。我们需要让产品有一种涅槃重生的变化。基于此，我和阿良跟老板开了一个会，老板指点我们要关注数据，但也不能相信数据。
我俩听的云里雾里的就回去确定需求了。对于老板的指点，我和阿良有了两种理解：我认为老板要我们从产品的历史版本的数据中找到产品重构的线索。
而阿良认为老板也不知道怎么产品重构，为了应付我们的提问随便说了数据这一方面，他决定从业务端下手去确定产品重构方向。于是我俩分配了两个业务方向去做产品的重构。
首先，我去找运营同学要来了产品历史版本中的监测数据，包含日活，月活，新增用户，活跃用户，一些埋点数据等。由于我们公司既做2B又有2C的用户，基于这种特殊性，数据有的时候并不是能真正的反映出产品的使用用户的真实诉求。不过我还是根据需求，把每一个需求都根据数据进行了佐证。等到跟业务方开会确定需求的时候，发现竟然有23个左右的需求都是P0，那么都是最高级即没有最高级，我们还需要有更有力的东西去重新划分优先级。这时我拿出了前面整理的数据，其实，数据是可以讲故事的，在各个业务方眼里，自己的需求解决不了就需要提升优先级，可是真正对于2B的用户，他们的需求一直都是很明确的，而我们不能把我们的需求强加到他们身上。而2C的用户， 他们的行为数据更多的也反映了他们习惯性的需求。所以通过数据佐证加用户故事的方式，我们统一了11个最高优先级的需求。
嗯，结果自然是很happy~
阿良就不怎么好过了，从跟业务方确定需求一开始，就被各个业务线大佬洗脑，不停的同意否定同意否定，不仅没有减少需求量，反而又增加了几个需求，虽然这几个需求是公司的隐藏需求，但是产品重构迫在眉睫，现在最重要的是集中精力解决主要矛盾。所以才有了文章开头的低吼。
看到阿良如此，我对阿良说道：“其实针对产品重构，一定要确定好重构的目的，上线截止日期将至，我们首先要确定最重要的产品功能，我们是产品的灵魂，我们不应该被业务牵着鼻子走。而想要说服业务，我们必须拿出让他们信服的证据，而数据，就是我们最有力的武器。少想一点富婆吧，多运用一下数据，你照样可以在未来的20年轻松应对各方需求。”
从上面的产品重构场景中，我拆分出几个数据运用的路径与时间节点：
1) 产品上线前，更关注历史版本中的埋点数据与周期内数据。每个功能点的里程碑，上线后一周内的埋点数据与用户数据最为关键。不止是衡量功能点的情况，更是用来检验产品功能是否能触达到用户，并产生我们想要看到的结果。通过体验友盟的U-APP AI版的Demo,发现有很多数据指标正是我们所关心的。比如用户分析中的添加对比功能，对于我们新的产品功能列入到新的里程碑后，对这个新的产品功能有很强的检验作用。用户增长板块有些地方比我们公司的运营同学呈现的更有层次感，比如对风险用户，价值用户，沉默用户的标注。用户增长这部分也即将是我们公司下一步将要研究的内容，这里也算是给我们一个启示吧。不过，通过体验U-APP AI版，我发现整体看板功能很专业，数据指标也都与我们常用的指标对应，不过我们每个功能上线后都会标注一个里程碑，而通过各个里程牌，我们往往能发现在里程碑阶段中新的产品功能对产品产生的影响，而这是我们产品重构也好，年度复盘也好，分析产品最有用的数据。如果友盟的数据指标中能将指标模块化到里程碑状态，将更能锲合产品的迭代周期。
2) 产品上线中，对于实时数据可能是每天最关心的指标了，而每周一次的数据分析更是扣动每个运营同学与产品同学的心弦。什么用户留存，漏斗分析等都得分析的明明白白的。当然，我们公司每个产品都不是单一存在的，各个产品线都有或多或少的关联，不同产品之间甚至有着包含与判断的关系。所以单个产品的数据实际上是不能反映整体情况的，而不同的产品之间一般存在１对１，１对多的关联关系，而有关这些产品之间关联关系的数据指标往往才能真正的反映一个迭代周期内产品功能的真实情况。所以我们在数据分析时如果能将有关联关系的数据指标结合分析，将对于不同业务线产品经理之间的沟通与方案确定产生十分积极的影响。
生活中，无数个产品经理都有扮演阿良的时候，面对产品的重构，希望每个产品经理不是通过无效的业务沟通去燃烧自己，而是通过靠谱的数据分析达到产品与个人的涅槃重生。
二、产品迭代，从小步试错到轻车熟路
我和阿良进行了产品重构的第一版之后，遵循敏捷开发的路径，开始了小步快跑的状态。
不过不久之后我和阿良都发现了一个问题，我们在产品重构之后会遇到一些坑，可是这些坑其实之前的产品经理已经踩过，不过他们做汇报的时候避重就轻，导致我们没有真正意识到问题的根源。
而当我们查看历史数据时发现有些错误实际上是没必要去再一次小步试错的，而适配于每个公司的产品经验其实数据往往是最有权威性的。像这样被前/离职产品经理误导的例子数不胜数。公司也一直致力于完善整个产品的承前启后的经验总结，而历史数据的判断往往都是由产品经理整理成PRD或者月度总结PPT上面去呈现。
从数据根源上更需要对于异常数据，错误分析极值做出标记并做出每个周期的反馈报告，这样各个端的产品经理看到之后就会有一个统一的意识。而不至于确定出现异常情况出现多次沟通歧义的情况，像这种无效的确认沟通会实际上很占用大家的工作时间。
对于公司方面，每次小步试错之后都会有一个数据的支持，从而避免后面的产品经理或者其他与产品有关的人员继续踩坑，更是公司产品的核心产品经验建设。在我试用友盟U-APP AI版的时候，并没有类似周期性总结报告产生，而实际上每个公司都是有人员流动的，后面的人接手的第一份资料往往是前员工提供的资料，而这个资料有很多主观成分存在。这个时候接手的员工更希望看到一份客观的资料，这份资料更有助于接手的员工抽丝剥茧总结出接手的产品规律。这也能最大程度避免接手的员工被前员工留下的资料所误导。所以希望友盟U-APP AI版能够提供周期性的总结报告，让每一次小步试错都能有所记录，将错误的价值做到最大化利用。
其实在公司工作久了就会发现存在一个信任的问题，原本两个部门的人同属于一个项目之下，可是由于每个人对于产品的解读都有自己的一套理解。这份理解有的是正确的，有些是错误的，更甚至有些是两部分的人都不知道是对的还是错的。而两部分人一旦基于某个点产生了分歧的时候，就会有信任危机，即使面对面确认信息也会产生不信任的现象。到最后还是要拿出公司BI数据当面对质，才能化解这场信任危机。其实每个人都希望工作效率能得到提升，而信任危机往往会影响公司员工士气与整体项目的推进效率。数据结果的整体建设往往是公司内员工公认的解决信任危机的最好方式。而公司外部数据统计工具也具有普遍的公认性，希望友盟U-APP AI版能从服务的公司的角度，帮助公司从小步试错到轻车熟路的产品迭代过程的转变。
三、总结
本篇文章分析了我实际工作中的两个场景：产品重构，产品迭代。实际上这两个场景时时刻刻发生在各个公司当中，针对我工作中的这两个场景中遇到的各种问题，其实都离不开数据的支持。都说产品经理要用数据的结果说话，可是如何利用数据，数据的可持续利用等问题都是每个产品经理每天都亟待解决的问题。而通过前面的场景复现，我也对友盟U-APP AI版提出一些在实际工作中可以起到帮助性的方向：
1) 针对里程碑建设，每个产品迭代都会确定一个里程碑，而里程碑建设又是由数据做基然后才能靠产品去添砖加瓦。所以希望从数据阶段就能融入到公司的里程碑建设当中，每个里程碑作为一个模块，串联出一个完整的产品路径。这样才更符合产品的日常工作，并无论产品最终的形态如何都会有一份权威的里程碑资料作为后面想要了解这个产品的人的分析依据。
2) 针对公司业务线复杂的情况，产品之间本身存在着千丝万缕的联系，而这份联系往往因为负责人不同，沟通不畅，导致产品结果两边不一致的情况。所以针对不同业务线之间有关联的情况需要将有关联的数据进行联合分析，然后得出一个统一的结论，让不同的业务线达成一致的结论，提升工作效率。
3) 针对公司的试错结果传输不畅情况，公司员工对于历史版本情况的分析往往需要一个可值得信任的数据去得出结论。而友盟可以以此为切入点，结合每次产品迭代周期内的异常现象，周期性的得出一个结论报告去供公司产品人员存档。并针对本次迭代周期出现的问题得出一个公认的结论，这样才算是真正完成了一次小步试错。
经过前面的种种事件，阿良终于不再奢望富婆，以数据作为导向，做好产品的里程碑建设，何愁不能做好产品呢，升职加薪还会远吗？真好，我又看到了那个纯良的阿良。
作者：宋恒达
本文为「人人都是产品经理」社区和友盟＋联合举办的“2019「友盟杯」数据分析大赛”中参赛作品，未经作者及平台许可，禁止转载
本文部分数据有脱敏处理，非全部真实数据
有关产品测评大赛合作事宜，请联系邮箱：denis@woshipm.com
网友评论