zoukankan      html  css  js  c++  java
  • 产品经理与众不同的思维方式与“职业病”——《人人都是产品经理》

        最近一直在想自己作为一名phper要不要转职产品经理的岗位。正确的认识自己,是人生的必修课之一,在行业内做的越久,也越来越对自己的认识增加深刻。

    对自己的认识

        1、对自己的定位,理科的行当中,热爱偏艺术多的行当;艺术的范围内,又属于拥有较强逻辑思维的一类人。因此在最初找专业的时候给给自己的定位,则是希望身为理科生能做既能体现自己还不错的逻辑思维能力,又能涉及到偏文理方面的,后来误打误撞进入了IT行业。在java、php摸爬滚打了2、3年,渐渐觉得自己更热爱管理、产品的行当,而在技术的方面有了瓶颈,类似于,心有余而力不足,不希望一门心思钻进去,而希望有更多思考更广阔的空间,所以希望自己能够有更好的职业规划和发展。

        2、如题,产品经理与众不同的思维方式与“职业病”。先简单的定位自己的思维方式。我给自己的评价,在乎于,比较耿直,还是习惯性的拥有“学生”思维。当然我现在开始接触产品经理这一岗位,不管未来是真的转行过去了,或者就算在我了解了之后觉得不是适合自己,我个人觉得这样思维的转变对我自身而言都是有很大的提高和进步的。

    产品经理应该有的思维方式

        1、 当出现某一需求A,应该首先能够列出来一系列的初步解决方案。

        当这个需求是单向的,其解决方案会从一点出发,涉及到多种不同的用于解决的工具、方案等。

        当这个需求是不是单向的,涉及到几类不同的用户,应该考虑到不仅可以从这一类用户入手,其实有时候换个角度思考也是可以的。

        比如说,当你要从H地到M地卖一个东西,途中遇到障碍无法行进,你应该不仅仅想到能够换一条路,换一种运输方式等、还应该能想到,M地的人员是否能够提供帮助这样是不是可以更节约成本。

        比如说,如果是一个做内容的网站,当网站本身提供的内容开始不充分、满足不了用户的需求,是否可以考虑由某些创作者用户他们来提供内容。很多成熟的平台都是这样的案例。

        2、当思维遇到瓶颈,应该能够跳出当前的场景,换一个角度,或者直击真正的需求目标目的,是否能够有别的解决方案。

        这部分可以参照《人人》这本书中,讲述从“现象”到“本质”的章节(1.3.3)。

        另外,讲我今天遇到的一个我个人认为挺厉害的一个 朋友跟我讲的案例。我跟他说,我想试试自己能否面上XX的产品岗位。

        这位朋友告诉我说觉得xx的产品运营十分辣鸡,XX是一家很成熟的公司,对于我的印象来说就是能够作成教学案例的那种。

        XX是一家做交易的平台。我问为什么,他告诉我说XX虽然强调自身品质,但是比如在购买1块钱的东西,运费10块。这物流的部分需要公司自身来承担,运营成本太高,而当未来这种强调配送的平台,在无人配送和VR消费兴起之后,就会变成毫无优势。

        而这样的话,XX务必会面对着他的瓶颈,在未来务必改变这种方式。

        当然我目前并不知道他说的对还是不对,我只是觉得这种思维是我自己不曾注意到的一面,写在这里提示自己。

        3、思维全面,并且考虑充分。

        在我做开发的时候,常常会有一种依赖心理,产品怎么说我就怎么做。产品阐述完了他的想法,我根据这种想法,去思考我的代码能否实现,当能实现的时候,我便会开心并且坦然的帮他去实现。

        在我工作第一年的时候,遇到了一个特别坑的东西。当时我们的产品是一个财税培训站点。产品告诉我需要做一个,某用户购买了公司别的产品,需要将我们培训的权益作为服务赠送给用户。产品给我阐述了他的想法和做法,于是我花了1、2天帮他实现了功能。

        起初还挺好,但是在后来这部分遇到的问题越来越多。

        对于这家公司,全国拥有14个分公司,每个分公司的销售场景各不相同,销售策略也各不相同,有些需要赠送一次培训的权益,有的需要权益有时间效益,有的需要赠送会员;有的针对购买的企业赠送,有的针对购买的用户赠送;而我们的站点是针对用户而不是针对企业。

        再其次,赠送的权益,用户退款了权益怎么处理;各个分公司销售在下单下错了要帮用户换购,如何处理;用户在购买是有时限的,那么到期了之后如何处理,续费又该如何处理。

        于是在后来很长一段时间,这个方面的工作成为了我要慢慢填坑的一大部分工作。简称,巨坑。

        导致这样的后果,首先我认为,产品在这一块并没有思考完善、充分,作为开发并且毕业半年的我,不了解这块业务的我更加没有考虑充分,代码也没有写的很好。再更有甚者,在后期,当运营已经以某种承诺将产品推销出去卖出去了,但是功能点上还没有实现,导致甚至很多数据需要重新计算等。

        假使,现在重新让我接手这一件事情,我相信会比当初做的好太多。我打算抽空自己再整理这部分的需求,以作为我对这一行更深入的了解的一个起点。

        4、辩得过开发,抢得过资源,hold住全场。

        作为开发的时候,常常和产品争论,觉得不带这么玩的,为什么要越做越复杂,并且为了实现一个小功能做修改一堆东西,最后做出来用的人还很少。

        而我觉得,作为产品的时候,首先要为了自己的需求辩论,在成本过高的情况下要能相出别的方案能够解决最终需求本质的东西。

    producted by llicat

  • 相关阅读:
    11月2号
    2020.9.22 (Java测试)
    2020.8.30 + 每周周报(8)
    2020.8.31
    2020.8.29
    2020.9.23
    伪分布式hbase从0.94.11版本升级stable的1.4.9版本
    python 将列表(也可以是file.readlines())输出多个文件
    hbase0.94.11版本和hbase1.4.9版本的benchamark区别
    idea 配置
  • 原文地址:https://www.cnblogs.com/llicat/p/7414180.html
Copyright © 2011-2022 走看看