避坑参考:产品向上要突破的制约因素

0 评论 5764 浏览 3 收藏 15 分钟

日常工作中,产品新人容易陷入两个认知陷阱:「弱思考」与「凭直觉」,它们有着内在的强关联,很多时候都是有机的统一。本文作者结合两个产品案例,分享了一些关于向上发展的思考,希望能给你带来一些启发。

问题清单,往往就是机会清单。

最近这几周我们为了冲刺一季度KPI,“英明神武”的领导把工作安排的那是体体贴贴,比黑色星期四的超级大满贯还丰富,咱不能说是996,只能说是接近007,连生产队的驴看了都直打哆嗦。上周有一个产品同学选了咨询服务,他和镜同学进行了系统性的交流讨论,期间也提到了不少产品专业知识和职场困惑,我觉得有些问题很典型,答案也很有普适性,便想和大家分享一二。

尤其让我印象深刻地是,他还特别准备了问题清单,结构层次也很清晰,而我们都知道:问题清单,往往就是指向答案路径的机会清单

因此,今天熬夜复盘下沟通内容,发现对我们产品经理最有启发,也是很多产品新人最容易陷入的两个认知陷阱:「弱思考」与「凭直觉」

严格来说,「弱思考」与「凭直觉」有着内在的强关联,很多时候都是有机的统一:「弱思考」往往催生「凭直觉」,「凭直觉」也往往受制于「弱思考」

其实在职业发展中,我们有很多产品工作做得不够完美,背后的底层逻辑往往都是懒于思考、弱于思考,因为,在这样的背景下,即便是有成熟的产品方法论做行动指南,也无济于事。

而关于凭直觉,镜同学则认为这是最常见的产品认知错误,比如,我们在很多产品需求调研时,往往会“自以为是”的凭直觉为需求设定自我标签,俗称闭门造车。

我记得,之前给大家也分享过37 signals关于“正确决策”的38条铁律,其中就明确提到“正确决策要基于数据,而不是凭直觉”,对了,37 signals还出版了一本畅销书,就是我反复推荐大家阅读的那本《Rework》

不妨试着回忆下,你们之前的公司决策,是不是有不少是“凭直觉”,而非基于数据呢?

不妨试着回忆下,你们之前的个人决策,是不是有不少是“凭直觉”,而非基于深思呢?

因此,镜同学想结合上周的两个产品案例,分享一些关于向上发展的思考,希望能带给你一些启发和参考。

避坑参考:产品向上要突破的制约因素。

01 运营反馈需求:用户想要删除系统数据

上周我们产品运营同学向我们提交反馈了一个需求:企业用户想要删除掉系统中“待办”、“整改”的系统数据,请我们产品经理设计需求,研发同学执行下开发任务。

这个需求背景是:企业使用我们的信息管理系统,他们的上级监管部门要检查企业的信息化使用情况,但他们系统上存在很多待办数据、整改数据等,这些数据暴露出企业安全生产管理的执行不力,因此,这个企业就想要我们帮忙删除掉这些数据。

镜同学相信,应该有不少B端产品同学都遇到过类似问题,当时我们一个产品经理在群里收到该需求后,不假思索地就答应了,还凭直觉承诺当天就会完成产品设计,当然,这类技术性需求本身并不复杂,只要定义描述好需求后,开发同学分分钟就可以搞定。

听完该产品同学的反馈汇报后,我有两点清晰的感受,一是该同学工作很积极,响应很快;二是,该同学掉入了“弱思考陷阱”,越是简单的事越容易凭本能、按感觉去做事。

我便引导着问他,在正常的产品设计流程中,收集到需求之后应该做什么?他回答说,应该先做需求调研,论证需求

是的,他很清楚需求流程,也具备方法论,只是忘记了思考,由本能主宰了理性,凭直觉做出了行动决策

那我们多维度论证下这个需求:从技术实现上来说,并没有任何难度,但从公司价值来说,我们作为技术服务的供应商,我们竟然能删除用户数据,帮助用户“造假”,既违反用户隐私,也有损公司口碑。

从需求调研本身上来说,这就是典型的“伪需求”,既没必要做,也不能做,更是技术性公司应该坚持的底线,而从产品同学的思考逻辑来看,他并非不知道需求调研的方法论,也不是没有能力识别,而是,在这个小需求面前,忽略了“思考”的必要和价值。

所以你看,弱思考,往往会导致流程性的错误

02 客户提出需求:想要批量开通用户

大家都知道,在日常工作中,产品经理与客户沟通需求的场景非常普遍,用户往往也会反馈很多有价值的真实需求,而有些需求通常很着急,做完整的产品设计则会耽误用户使用。

比如,上周我们的机构客户就提出一个需求,他们在使用我们的一款SaaS产品,其中有个功能是可以添加自己所服务的企业,当时,他们临时有个集中汇报会,需要快速为即将要服务的200多家企业开通账号

不过,按照现有的功能,他们需要逐一去添加账号,为服务的企业开通系统,这样很慢、效率很低,我们系统又没有批量导入功能,他们就希望我们通过技术手段后台为这些企业用户批量开通下账号。

