02 产品经理的工作流程

作为产品团队的信息收集者与传递者,产品经理的工作所涉及的部门和人员是非常多的,今天我们就从人和事两个方面聊一聊产品经理的工作流程。

基本工作流程

关于产品经理的基本工作流程,我们用一个产品迭代优化的例子来阐述。

要迭代优化,产品经理遇到的第一个问题就是要做什么,即工作流程的第一部分:搜集需求。

在这个阶段,产品经理需要弄清楚需求在哪里。归纳起来,需求可能会在领导那里;可能在协同部门那里;可能在用户的反馈里;可能在产品后台监控的数据里,还有可能在产品经理自己对产品的理解与洞察里。

既然需求可能在这么多地方,那产品经理就要想办法来搜集这些需求。在收集需求的过程中,产品经理需要应用多种方法,例如用户访谈、调查问卷、数据分析、用户画像等,总体可以归为定性和定量两大类,同时还需要关注需求方的表达与行为(很多时候,需求方说的并不是他们真正想要的)。这里我们不展开讲,建议想深入了解的同学可以读相关的专项书籍或文章。

假设产品经理搜集到了这些需求,那接下来就要考虑哪些需求能做,哪些不能做,哪些需求重要要先做,哪些不重要要排后,即工作流程的第二部分:需求筛选与分析。

需求筛选与分析面临的第一个问题就是甄别哪些需求是真的,哪些需求是假的。相信大家都听过亨利·福特的经典语句 “如果我最初问消费者他们想要什么,他们应该是会告诉我,‘要一匹更快的马!’”。而事实上,用户的最终目的是要更快的到达目的地。所以产品经理需要通过搜集的信息甄别出,用户的真正需求是什么。

当弄清楚这个问题后,接下来就是对需求进行排序,即开始说的确定哪些需求重要,哪些不重要。这个排序的过程,需要考虑的因素很多。理想的情况下,需求的优先级是基于产品规划及商业目标展开的,当然也可能会出现其他情况,例如老板需求等。

将需求排好了序,接下来该做什么了呢?那就是把需求整理成可执行的方案,即工作流程的第三部分:文档撰写。

这里所说的文档是一个统称,指产品迭代过程所用到的所有文档,例如思维导图、流程图、产品原型、需求文档等。所以文档撰写是一个由抽象到具体的过程,可以分几个层次来看。

首先,要确定大的方向,核心流程。对此,产品经理可以整理思维导图或流程图,和需求方确认核心是否正确;确认了核心流程以后,产品经理就可以整理更加细化的原型,前期原型只需要将页面的结构及交互关系体现出来(低保真原型),然后再与需求方确认;确认后进一步细化,形成细致的原型及配套的需求文档。特别要注意的是,这个阶段的沟通不仅包括需求方,还应包括技术以评估技术的可行性。

有了完整的文档,产品经理就可以考虑进入下一阶段,即工作流程的第四部分:项目启动。

项目启动首先是要组织项目启动会议,会议上产品经理需要向各方完整阐述项目的背景及需求内容。值得注意的是,产品经理在发送会议通知时,需要把原型及文档同时发给团队成员,让大家带着问题参加会议,这样会议的效率会更高。

会议中,在与会人员明晰之后,确定相关负责人,由项目团队给出项目排期(需要确定项目排期的时间节点)。

有了排期,就进入工作流程的下一阶段:项目开发。

在项目开发过程中,产品经理需要沟通,沟通,再沟通,再有就是关注项目关键节点及成果,以确保项目的按时按质完成。

项目开发完了,就是安排上线了,同时给相关成员发送上线通知邮件。一般而言,上线之后的一两周内,都是产品的重点监控时间区间,及时发现问题,及时解决(上线时应该制定相应的应急方案)。

当新版产品运行经过平稳期,产品经理就该考虑下版迭代了。

产品经理接触的人

这个问题可以分两部分来说:产品规划与产品开发。

就产品规划而言,产品经理接触到的人包括但不限于:

1)直线领导

当我们做产品规划时,必然要和直线领导就方案达成共识,才能进一步向外沟通确认,因此在产品规划阶段,你需要频繁地与直线领导沟通或汇报(有时候直线领导可能不参与具体讨论,但需要知道进度)。

2)公司领导

有时候,公司领导可能是某个需求的提出者。这种情况下,产品经理(或直线领导)需要向公司领导汇报相关解决方案。

3)业务人员

如果你负责的产品有业务人员的话,那他们也是产品重要的需求方,同时他们在与客户接触中,会出现种种问题。这个时候,都需要产品经理参与解决。

