快好知 kuaihz订阅观点

 

从逻辑思维和金字塔原理,谈谈惰性思维对产品人的伤害

本文就结合逻辑思维和金字塔的思维方式并结合一定的产品方法论,进行文章撰写,主要分为几大部分:背景、论点、论证以及结论4大部分来展开叙述。

愿景: 作为转行成为产品经理1年的产品人,在产品设计中,有一些自己的领悟,希望分享出来,给人以启发。

目标人群:产品

idea:产品设计中的一些思维方式的转变

竞争对手:个人兴趣、时间、惰性

写在前面的话:

惰性既是人的本性,也是人的一种行为,同时更是人的一种思维方式。人们在做每一件事情、思考每一件事情的时候,总是想着以最小的代价、最小的精力、付出最少的脑力和行为就就能完美的完成一件事情或者任务,但往往南辕北辙。

人这一生总是活在与惰性对抗的竞争中,只有两种可能,要么平局,要么被打趴下,惰性永远都在。但世间没有任何东西都仅有一面,因此惰性思维会对产品人产生伤害。但换一个角度而言,也会对产品的设计大有裨益,但本次不作讨论,后续在写。

既然是写思维的文章,本文就结合逻辑思维和金字塔的思维方式并结合一定的产品方法论,进行文章撰写。主要分为几大部分:背景、论点、论证以及结论4大部分来展开叙述。其中在论证的环节,笔者将结合在实际的产品工作中的一些例子,作为论证和论据的材料供读者阅读,同时也会给出一些正确的工作方法。

一、背景

笔者作为产品人,需要同时身兼产品经理、UX、售前、数据分析师、项目经理、测试等多个职位。由于前端时间学习金字塔的思维方式的时候,笔者感觉其实更多的是讲如果突破思维的惰性和障碍。

突然想到最近从事售前的工作中,在进行售前支撑的时候,自己写的售前材料,按照金字塔的思维内容进行分析的话,内容还不够完善,若细细思考都是因为自己的思维惰性才导致的。

因此笔者带着这样的思考内容去分析这段时间做的产品,就发现,其实很多产品功能完全可以做的更好,做的更有特色,而这一切也都是因此思维惰性,只想着满足客户的需求,才导致的。

二、论点

基于思考感悟,笔者就悟道了一个道理:惰性思维会严重影响产品思考和产品设计,从长远来看,会严重影响自己的产品能力变革和提升。

三、论证

其实,单论产品人的话,需要有一个意识,就是你所交涉的对象,都是你的客户,你所交付到对方手里面的东西,都应该作为一件产品进行交付,而不应该是作为一件任务完成。

这存在着本质的差别,任务,只有任务完成与否。但若产品,需要考虑到受众、场景、使用时间、痛点、目标等等。

在此,笔者将从如下3个方面论证惰性思维对产品人的伤害:

1. 会有一种产品工作无法掌控的感觉

(1)针对公司内部的项目组同事(一类客户)

笔者产品工作需要对领导、UI、开发、测试负责。针对领导,笔者没有建立一个很好的需求管控手段,需求池的管理很懒散。在整个项目的推进过程中,只录入过两次需求池,整个需求的产品设计情况、开发情况、测试情况、上线情况都没有一个统一的记录和控制。

因此在每次向领导汇报的时候,只能全凭记忆向领导汇报近一周产品设计、开发、测试等情况,若是再追问整个系统的开发进度、测试情况,笔者就无法回答。而且,产品的工作进度肯定远远大于开发进度的。

因此,也存在时间长了,设计的产品越来越多,产品原型结构越来越复杂,之前设计的产品,就被遗忘在角落里面,无法进入开发需求池中,导致会有一种无法对自己设计的产品进行完全掌控的感觉。

针对UI,笔者设计的原型,是有点粗放,需要标注的没有标注,需要做解释的没有解释,大脑的惰性思维会告诉自己,UI肯定可以理解。但实际上,在进入开发设计阶段,最关键的是时间久了,UI在设计的时候,问到笔者页面情况,笔者需要回忆很久,但有时候,想出来的可能和当初理解的需求不一致。

针对开发,笔者很少输出需求文档、流程图、用例图等,基本上全靠原型和原型注释进行开发,也是因为惰性思维让自己觉得,这个需求这么简单,看一下就能懂。

但在开发完成之后,笔者去验收的时候,发现前端设计不对,开发的计算规则不对,甚至页面的展示字段都不对,这就是因为惰性思维让笔者少输出了应该输出的需求文档,导致需求理解不一致。

这样笔者在验收的时候也会很冒火,让开发去改的时候,开发也很冒火,对双方都有伤害。

针对测试,笔者很少输出usecase,这样笔者就需要主导测试,这样花费了笔者很长的测试时间,而产品其实是不需要主导测试的,只需要验收测试结果即可,大量的测试时间,很耗费产品人的时间。

(2)针对公司的实际客户(二类客户)

笔者产品工作是需要实际和客户进行实时交流的,交流内容包括使用问题、需求等,但笔者也没有针对客户的使用问题和需求建立一种很好的正向反馈机制,往往客户提的问题或者需求,提给了笔者,就没有下文了,客户也不知道怎么样了。

比如客户提给笔者的需求,就是记录在笔记本上,因为惰性思维,让笔者没有及时纳入到需求池进行管控,往往时间一长,工作一多,就忘记了。在客户提起的时候,自己又一脸茫然,给客户的印象极度不专业。同时自己也会自责,这点小事情都做不好,打击自身的信心。

