你以为的产品管理其实是啥诚实地讲, 在我当初刚进入这个行业的时候, 曾经认为产品管理所涉及的内容不过就是绘制原型, 撰写需求, 催促开发人员进行工作而已。后来, 被现实狠狠地抽了几道巴掌。这时候, 才发觉。真正的产品管理, 有九成的时间, 都在处置那些“看不到”的事情。像是, 就在今天上午, 我耗费了足足三个小时, 就是为了去说服销售部, 让其同意把某一个功能从下个版本当中砍掉。他们没办法理解, 为何我们花费了两周时间所做出的功能, 在数据层面上明明有着8.3%的点击率, 然而却依旧要选择放弃。我跟他们讲, 这个功能存在被人点击的情况, 然而, 用户留存率仅仅为1.2%, 并且, 我们的服务器资源, 其中70%都消耗在了这个上面。对方沉默了。这就是产品管理的日常不是创意不是灵感是算账。为什么你的产品规划永远赶不上变化我为这个问题思索耗费了四年时间, 一直至去年年末的时候, 我把团队过往三个季度所做的迭代记录都翻得破烂不堪了, 才发觉了一个能令人崩溃不已的事实: 我们预先规划好的28个功能点, 直至最终按时上线的仅仅只有11个, 其完成率为39.3%。剩下那61.7%呢先是被紧急需求给来了个插队, 接着又被技术难点给死死卡住, 而后还被老板的一句话给完全否定了, 并且呢, 干脆就在开发进行到一半的时候发现用户根本就不需要。就数据而言, 其真实呈现于眼前, 致使我没办法不予以承认, 并非变动的数量过多, 而是我们所制定的规划实在太过“空洞”罢了。在那个季度的时候, 我们的团队平均于每个版本都去变更需求方向2.7次, 每一回变更, 就表征着最少浪费了前序工作的43个小时, 一年过去之后, 这个数字成为了3870个小时。什么概念相当于团队里凭空蒸发了一个半人的全年工作量。所以当下我正在带领新人, 其中的第一课是传授他们如何进行“做减法”, 也就是在规划阶段宁愿削减掉百分之八十的需求, 也绝不能致使开发组做了百分之八十的无用功, 白白耗费精力。优先级排序不是拍脑袋的不少人觉得优先级便是“重要紧急四象限”, 弄出个矩阵, 填进去, 便算完成了。呵。我见识过最为离谱的情况, 那便是存在这样的人, 此人将“老板想要去做的”以及“用户所需要的”, 全部塞入到第一象限之中, 随后竟然发现原本的四象限已然变成了两象限, 为此忙活了三个月, 其结果却是用户数据不但没有上升, 反而出现了下降的状况, 日活数量从十二点四万降至了八点七万。能靠谱地用于排列优先级的方式都是怎样的呢? 我个人所采用的办法是, 针对每一项需求而言, 一定要去回答三个相关问题:这一功能究竟能够带来多少能够进行量化的收益呢? 举例来说, 像是提高转化率, 就算仅仅只有零点五个百分点, 那也是算数的。我于上一个版本当中砍掉的那个功能, 原因在于它所带来的收益最多不过是将次日留存提升百分之零点三, 然而开发成本却需要一百二十个小时。若不做此功能, 用户难道就会死亡吗? 并非是真正意义上的死亡, 然而“是否会致使用户流失”这一红线, 我向来都不敢去触碰。先前存在一个竞品, 为了赶工期裁掉了注册流程里的验证码环节, 结果在六个月内被黑产夺走了37.2万个虚拟账号, 进而直接致使产品数据遭受污染, 整个算法模型都必须得重新制作。当下开展这个, 这个时机合适吗? 今年三月份的时候, 我们真切地早早便完成了某一个社交功能, 然而却执拗地一直等到五月才予以上线, 这是由于一旦到了四月, 用户活跃度整体而言都会下降12.3%, 要是提前发布那就等同于白白浪费宣发资源。这三个问题筛下来能留下的需求基本不会超过总数的25%。需求评审会为什么总变成撕逼大会坦白讲, 我经历到极为惊悚的需求评审会时长满是七个钟头耗费, 其开启于下午两点之际, 持续至晚上九点时分, 最终却未达成任何确定结果, 什么事都没敲定下来。缘故何在呢? 是由于每一个人均立足于自身所处的位置进行言语表达。从事销售工作的人期望内容众多且全面, 专注于技术领域的人渴望易于达成, 围绕运营开展工作的人期盼能够紧跟热点潮流, 身为老板的人则希冀达成融资目标得以实现。谁都没错但谁都不对。随后我想出了一个法子: 每一次评审会的时候, 首先耗费十五分钟将“本级版本的内里目标之物”书写在墙壁之上。其必定应当具备可被量化的特性, 仿佛举个像“把次日留存从32.1%升提到35%这样的例子”或者“把注册转变比率向上拉高2.3个百分点数”。任何一种需求, 一旦它跟这个核心目标不存在直接的关联关系, 那就直接将其打入冷宫, 还不允许再进行讨论。这特定一招, 将评审会的时间, 从平均的4.2小时, 压缩至了1.8小时。关于效率提升的缘由, 极其简单, 那便是大家的争论, 由一个空洞的, 表述为“我觉得这个功能好”, 转变成为了具体的, 呈现为“这个功能对提升留存率有什么帮助”。如果对方答不上来自然就闭嘴了。数据驱动别再自欺欺人了我明了当下盛行讲“数据驱动决策”, 然而说实话, 我目睹了太多的人处于“数据佐证决策”的状况, 何种状况呢, 就是先凭借主观随意地确定了方向, 而后再于数据当中寻觅对自身有益的证据。我自己就干过这种蠢事。在前年的夏季时节, 我笃定地相信着某一个功能必然会走红, 究其缘由是直觉向我传达出用户对其存在需求。然而在该功能上线之后, 我耗费了整整一周的时间来翻看后台日志, 费尽周折地硬是找寻到了一个微弱的信号, 那便是有百分之零点七的用户对这个功能进行了两次点击操作。随后我凭借着这个数字去尝试说服老板持续投入。然后呢两个月之后, 那个功能的使用率, 从百分之零点七, 下降到了百分之零点三, 而之前的百分之零点七, 并非是所需要的信号, 实则是误差产生的数值。这以后, 我为自己制订了一个规则: 任何有关数据的结论, 都必须同时对“为何并非如此这般”作出解释。举例来说, 你不可以仅仅表述“点击率提升了5.1%”, 你同样需要仔细思索, “有没有存在这样一种可能性, 即是源于我们对按钮颜色进行了更改, 而非功能自身出现了改善? ”。数据, 永远仅仅能够告知你“发生了啥”, 并非“因何发生” , 而那后者, 才是产品经理切实应当去思索的事物。关于团队沟通我踩过的那些坑沟通这件事我踩的坑大概能写成一本书。最惨的一回, 只因我于需求文档之中写下了“建议优化用户体验”, 开发组却理解成弄一下字体颜色, 运营组也理解成为增添个活动入口, 结果上线之后三边彼此推诿责任, 那个月团队流失了百分之二点七的用户。此后我变得乖巧了, 所有关于需求的表述都得精准到数字以及逻辑。不提到“提升加载速度”, 而是表述为“首页加载时间由一秒点六降至一秒点一”。不提及“增加投放渠道”, 而是说“接入两个全新渠道, 预估会带来日均一千二百个新增用户”。但最让我有感触的不是这些方法论而是一件事与我共事有段时日的一位老同事, 其所负责的产品, 在三年时间里面临多达五名产品经理更迭, 而他是仅有的成功坚持下来的那一位。我向他询问其中诀窍, 他这般讲道, “并无什么特别的诀窍, 仅仅是每日都同开发组一道共进午餐, 和他们一同饮酒, 倾听他们指责数落我罢了。”。这大约便是产品管理最真切实际的模样, 它并非高高在上的那种战略样子, 不是精美漂亮的原型形象模样 , 而是将一群人的时间, 还有精力以及情绪, 聚集融合在一起, 进而制作成为一个物品。你知道最难的是什么吗想要叫所有人都信服, 你所做出的这个决定, 并非是为了把锅甩出去, 并非是冲着自己的关键绩效指标, 完全是实实在在地为了产品能够变好。这般信任, 是我历经三年又两个月方才构建而成的。然而, 将其毁坏, 仅仅只需一回说谎。最后说点别的实际上, 在撰写此物时, 我的大脑当中时时刻刻都在思索, 究竟什么才能够算得上是优质的产品管理呢。是方法论吗是数据吗是流程吗可能都不是。我感觉那是一种责任感, 是一种你知悉该决策会对几百万人乃至几千万人的日常有着影响, 然而你依旧得有的那种去做的勇气。因为你不做就没人做了。而那些看不见的挣扎、妥协、权衡才是产品管理最真实的面目。
产品经理的隐秘战场：那些看不见的“产品管理”真相
你以为的产品管理其实是啥诚实地讲, 在我当初刚进入这个行业的时候, 曾经认为产品管理所涉及的内容不过就是绘制原型, 撰写需求, 催促开发人员进行工作而已。后来, 被现实狠狠地抽了几道巴掌。这时候, 才发觉。真正的产品管理, 有九成的时间, 都在处置那些“看不到”的事情。像是, 就在今天上午, 我耗费了足足三个小时, 就是为了去说服销售部, 让其同意把某一个功能从下个版本当中砍掉。他们没办法理解, 为何我们花费了两周时间所做出的功能, 在数据层面上明明有着8.3%的点击率, 然而却依旧要选择放弃。我跟他们讲, 这个功能存在被人点击的情况, 然而, 用户留存率仅仅为1.2%, 并且, 我们的服务器资源, 其中70%都消耗在了这个上面。对方沉默了。这就是产品管理的日常不是创意不是灵感是算账。为什么你的产品规划永远赶不上变化我为这个问题思索耗费了四年时间, 一直至去年年末的时候, 我把团队过往三个季度所做的迭代记录都翻得破烂不堪了, 才发觉了一个能令人崩溃不已的事实: 我们预先规划好的28个功能点, 直至最终按时上线的仅仅只有11个, 其完成率为39.3%。剩下那61.7%呢先是被紧急需求给来了个插队, 接着又被技术难点给死死卡住, 而后还被老板的一句话给完全否定了, 并且呢, 干脆就在开发进行到一半的时候发现用户根本就不需要。就数据而言, 其真实呈现于眼前, 致使我没办法不予以承认, 并非变动的数量过多, 而是我们所制定的规划实在太过“空洞”罢了。在那个季度的时候, 我们的团队平均于每个版本都去变更需求方向2.7次, 每一回变更, 就表征着最少浪费了前序工作的43个小时, 一年过去之后, 这个数字成为了3870个小时。什么概念相当于团队里凭空蒸发了一个半人的全年工作量。所以当下我正在带领新人, 其中的第一课是传授他们如何进行“做减法”, 也就是在规划阶段宁愿削减掉百分之八十的需求, 也绝不能致使开发组做了百分之八十的无用功, 白白耗费精力。优先级排序不是拍脑袋的不少人觉得优先级便是“重要紧急四象限”, 弄出个矩阵, 填进去, 便算完成了。呵。我见识过最为离谱的情况, 那便是存在这样的人, 此人将“老板想要去做的”以及“用户所需要的”, 全部塞入到第一象限之中, 随后竟然发现原本的四象限已然变成了两象限, 为此忙活了三个月, 其结果却是用户数据不但没有上升, 反而出现了下降的状况, 日活数量从十二点四万降至了八点七万。能靠谱地用于排列优先级的方式都是怎样的呢? 我个人所采用的办法是, 针对每一项需求而言, 一定要去回答三个相关问题:这一功能究竟能够带来多少能够进行量化的收益呢? 举例来说, 像是提高转化率, 就算仅仅只有零点五个百分点, 那也是算数的。我于上一个版本当中砍掉的那个功能, 原因在于它所带来的收益最多不过是将次日留存提升百分之零点三, 然而开发成本却需要一百二十个小时。若不做此功能, 用户难道就会死亡吗? 并非是真正意义上的死亡, 然而“是否会致使用户流失”这一红线, 我向来都不敢去触碰。先前存在一个竞品, 为了赶工期裁掉了注册流程里的验证码环节, 结果在六个月内被黑产夺走了37.2万个虚拟账号, 进而直接致使产品数据遭受污染, 整个算法模型都必须得重新制作。当下开展这个, 这个时机合适吗? 今年三月份的时候, 我们真切地早早便完成了某一个社交功能, 然而却执拗地一直等到五月才予以上线, 这是由于一旦到了四月, 用户活跃度整体而言都会下降12.3%, 要是提前发布那就等同于白白浪费宣发资源。这三个问题筛下来能留下的需求基本不会超过总数的25%。需求评审会为什么总变成撕逼大会坦白讲, 我经历到极为惊悚的需求评审会时长满是七个钟头耗费, 其开启于下午两点之际, 持续至晚上九点时分, 最终却未达成任何确定结果, 什么事都没敲定下来。缘故何在呢? 是由于每一个人均立足于自身所处的位置进行言语表达。从事销售工作的人期望内容众多且全面, 专注于技术领域的人渴望易于达成, 围绕运营开展工作的人期盼能够紧跟热点潮流, 身为老板的人则希冀达成融资目标得以实现。谁都没错但谁都不对。随后我想出了一个法子: 每一次评审会的时候, 首先耗费十五分钟将“本级版本的内里目标之物”书写在墙壁之上。其必定应当具备可被量化的特性, 仿佛举个像“把次日留存从32.1%升提到35%这样的例子”或者“把注册转变比率向上拉高2.3个百分点数”。任何一种需求, 一旦它跟这个核心目标不存在直接的关联关系, 那就直接将其打入冷宫, 还不允许再进行讨论。这特定一招, 将评审会的时间, 从平均的4.2小时, 压缩至了1.8小时。关于效率提升的缘由, 极其简单, 那便是大家的争论, 由一个空洞的, 表述为“我觉得这个功能好”, 转变成为了具体的, 呈现为“这个功能对提升留存率有什么帮助”。如果对方答不上来自然就闭嘴了。数据驱动别再自欺欺人了我明了当下盛行讲“数据驱动决策”, 然而说实话, 我目睹了太多的人处于“数据佐证决策”的状况, 何种状况呢, 就是先凭借主观随意地确定了方向, 而后再于数据当中寻觅对自身有益的证据。我自己就干过这种蠢事。在前年的夏季时节, 我笃定地相信着某一个功能必然会走红, 究其缘由是直觉向我传达出用户对其存在需求。然而在该功能上线之后, 我耗费了整整一周的时间来翻看后台日志, 费尽周折地硬是找寻到了一个微弱的信号, 那便是有百分之零点七的用户对这个功能进行了两次点击操作。随后我凭借着这个数字去尝试说服老板持续投入。然后呢两个月之后, 那个功能的使用率, 从百分之零点七, 下降到了百分之零点三, 而之前的百分之零点七, 并非是所需要的信号, 实则是误差产生的数值。这以后, 我为自己制订了一个规则: 任何有关数据的结论, 都必须同时对“为何并非如此这般”作出解释。举例来说, 你不可以仅仅表述“点击率提升了5.1%”, 你同样需要仔细思索, “有没有存在这样一种可能性, 即是源于我们对按钮颜色进行了更改, 而非功能自身出现了改善? ”。数据, 永远仅仅能够告知你“发生了啥”, 并非“因何发生” , 而那后者, 才是产品经理切实应当去思索的事物。关于团队沟通我踩过的那些坑沟通这件事我踩的坑大概能写成一本书。最惨的一回, 只因我于需求文档之中写下了“建议优化用户体验”, 开发组却理解成弄一下字体颜色, 运营组也理解成为增添个活动入口, 结果上线之后三边彼此推诿责任, 那个月团队流失了百分之二点七的用户。此后我变得乖巧了, 所有关于需求的表述都得精准到数字以及逻辑。不提到“提升加载速度”, 而是表述为“首页加载时间由一秒点六降至一秒点一”。不提及“增加投放渠道”, 而是说“接入两个全新渠道, 预估会带来日均一千二百个新增用户”。但最让我有感触的不是这些方法论而是一件事与我共事有段时日的一位老同事, 其所负责的产品, 在三年时间里面临多达五名产品经理更迭, 而他是仅有的成功坚持下来的那一位。我向他询问其中诀窍, 他这般讲道, “并无什么特别的诀窍, 仅仅是每日都同开发组一道共进午餐, 和他们一同饮酒, 倾听他们指责数落我罢了。”。这大约便是产品管理最真切实际的模样, 它并非高高在上的那种战略样子, 不是精美漂亮的原型形象模样 , 而是将一群人的时间, 还有精力以及情绪, 聚集融合在一起, 进而制作成为一个物品。你知道最难的是什么吗想要叫所有人都信服, 你所做出的这个决定, 并非是为了把锅甩出去, 并非是冲着自己的关键绩效指标, 完全是实实在在地为了产品能够变好。这般信任, 是我历经三年又两个月方才构建而成的。然而, 将其毁坏, 仅仅只需一回说谎。最后说点别的实际上, 在撰写此物时, 我的大脑当中时时刻刻都在思索, 究竟什么才能够算得上是优质的产品管理呢。是方法论吗是数据吗是流程吗可能都不是。我感觉那是一种责任感, 是一种你知悉该决策会对几百万人乃至几千万人的日常有着影响, 然而你依旧得有的那种去做的勇气。因为你不做就没人做了。而那些看不见的挣扎、妥协、权衡才是产品管理最真实的面目。