4)客服人员

针对产品规划,客服人员反馈的用户数据尤为重要,因此产品经理需要频繁地与客服人员进行沟通,搜集数据,整理并转化为需求。

5)用户

用户研究是产品规划阶段的核心工作之一,也是产品经理难得的接触真正用户的机会。在这个阶段中,产品经理可以采用用户访谈、调查问卷、可用性测试等方式,多多与用户进行接触。

就产品开发而言,产品经理接触的人包括但不限于:

1)UI/UE

当产品原型最终确定,就可以进入UI设计阶段,这个时候产品经理就需要和UI探讨原型细节,进入设计阶段。

2)前端

UI设计完成后,就开始转入前端工作。对于前端而言,会更加关注细节,每一个按钮的状态变化,每一个交互细节,都需要详细说明。这块一般是由产品经理和UI共同提供的。

不过如果是移动端产品,前端基本上就不太会参与,页面切图和标注工作主要是由UI完成。

3)开发

开发的工作主要是参照需求文档来展开的,因此产品经理需要就需求文档细节与开发进行充分沟通,以保证开发工作的有效性。

4)测试

开发完成了项目工作,就进入了测试阶段。一般情况下,测试人员会在开始之前召开测试用例评审,然后才进入具体的测试阶段。无论是测试用例编写阶段,还是测试阶段,产品经理都是要与测试充分沟通的。

事实上,项目开发的工作是阶段性的,但产品经理与团队的接触则是全程的。从需求的发生,到项目的上线,产品经理都需要与UI、前端、开发、测试等人员充分接触,对产品需求进行沟通评估。

产品经理的一天

结合产品经理基本工作流程来看这个问题,会更容易理解一些。虽然具体的产品开发工作不用产品经理做,但产品经理也绝对做不了甩手掌柜。在有产品开发时,他需要时刻关注产品的进度,进行问题确认,必要的时候协调资源;在没有产品开发时,他需要进行规划,同时还要关注市场及竞品的变化,以能够及时洞察产品的发展趋势。

把以上的这段文字转换成场景,基本上产品经理的一天就能呈现在我们面前。

早上在上班通勤的路上,产品经理可能会打开新闻客户端,关注自己感兴趣或与工作相关的内容,必要的话会把重要信息或链接记在备忘录里。

到公司以后,打开电脑首先查看一下邮箱,邮箱里有四五封邮件,其中两封邮件是测试发的bug信息,需要沟通确认;有一封邮件是协同部门发来的,内容主要是得到了一些用户反馈,需要满足新的需求,需要进行评估;还有一封会议通知邮件,下午三点要开某产品需求沟通会议。

然后产品经理的一天也就围绕这几封邮件开始了。上午他可能会先去和测试沟通确认一下两个bug该如何修改,沟通的过程中又发现了新的问题,所以后来和测试的沟通就变成了和测试、开发、前端等同事的沟通。问题解决了,时间也过去了半个多小时。

解决了测试bug的问题,产品经理需要好好想想协同部门提的需求。对产品经理而言,需要很慎重地对待需求,有的需求不一定要满足,而有的则必须快速响应。经过初步分析,这个需求是需要满足的,但如何做还需要和领导沟通一下。因此,产品经理就去找领导沟通,沟通后最终形成了一个初步的方案,产品经理以此回复了邮件。而此时已经上班两个多小时了。

产品经理刚发完邮件,着手开始准备下午开会资料时,电话响了。电话是客服同事打来的,说用户使用出现了问题,需要马上解决。产品经理只好先暂时放下手里的活,去解决用户问题。用户问题解决了,时间基本上也就到中午了。

下午的工作内容相对比较整,简单说就是准备开会、开会。不过,在这个过程中,还是时不时需要跟项目成员确认信息;收到其他同事的微信或电话。下午的会开得还算成功,不过有些需求的细节还是需要调整。会议开完,产品经理就开始着手修改工作了。等修改完了,差不多也就到了下班的时间。

其实上面说了那么多,总结起来讲产品经理的一天就是由洞察趋势、内部沟通、整理信息、产品思考四大部分组成,其中沟通会占大部分时间,形式有面对面、电话、会议等等。所以沟通能力对产品经理来讲,尤为重要。

小 结

关于产品经理工作流程,我们可以归纳为想、写、说、做、改五个字。任何一个阶段,都由人、物、信息三种元素组成,产品经理的工作也都以此展开。

  • 发表于:
  • 原文链接http://kuaibao.qq.com/s/20180106G0CMEG00?refer=cp_1026
  • 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券