新人产品经理二三事(2019.06)

2019-06-01  本文已影响0人  HughDong

写在前面

不知不觉就到了六月份了,六一儿童节快乐!啾咪~



来公司三个多月,除了对客户业务上的了解,也体会到了很多工作中的不容易和妥协。
本着“不积压、传播负能量,只复盘问题和解决方法”的原则来看待生活会好些。
之前月度复盘写的比较零散,想到一条就写一条,还是应该划分篇章的,之后改进~

工作方法篇

#01 做PPT的方法

上个月在准备一个很重要的PPT,大概花费了60个工时还没搞定,回想起来很容易犯个错误,没有聚焦于核心问题:

PPT是为了把内容传达给听的人

划重点:内容。在做的过程中经常内容还没完全想好写哪些,就动手画图示了,修改内容后图示还要再改,甚至是推翻重来,浪费了大量的时间。
另外一件特别傻的事儿是PPT都快做完了,讲义还没写,一定要写哪一页PPT就顺手把讲稿先写了!不然时间跨度大时转回头就想不起来很系统的讲述思路了。

#02 关于微信消息

频繁打开微信查看消息,效率会变得很低(主要是还会顺手闲聊两句),这个问题要重点去处理啦,微信消息集中时间处理,比如去洗手间或站起活动的间歇,专注工作时就不要看了。

#03 工作量评估

终于找到了最近时间特别紧+工作压力大的根源:不会估工作量
本来需要3个工作日的量,应该留4天的,估计错给领导说2天完成,不忙都怪了……

#04 一个思考方式

项目经理提到了一个很简单粗暴的思考方式,私以为用来考虑问题非常实用,没有花里胡哨的说法

输入 → 处理 → 输出

业务模块设计时可以用到,了解项目情况时可以用到,会议准备、PPT制作都可以用到。这本身就是个普适的结论,时刻谨记这三点还是有好处的。

#05 切忌雨露均沾*2

“做一个成一个,做一个好一个”,不能把精力分散开到各个地方。最近迭代封闭开发,同时开始做四个大模块,原型设计的工作量就特别大,加班ing。
雨露均沾的后果也显现出来,因为时间紧任务重,出现了需求描述不明确、功能定位没想清楚的问题。

#06 数据流的重要性

在改造以前遗留的功能时,没有彻底搞清楚数据流就动手设计功能,很容易出问题。

#07 不要重复造轮子

最近设计的一些功能中有一些是公司其他的产品已经做过的,再从头琢磨设计并且没有参照很容易陷入盲点,造出方形轮子。

#08 定位

在看人人都是产品经理的那本书中提到了,产品的定位要清晰,把核心定位写在随处可见的地方。
如果说产品定位是基,那么这个地基打下之后基本是不会改变的,但功能模块不同。
功能模块的定位是在日常工作中会变的,在新加入一些功能时,其他功能也需要对应的调整。
最近在做功能规划时,各个模块的定位未明确的情况下,盲目开始设计,导致开发改了又改。
后来再做的时候就学乖了,设计功能前先把这个模块的功能和定位写清楚之后再设计,会稍微好一些。

#09 磨刀不误砍柴工

需求文档还是要写的,因为手头的设计工作很多,有些流程图、模型数据流图就没有及时用visio画出来(即使已经在纸上、白板上讲了无数遍的)。然后就出现了一件非常尴尬的事情:最重要的没画,画了个不重要的还错了。导致开发按照错的模型实现了一遍,直接浪费后端主程5人日(仿佛看到开发手里的刀)。之后一定要好好画流程图,再忙也要画。

PPT篇

#01 PPT的内容逻辑

之前一直认为自己PPT算是做的不错的了,于是乎就被老板骂了一通,按照他的思路写了一遍才算Pass。因为事关重大,所以最近两周都在做它,总计工时68。说说心得:
不谈细节、美化,领导只要看过目录就明白你的PPT做的好不好。
首先在目录这一页要讲清楚你今天的讲述思路是什么,如果在这里听不明白的话,很难有一个整体的概念深入的听下去,高层领导尤其关注这个。
框架设计上每一个章节都应该是有关系的,我的章节设计如下:

  1. 分析素材(以下所有内容的材料支撑)
  2. 政策分析(全国性的政策支撑)
  3. 区域分析(地方性政策+市场+竞品)
  4. 竞品分析(市场竞争中遇到的竞品总结归类)
  5. 发展规划(我们下面要做什么)

