产品经理管理问题的“三板斧”

产品小白专属,10周线上特训,测、练、实战,22位导师全程带班,11项求职服务,保障就业!了解一下

产品经理的工作中总不乏各种各样的问题需要解决,能够立体化、系统化地解决问题是身为产品人必须具备的能力。

产品经理的工作是什么?我认为归根结底就是解决各种问题。

产品经理要定义一个产品,定义产品的关键就是定义产品价值,产品的核心价值就是解决用的问题,没有价值的产品再优秀的研发团队都是徒劳的。

除了定义产品,产品经理还需要管理产品,甚至关注产品运营,这一切的工作本质上都可以抽象为一个问题,开一次产品需求评审会是要解决这份产品需求能否达标的问题,写一个产品立项书是为了解决产品研发能否有资源的问题,定义团队章程,协调成员沟通都是为了解决产品团队的问题,所以说产品经理的工作就是解决问题一点都不为过。

那么问题来了,到底什么是问题呢?  问题本质上就是期望和现状的差异,因为差异产生痛苦,因而产生问题。

为了更加全面的理解问题,我想从三个方面去论述,让你对问题的理解更加立体化、系统化。

一、定义问题

问题分类的维度很多,按照二元论,我认为问题分为两种,一种是看起来是问题的问题,一种是看起来不是问题的问题。

先来第一种,看起来是问题,比如你做产品测试时发现不满足需求,交互界面易用性不好,产品开发进度未按照预期完成,这些都是第一种问题,一看就是个问题。

还有一类问题看起来不是问题,比如你的上司让你写个产品方案,他要给老板汇报,用户调研需要写一个调研提纲,这些看起来更像是个任务,这任务本质也都是为了解决一个问题,你接到老板让你方案的任务,实际上是为了解决你的上司如何给老板汇报的问题,本质上是要解决你的主管领导对于这个产品的认知问题。

问题分类清楚了,接下来要有能力分辨这个问题对我来说到底是不是个真正的问题,听起来有点拗口,我举个例子,一个需求人员过来跟我说,研发未完全按照原型设计进行开发,我看了下,研发因为前端技术所限对界面有微小调整,不影响大局,总体来看这个调整是OK的,对我来说这就不是个问题,可对需求人员觉得是个问题。

再举个例子,一个技术架构组的的重要人员要离职了,这看起来对我而言不是个问题,可实际我们的产品的用到了他开发的技术组件,他的离职很可能会造成我负责产品的进度延迟,这对我来说就变成了一个问题。

所以辨别是否是一个真问题的关键,就要看这个问题对我来说到底是不是个问题。

确定了问题,我们再来看如何准确的描述问题,先看下面的例子:

这个PPT写得太差不合格,听起来这确实是个问题,但你还是不知道到底问题在哪?是PPT的布局不够美观?还是逻辑结构不够严谨?所以正确的说法是你的这个PPT篇幅太长,要表达的观点不变,精简到10页就可以了。

看到没,描述问题的关键就是现状和目标,这两个点说清楚了,问题就描述清楚了。

二、分析问题

分析问题要关注三个方面,问题出现的频率、问题的关联性、问题的因果关系。

先看问题的频率。在ITTL规范里有事件和问题的概念,假如一个信息化系统发生了故障,在最短的时间内解决故障,恢复服务这叫事件,如果这个故障反复出现,一个月出现了好几次,那就要重点关注,把这些重复出现的偶然事件就会定义为问题,技术专家要想办法给出彻底的解决办法,解决这个问题。所以分析问题的频率很关键,不同的频率解决方案也会不同。

再看问题的关联性,如果我们的信息化系统需要升级一个底层组件,解决一个安全漏洞,看似很简单,可是真的升级了就解决问题了,他是否会引发新的问题,当前的安全问题是解决了,可是因为有个功能模块只能适配这个最组件的旧版本,新版本升级了马上新问题出现了。

最后就是问题的因果关系,我们要学会寻根溯源,打破砂锅问到底,像剥洋葱一样,层层把这个问题分解,透过问题的表面看本质,只有这样才能根本上的解决问题。

我举个实际的例子,我有个同事给客户演示系统,结果演示的效果不好,用户不太满意,后来我们复盘这件事,发现了以下子问题。

演示地点是客户的办公室,那一次的办公室没有外网环境,这个事先没有调研清楚,到了现场才发现,只能临时用的手机热点联网,系统的速度显得比较慢。

另外演示的投影仪连接电脑有些问题,捣鼓了几分钟才开始正式演示,这给用户留下了坏印象。

演示的过程中出现了一次系统bug,而这个bug的出现是演示的准备不足造成,研发知道有这么个问题,只是暂时来不及解决,如果提前准备充分,这小功能根本不会主动点开。

所以这些问题的叠加最终造成了一次失败的系统演示。

三、解决问题

只要思想不滑坡,办法总比问题多,一切问题都是可以解决的。

先说一个点,解决问题一定要以自己拥有的资源为最基础,否则得不偿失,说白了就是看自己手里有什么牌,才好出招。

比如一个用户提出一个系统需求,要真正的实现这个需求,我们现在的技术能力是不具备的,可能需要和别的厂商合作,或者需要付出大量的人力去做技术预研,成本都是非常高的,解决了用户的问题但是项目赚不到钱,怎么办?

问题还是要解决,我们回到问题的定义,问题就是预期和现状的差异,现状无法改变,只能降低用户期望了,通过成本较低的替代方案最终解决用户的问题。

问题经过分解,出现了很多子任务,这些任务都完成了,问题才算真正的解决,如何排定这些任务的优先级,有两个很关键的因素,一个是外部资源,如果这个任务需要其他人协助解决,这个人是不太可控的,所以这类任务优先级一定是最高的,另外一个就是依赖关系,通过任务的依赖关系明确哪些任务可以并行优先做。

最后问题的任务都分解完了,计划也定了,也分配到具体负责人了,那是不是就万事大吉坐等问题解决,显然并不是这样的,产品经理要全程追踪问题的解决过程,有问题及时沟通协调。问题解决后还要验证。

最近有个项目,我分配给一个现场的工程人员去部署附件服务,要实现多个节点的同步和负载均衡,他干了一天和我说问题解决了,这比我预期的要快很多,然后我再问他你验证了吗?怎么证明你部署成功了呢?他才晓得原来还有验证这一步。所以未经验证解决的问题,都不能算真的解决了。

这里把角色放的更大一些,你除了是一个产品经理,在家里你可能是一个父亲、一个妻子,在一个读书会你可能是一个读书会的会员或是组织者,在医院里你是医生的病人。我们每个角色所作的思考、决策、行为其实都是为了解决问题。

辅导孩子的功课是为解决孩子的成绩问题,带家人旅游,是为了满足精神上的释放,甚至我们每天吃饭、睡觉都是为了解决身体本身的健康问题。

所有一切行为皆是问题,成为问题解决高手,会让你的工作更加出色,生活更加幸福。

 

本文由 @奋斗De奶爸 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

给作者打赏,鼓励TA抓紧创作!
5人打赏
评论
欢迎留言讨论~!
  1. 学习了学习了

    回复