笔者反思专门针对客户提出的问题和需求建立一套管理机制,在需要系统改善和新增功能的时候,纳入到管控池中,按照需求的模式进行管控,并对这类管控池中的问题和需求尽快和开发以及项目经理定制一个清晰的时间节点和解决方案,尽快给予客户一个反馈,给客户营造一种专业和负责的态度,又有一种掌控的感觉。

另一个,在进行产品设计的时候,完全清楚需求才不和客户进行交流,在只要有一点点不确认的时候,就需要及时与客户进行交流。

笔者产品设计的时候,因为惰性思维,懒得又要打电话沟通客户,约时间聊需求,就自己拿主意,结果设计出来的产品,让客户不满意,又重新设计,既浪费了时间、精力和成本,也极度消磨产品人的积极性的。

2. 产品设计无法让人眼前一亮

由于笔者的行业是政府,做的是数据分析展示,因此在对接需求的时候,笔者的方法是直接确认页面的展示内容、字段以及交互逻辑,这样是最简单、懒惰的方法,做出来的东西肯定能用。

但是由于客户并不是专业的产品人,他们所说的只能说是满足自己这个部门的实际使用情况,往往不会考虑其他受众,而且潜意识他们也会认为我们应该懂他们脑海里面的东西。而有一些潜在的东西,他们是下意识的忽略了,而不是不想讲,因此做出来的东西也缺乏亮点。

比如笔者在和用户沟通一个风险监督点A的时候,客户表示,这个风险点A,你要根据他的类别进行展示,这样方便有针对性的进行核查。

笔者初步分析这样的需求,似乎没什么问题。但是实际上开发作出来,不同类别的数据量也很大,导致人工核查成本非常高。在之后的沟通中,笔者针对这类风险再深入问一个why,那么客户就会告诉笔者,因为某个类别B里面,往往会出现很多应办但未办的事务,按照法律条例应该处理但未处理的。

了解到这里,就明白了,根据客户描述的,进行金字塔原理分析,应办的事务特征是什么?按照法律条例处理的特征是什么?

这里随着沟通的深入,笔者和客户一起梳理了一些事务描述的关键字内容,笔者设计一套知识库的方案,结合在展示上,采用自定义选择、标签以及关键字内容描述的方式,进行产品设计,开发出来的产品,极大提高了可用性,而且给客户眼前一亮,同时该功能的后期成长性非常强。

3. 产品人的道路迷茫

如果没有对自己的产品有完全的掌控,没有在自己的产品设计中融入自己的风格,没有在产品的规划中融入自己的思考,我们产品人是很容易沦为产品工具,而不是一个产品人。

在刚开始的阶段,笔者的工作内容就是耳听需求,缺乏工作管理,和产品意识。一段时间之后,自己就会感觉茫然,产品工作真的如此乏味嘛?

实际上是不正确的产品工作方式,消磨了自己的产品心,也极大消耗了自己的创造力,让自己在一段时间内只是按图索骥,画原型,做设计,做出来的产品完全缺乏灵魂和灵动,就是自己都不愿意去使用自己设计的产品。久而久之,笔者就对自己是否适合做产品产生了怀疑,更是对走产品这条路的初心有了许多动摇。

但还好,在后来的不断调整中,笔者不断根据当前的工作问题,针对性的从产品的角度进行解决,采用合适的产品方法,即使转变产品思维,才慢慢的开始找回了之前转型成为产品人的自信。

四、结论

惰性思维对产品人伤害很大,一件事情、两件事情是无法感知到的。但就如读书一样,1天不读、2天不读无法感知,但1个月、2个月不读书,就会感觉思维迟钝。所以我们产品人一定要有一点自我怀疑的态度,实时审视自己,我是谁?我在做什么?我做的有意义嘛?意义是什么?等等。

产品路本身也是一条充满荆棘和抗战的路,我们需要和自己战斗,也需要与同事、客户、受众、资源等等战斗。也不要因为一件、两件不如意的事情,就对产品这条路产生怀疑。但我们需要首先就要对抗好惰性思维,只有摆脱了惰性思维,我们的思维才会更加的活跃、灵动。

况且本身产品人就应该保持着一颗活跃无限、创意无限的心,产品既人,人既产品。愿我们砥砺前行,不畏风雨,保持自我,坚定产品心!

本站资源来自互联网,仅供学习,如有侵权,请通知删除,敬请谅解!
搜索建议:惰性  惰性词条  逻辑思维  逻辑思维词条  金字塔  金字塔词条  谈谈  谈谈词条  思维  思维词条  
产品

 产品经理工作总结 | 需求阶段,...

一、产品设计开发流程首先PM需要进行需求分析,即通过各种方式发寻并筛选出有效的需求,结合当前的企业市场定位进行需求管理排期逐步实现(战略层)。然后考量本阶段需要...(展开)

产品

 再谈那个被说烂的词——需求

 言于前,再谈是基于之前写的一篇日志《谈一谈那个被说烂的词——需求》。上篇日志主要论述“用户期望——用户需求——产品需求——产品”的需求的进程。而本篇是则是在前...(展开)

产品

 为什么产品经理要背KPI?

未来,纯粹的产品功能经理将越来越少,越来越多的产品经理将兼部分运营的职能。产品需要站在业务模式、运营推广 的角度,协调产品的整体推进,为KPI结果负责 ,并不断...(展开)