在这个PPT里有以下几层逻辑:

  1. 第一章【分析素材】说明以下所有的分析材料都有所依据,并非拍脑门所想
  2. 二三四章每一章都是总分总结构,比如【竞品分析】:首先说明有哪几类竞品,再从每一类中挑一个典型出来说明,最后总结并说明我们的打法。
  3. 第三章是关键的承上启下的作用,【政策分析】表明了全国性政策有哪些,但不清除具体落实到地方是怎样的,所以第三章【区域分析】首先要说明在各个区域的政策推动情况,引申出建设进度,再说项目上遇到了哪些竞品,通过这些竞品引出第四章【竞品分析】
  4. 二三四章分别从【政策】【市场】【竞品】为第五章【发展规划】做支撑,说明“为什么我要这么发展”
    受益颇深,欢迎讨论。

同事合作篇

#01 支撑

为什么叫做支撑呢,经常因为某些地方人手的不够,需要从其他部门或地区借调人员帮忙支持,完成一部分的工作。我对工作边界不太敏感,刚来公司也不知道该怎么拒绝人,所以最近就有了不少需要支撑的工作。两天临沂的项目支撑(算是分内),半夜飞到北京,帮其他部门的项目写了一天的方案,但是坦白说,没有见到成效
在临沂的时候被搭档(项目经理)催了一次家里的进度,因为本职工作还压在手里,所以拒绝了这边余下的任务,明天早晨(周日) 回南京继续加班完成本职工作。有点像是……明明给了别人希望,又给了人失望,这种感觉非常不好。
希望以后自己在工作中如果有人需要帮忙,要么不接,接了就要做好
另外,还是要时刻关注自己本职工作,关注自己的孩子“产品”,一定一定要把最高的优先级排给它。
后续:
跟直属领导汇报了项目上的情况,也说明了最近的工作压力。我以为项目上的那个副总裁找我时已经把事情提前跟他沟通过了,写方案这事儿是我的领导授意的。结果领导并不知情,以为只是和我的产品相关,需要简单的帮帮忙。好在原因说明之后领导表示本就不该我来做,他去协调了。
如果是领导安排的外部工作会影响本职工作进度,以后一定一定要先确认,把风险说明并确认。

#02 一个产品经理 + 一个产品经理 = ?

我以为是强强联手,其实是相互拉扯。每个产品经理的发展历程都不同,日常积累的经验所产出的设计思路也不同,如果因为对方的想法修改一个模块,其他的模块定位就会受到影响,甚至说拆散了重组。
私以为如果同一个项目由两位产品经理共同完成设计的话,必须要有一个主导思路,另一个辅助落实到细节上,不宜自说自话。两个人相互说服对方按照自己的思路来的结果会浪费大量的时间,私以为不会再以这种方式来合作,尽量确定下来主导思路(骨架),另一位往里面填内容(血肉)即可。
但是!从另一个角度来看,两个产品经理合作也有很大好处的,快速吸收新鲜的思路和设计经验。

思维方式篇

#01 产品经理的二八原则

= 80%时间思考 + 20%时间实现

#02 全局思维

总被领导吐槽我格局太小,缺乏全局思维,做PPT或者汇报的时候谈着谈着就说到了细枝末节上了。目前还没有什么解决办法,只能开阔眼界,加油。

其他篇

#01 实习中的一些需要改正的问题

1.难以自顶向下设计,全局思维差,需要让自己的格局更大,输入更多的知识和经验来扩充
2.存在功能上重复造轮子的情况(如标签、布控),需要优先熟悉公司内部其他产品的业务与逻辑
3.工作效率不高,无法快速响应需求并设计出可用的功能,需要经验积累
4.不会评估工作量,经常出现时间估计少或未考虑突发事件的情况,事务堆积影响工作,需要借鉴之前记录的工时来合理评估
5.与客户交流较少,需要加强与项目客户交流
6.产品设计效率不高,导致文档滞后,需要提高效率
7.产品培训与宣讲工作不到位

总结

1.做事情先聚焦于自己的需求(PPT的内容),附带工作可以放到最后再做(如排版)
2.PPT写完一页就顺手把讲义写在备注里
3.少看或不看微信消息,集中处理回复消息,保持工作的专注
4.时刻关注自己本职工作,关注自己的孩子“产品”,给与最高的优先级
5.工作中帮忙的事儿,要么不接,接了就要做好
6.两个产品经理合作优先定下来主导思路和主导人,忌相互说服
7.其他部门领导协调我工作时先找自己的领导确认
8.开阔眼界,注意全局思维
9.数据流!数据流!数据流!
10.不要重复造轮子
11.产品要有核心定位,模块也要有核心定位,不能偏
12.设计工作不能雨露均沾,把一个模块想清楚、想透彻了再做下一个
13.重要的流程图、说明等一定要写全、写进文档

上一篇下一篇

猜你喜欢

热点阅读