产品经理如何面对失败

1 评论 7584 浏览 16 收藏 9 分钟

编辑导语:作为一名产品经理,或多或少都会经历过失败的产品,失败了不可怕,可怕的是没有正视失败产品的勇气。本文针对数据产品,分享产品经理如何面对失败这个话题,希望给经历过失败的你一点启发。

作为一名数据产品经理,从业至今,多少有过几个失败的产品(我想每个人都至少有一个失败作品吧)。俗话说,失败乃成功之母。失败的案例同样可贵。由于数据产品有一定区别于其他产品的特点,所以今天我们谈产品经理如何面对失败这个话题,也主要是针对数据产品。

一、承认失败

要承认自己失败是一件很难的事情,特别是对于产品经理来说,承认失败在某程度上意味着否定自己的工作。

一定要摆正心态,要知道只有敢于认错,才能纠错。在日常工作中,有很多时候需要产品经理勇敢下决定,但是比较少让我们做最后的结论判断,承认失败是一种结论判断。

二、复盘失败的原因

和你的团队一起去复盘失败原因之前,需要你自己先做一个独立复盘,这是为了不在复盘会上被带风向,团队复盘会很容易气愤低迷,充满了失意气息,或者演变为互相指责,进入不了下一个阶段。

为了避免这些现象,需要产品经理自己先完成初步的复盘,这个复盘就是目前失败是在哪个环节,一般来说可以将产品设计到推广的大概分为以下几个环节,本文列出了几个常见的原因,希望能为大家在复盘时提供一些参考。

1. 产品定位

(1)不是刚需需求判断是源头

我见过启动一款产品的时候做需求调研,产品经理喜欢拿着锤子找钉子,心里在需求调研分析之前就已经有了先入为主的印象,最后需求判断的结论与调研实际情况脱节。

(2)需求没了

公司业务调整,原来的主要业务变为了次要业务;部门架构调整,使用该产品的岗位没了;

有其他部门在你们上线前就推出了更好的替代方案。

一句话,原来有这个需求,现在没了。

2. 产品设计

(1)偏离核心需求

产品设计是否是真实按照需求做的,产品在设计过程中会受到很多干扰,比如上级的期望、业务部门的 KPI,从而导致做出的成品和最核心的需求差异较大,或者重心偏了。

举例:产品核心需求是用数据做生产质量管控,那么数据产品里面应该要提供基于数据质量指标的预警告警、质量问题自动归因等,但是最后全都做成了大而全质量报表和数据分析工具,这就是偏离了核心需求。

3. 产品开发

(1)核心功能未实现/少实现

很多时候为了赶上线进度,产品经理会和开发人员妥协调整产品功能的优先级,这个时候要复盘一下是不是把核心功能优先级调整了导致功能实现的不全、或者没有实现,或者理解有偏差。

(2)想法很好、实现起来很难

还有一种情况,是核心功能实现起来需要较大的技术成本,目前的技术投入条件不成熟,其他的技术方案对核心功能最后的效果有较大的影响,这个影响了产品的效果。

(3)开发周期长、错失机会点

除了赶进度,还有一种是开发时间较长,需求蔓延、需求变更、技术方案变更、研发团队组织架构变动、项目优先级调整等因素导致产品开发周期过长(当然如果你这几种情况都遇到了,产品能上线就不错了),本来是一款填补行业空白的产品,后来上线时已经失去了领先机会点。

4. 产品推广

这个是很多人容易忽略的问题,数据产品和功能产品不一样,大多数都在主流程之外,不影响业务主流程。这类产品一定要有推广、宣讲的过程。应该反思一下,产品没有人用,是不是推广没做到位——需要的人不知道(没权限)。

三、发掘产品的机会点

产品已经上线了,整个团队为此投入了很多的人力、技术去开发。虽然产品效果不好,但是说不定还有“复活”的机会。这个 “复活” 包含 2 个含义:

第一,产品开发过程中留下了哪些宝贵的财富(业务理解、技术组件等),可在其他项目使用;

第二,上线推广、内部盘点时发现了新的机会,对产品进行改造去适配新的需求。

一般来说产品的核心资产有这么几类:

1. 用户产品

初期圈定的用户群,在推广阶段其实已经有一些用户量了,这些用户如果做需求调研,会比其他未接触过你们团队的用户更友好一些。可以考虑还是做这些用户的业务线方向,比如之前是面向电商运营的数据产品,那么可以考虑还是这个用户群的细分场景。

2. 技术组件/数据沉淀

考虑已完成开发的技术组件、数据模型的复用。比如,原有产品沉淀了一个 NLP 的分词组件,这个在其他的项目中是否可以复用;以前梳理的主题数据模型,有哪些场景是和这些数据模型相关的。

3. 业务知识

做完一个项目,从产品到研发、测试,都会对业务背景、业务概念有所了解,包含对应业务系统的数据,这些都是软性的财富,如果后续找新的需求、新的机会,还是和这些做过的业务背景相关,那么能够节省很多的时间。

4. 研发团队

研发团队的能力,是一个组织能力,我们由于当前的产品/项目,已经组成了一个团队,判断团队成员的技术栈和技术能力,也可以得出新的产品/需求挖掘的方向,比如你们团队中有NLP算法工程师,那么和自然语言处理相关的需求和场景就是可以去考虑的。

5. 需求池

最初做产品需求分析的、产品上线后陆续接到的需求,也是一份宝贵的财富,从这些已有的需求中聚合挖掘出新的机会点,比从海量的业务场景中重新探索要节省很多精力和时间。

另外,如果先发现了新需求,也可通过以上这几个角度去看能否将现有产品改造、迭代为适应这些新需求的产品。

四、结论

在一个项目、一个产研团队中,产品经理常常担任小 CEO 的角色,产品是有很强的 Ownship 和成长自驱力的。项目和产品最早期就是从需求调研、产品设计做起,如果产品经理能多一分成功的把握,对于团队和项目来说,会有事半功倍的效果。

对于产品人来讲,如何带领团队从失败中成长、复活,让产品、团队和自己走得更远,是每一位产品经理都应该去思考的。

 

作者:经海路@薄荷点点京东物流数据PM一枚;专注“BI+”,带你发现数据产品的更多可能性;“数据人创作者联盟”成员。

本文由@一个数据人的自留地 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 不错😊

    回复