- 1、本文档共4页,可阅读全部内容。
- 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
- 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载。
- 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
- 5、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
- 6、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们。
- 7、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
- 8、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
入职美团点评半年,我可能写了一篇假的产品经理总结.doc
入职美团点评半年,我可能写了一篇假的产品经理总结
入职美团点评半年了,想着要总结一下,此文并不一定适用于所有人,抛砖引玉~~
本文主要从格局、目标、Owner、产品迭代、产品运营、不断学习六个方面进行总结,这是我理解下来我这个阶段产品经理需要努力去学习和补足的六个方面。
一、格局
1.我理解的格局
这里的格局我定义为去理解公司、团队的定位发展,将事情上升到一个档次。了解公司的发展、团队的定位,与上级的思路达成“一致”,更有力地向前推进。这里的一致是大方向的一致。2.为什么要有格局
产品经理是方向执行者,必须理解大方向。同步项目合作方,大家目标达成一致或基本一致。二、目标
1.大目标:类似公司的愿景,产品最终希望实现的一个愿景。
2.每一阶段目标:?这里可能就是流量、收入、产品功能/运营等OKR要求。
将每个季度的目标拆解到每个月,每两周,不断推进,不断review。
3.每一个需求目标
之前经常性做伪需求,先想清楚你要解决的问题是什么,你的目标是什么,然后再考虑解决方案。有时候就是想到了一个解决方案,就想着做这个方案,反而没有考虑更多,忘了有更合适的功能。三、Owner
1.你是产品的owner,你要为产品负责。
2.面子不重要
刚毕业产品要多请教别人,不要觉得怎么什么事情都要请教别人,或者让别人决定。有的时候开发都笑我做不了主,不过比起面子,产品功能符合需求才是最重要的。自己拍的板可能考虑不周全,反而引起再一个问题,这样反而使开发对你失去信心。3.积极主动
积极思考,积极请教别人,是先自己思考再请教。积极跟进需求,跟进合作方进度: 你的需求对你来说是最重要的,但对于合作方不一定是,要不断跟进,多“骚扰骚扰”别人。四、产品迭代
1.竞品分析
竞品分析,一般都比较关注竞品做了什么功能,什么逻辑,容易忽略商业模式及运营策略,先了解竞品大策略,能更好地理解竞品为什么要做这些功能。
商业模式:可以读《商业模式新生代》这本书,见下图。运营策略: 别人是怎么运营的,你在推进产品功能的时候,运营有没有跟上。功能点分析:网上一搜一大堆,这里不详解。
2.需求初审
需求初审是与项目干系人介绍产品背景及目标,做相关核心功能点及相关优先级讨论。
(1)保证可用
每一次的产品迭代,要把对应的需求列出来,排好优先级,考虑如果没有这个功能,用户能不能用。每一个产品都希望上线的产品是功能丰富的,但受限于资源、开发时长,我们需要快速迭代,不断迭代核心功能。下图于《如何做出好的产品——位高级产品经理的回答》
(2)相关方沟通
比较大的项目,涉及多个合作方, 一定要跟所有相关方及时沟通。相关方会告知自己的考虑点,帮助产品了解各方问题,确定需求。这样就不会出现突然插入需求/修改流程。与leader及时沟通,将整体流程同步,因为leader经验比较丰富,会看的比较远。以之前做的支付提现流程为例,除涉及到前后端技术、设计外还涉及到收银台、付款平台、风控、法务、财务、税务、客服等相关部门。
(3)上线时间
做大项目时,老大会问你预估上线时间,这时候千万不要自己拍脑袋,要综合设计、技术时间给到一个合理的预估时间。产品最忌讳我觉得这个很简单嘛,应该xx时间就能上线。(我遇到过两次坑)
(4)组内沟通:如果需求比较小,在提需求前可以在组内进行沟通。
3.交互阶段
(1)提需求:需求考虑完整再提,不要为了卡提需求时间或占坑而提。
(2)流程图:提需求要给到相关的流程图。
(3)相关wiki:涉及到需求变更/逻辑补充都更新到wiki中,留下相关记录,好记性不如烂笔头。
(4)交互稿同步技术同事:
拉一个前后端负责人的群,有交互初稿时,可以先同步到群里。不要等到需求评审的时候才发现技术问题,这样可以避免交互多次修改。交互定稿再同步技术同事,跟技术确定下来的交互稿就可以直接进入视觉。4.需求评审PRD
这时的需求评审就不是技术找问题的评审,而是确定可以做的需求评审。
(1)产品逻辑:需要同步技术通过相关的页面逻辑,并详细写在PRD里面。
(2)独立的功能模块
当项目比较大时,最好把产品拆分成独立的几个模块,进行开发测试。好处是,减少开发时长。这里开发时长也包含测试时长。
(3)小问题要及时处理
这个可能是我个人的毛病,因为觉得打点信息/通知节点不急,就会有点拖。这些最好在需求评审完一天内晚上PRD,不要随便去改PRD。因为开发是拿着PRD去开发的,你每次改动都会有信息同步开发,多次改动,开发每次还要去看你改了什么,很麻烦,也会对你产生不信任。(4)组内其他需求排优先级:每次需求评审前要把组内需求过一次,排好优先级,节省在需求评审会议的需求排序时间。
5.开发测试阶段
(1)因为很多产品细节/文案都是在交互稿视觉稿中体现,所以在交互阶段就把相关文案确定。
(2)开发过程中可能会遇到
文档评论(0)