这个需求不同于上面删除用户数据的案例,该需求是有真实价值的,只是我们产品暂时没有该功能,因此,我觉得这样没有问题,就没再深度思考,作为产品研发中心负责人,我就准备随后安排后台开发人员进行技术处理。

刚好我们要开周总结会,我就顺便把该事情给总裁汇报了一下,领导当时就强调:先不要直接答应客户,让客户提交一个书面申请,授权我们为他们批量开通账号,这样既能解决客户问题,还能避免后续扯皮,更能对外表现我们的技术张力和专业正规性

果然,客户并没有反感,也没有认为我们的“多此一举”,反正发来信息赞赏我们的技术管理很专业,也很配合地提交了“授权申请”。

事后我总结,我在这件事情处理上认知有偏差,单纯认为是缺乏经验也不准确,事实上,我当时深度思考不足,也在凭直觉来处理新事物,至少没有寻求多方沟通的主动意识。

是的,往往越是简单的新事务,越容易陷入“直觉”陷阱。

避坑参考:产品向上要突破的制约因素。

03 产品同学需要写《产品操作说明书》吗?

上周还有一件事,有个产品同学询问我产品经理需要写《产品操作说明书》吗?那不是测试或者运营的工作吗?和他沟通后对我的启发也是:面对问题,我们的本能不应该是回答答案,而应该先深度思考

我当时也在小报童「镜同学的产品驿站」做了分享,在这里也给大家做下简单的复盘:

首先,有问题就会有答案,这对很多人来说,都是本能认知、也是基本常识,所以你看,这句标语甚至成了“知乎”的slogan。

但是,据镜同学观察,很多产品同学在面对职场问题时总显得缺乏定力和静气,难以周全的兼顾,本能的直接回复,生怕答案过期,而且,越是简单的问题就越是轻敌。

那么,面对问题,我们的本能反应既然不是“回答答案”,那应该是什么呢?

很简单,是思考。

底层认知逻辑也很朴素:问题→思考→答案

思考是催生答案的必备过程,面对问题我们最重要的便是深度思考:思考功能定义、思考问题要点、思考本质解。

我们说回这个问题,我当时并没有直接回答,因为我深知定义问题是找到答案前提,而且,我过往也踩过类似的坑,遇到过类似事情,比如,我们之前公司的《产品操作说明书》就不需要产品经理来编写,于是,我和他做了沟通交流,解题思路如下:

1)定义清楚《产品操作说明书》

你们公司对《产品操作说明书》的定义是什么?

产品生命周期后半程会有很多文档,如,《产品手册》、《产品说明书》、《产品操作说明书》、《产品培训手册》、《用户使用指南》等等,这些文件在不同公司语境下作用不同,承建岗位也各异。

而《产品操作说明书》顾名思义,主要是对现有的产品功能、操作步骤进行解释说明,以便用户更快地理解产品、上手使用产品。

2)搞清楚该文档的目标用户

那么,这个文档是给公司内部人员(如,业务、运营)使用还是给外部客户使用?

当时,我们之前公司定义的《产品操作说明书》是外部文档,因此,这个不需要由产品经理来写,而是由客户成功部门来编写,他们是直接面客的。

但是,产品经理需要编写《产品手册》,客户成功同事会依此为基础编写《产品操作说明书》。

3)以价值重新理解

好了,明白了该文档的内部价值,我们就更好理解为何我们当时公司没有定义产品经理来写的原因:

之所以这样安排,一是客户成功需要深度了解产品;二是很多客户关注的产品功能尚在研发中,但客户成功部门可以提前剧透,他们会结合市场动态进行放大表述

而产品经理所写的《产品手册》更多只是从产品角度对现有产品功能进行的内部分析,以便公司其他部门人员学习了解。

我们再次回到问题本身:《产品操作说明书》这个小问题,似乎很好回答,我相信一定有不少产品同学会说,肯定是产品经理来写啊,不用怀疑的,甚至会列出网上答案,或者,ChatGPT的回复,以证自己说得对。

避坑参考:产品向上要突破的制约因素。

诚然,绝大多数情况下《产品操作说明书》由产品经理来编制并无不妥,但总有例外,本能回答并非最优解,正确的解题思路应该先进行深度思考。

其实,这多复杂问题的正确的答案都不是从书面上可以直接回答的,而是在不断互动、碰撞过程中修正完善的。

问题→思考→答案,面对问题先不要急着回答

这个认知习惯也许能帮助你从问题中积蓄成长的力量。

最后,镜同学想说的是,产品经理本质上是设计岗位,是创造性的工作,华为曾说过,创新是最大的护城河,对产品同学也一样,核心竞争力来源于对新事物的达成效率

因此,我们再强调总结下,在产品工作中应该要竭力避免「弱思考」和「凭直觉」的错误认知,想把「问题清单」转化为「解决方案」更应牢记:深度思考、基于理性。

专栏作家

产品大峡谷,公众号:产品大峡谷,人人都是产品经理专栏作家。七年B端产品经理,供应链物流与金融领域,擅长需求设计、业务指导、商业观察等。

本文由@产品大峡谷 原创发布于人人都是产品经理,未经许可,禁止转载。

题图来自 Unsplash,基于CC0协议。

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!