一般我会制定1-2个月的产品规划与排期,在此基础上给到具体的优先级。之所以只做1-2个月的规划和排期是因为互联网的发展速度是很快的,2个月之后公司是否能够融到下一轮的资金、产品的市场环境是否发生了变化、产品的发展方向是否需要调整等等,都是存在具体的不确定因素。

  数据在很多时候是需求的一个重要依据,比如开发问:为什么做这个功能?有什么作用?凭什么你说了算?这个时候为了避免产品经理自说自话、沦为笑柄,所以就要拿数据说话,通过严谨的数据分析得出相关的结论,这样产品经理就可以说:通过数据分析发现我们的用户在3-10分钟的流失率达到35%,这说明产品在3-10分钟存在较大的问题,那么我希望通过添加任务系统让用户在3-10分钟的时候有一个明确的目标和任务引导,我不敢保证添加之后流失率必然降低,但是我的预期是通过这一项改进留存率可以降低10%。

  除了数据分析之后,市场和运营可能也会频繁的反馈产品问题或用户使用感受等等,但是市场和运营的反馈就需要产品经理经过充分的判断和思考了,因为很多市场的反馈可能仅仅代表着部分用户的小众需求,或者说是这个需求虽然有,但是优先级并没有那么高,不适合产品这个阶段去做这个事情。但是因为很多市场和运营人员并不具备这种判断能力,他们会吵着说用户的反馈很强烈,这个时候就需要产品经理很强的判断和说(si)服(bi)能力了。

  竞品分析就更不用多说了,有句话叫做“天下文章一大抄”,借用过来也可以说“天下产品一大抄”,比如微信的公众号、支付宝抄过去就变成了生活号,比如B站最早做的弹幕功能、很多视频网站也都纷纷借鉴了……在我看来,我觉得抄不是不可以,而是要合理的抄,在“借鉴竞品”的时候需要多问自己几个问题:这个功能到底是为了满足什么需求?这个需求的重要程度高吗?这个功能是否是合理的?为了满足这个需求、是否有更好的方案?

  撰写一份规划、严谨、详细的产品需求文档应当是产品经理的本质工作,由于产品需求文档缺乏统一的规范与要求,所以各家产品经理写起来也都是千差万别,很多初级的产品经理在撰写的文档总是会给人不规范、不严谨的感觉,比如写的需求只想到了前端展示,并不考虑后端实现逻辑、数据埋点、异常流程等情况。前端实现很容易看到,但是具体到后端的实现逻辑、接口如何调用、数据如何通信、在各种网络状况下的处理、异常操作出现时的逻辑判断等等,产品经理都需要尽可能的考虑清楚。

  一份严谨、规范的需求文档可以很好的提升开发的工作效率,同时也会加深程序猿对产品经理的好感,前段时间我在做产品的任务系统时,就因为文档没有很好的预见性而引起了技术的麻烦,后来我才了解到原来技术方面更希望我把任务系统设计成模块化的形式,其中的数据都可以从后台配置,前端的展现方式也需要进行统一和明确,这样他们开发一次之后,后续再添加新的任务就可以只配置后端数据就可以了。

  需求文档写完了、也和开发过了一轮,那么下一步就需要产品经理跟进了具体的开发流程中去。不同公司有不同的项目管理软件,禅道、Jira、Worktile等等。产品经理一般会把具体的需求录入到项目管理软件中,这个过程中,产品经理还需要进行跟进,看技术人员在具体的实现上是否还存在问题?或者在时间有限的情况下是否会压缩需求或者前期以简单的方式实现?等等。等到开发周期快截止的时候,产品经理还需要督促测试和上线、其他一切别人不愿意做或不去做的事情

  非常推荐大家去看一篇由谷歌前产品经理撰写的文章《产品经理,你其实是个锤子、清洁工、路由器》,这篇文章写出了大多数优秀产品经理的真实状态。

  比如技术人员之间发生分歧了,产品经理要想办法协调;老板突发奇想要加需求了,产品经理要帮技术顶住压力;运营活动人手不够了,产品经理要帮忙;甚至连财务打款没到账,产品经理也要跟踪给老板反馈……

  往后发展的话,我认为产品经理除了做好本职工作之外,还需要持续性的学习以不断提升自己的专业能力、形成相关的产品哲学与产品方法论,同时还需要对市场、运营、渠道、品牌、技术架构等方面有充分的涉足和了解!

  文档这类文字描述的,一方面pm后面回顾时,能知道当时自己是怎么想的。一方面也是需求封锁的过程。

  还有我觉得pm也不应该和开发扯太多逻辑和思维什么的,更多的应该关注在你要什么效果上,可以懂开发技术,但是不用自己去教开发应该怎么设计怎么做。#个人观点#

  人人都是产品经理(是以产品经理、运营为核心的学习、交流、分享平台,集媒体、培训、招聘、社群为一体,全方位服务产品人和运营人,成立8年举办在线+期,线+场,产品经理大会、运营大会20+场,覆盖北上海广深杭成都等15个城市,在行业有较高的影响力和知名度。平台聚集了众多BAT美团京东滴滴360小米网易等知名互联网公司产品总监和运营总监,他们在这里分享知识、招聘人才,与你一起成长。