被“绑架”的产品经理

你是被“绑架”的产品经理吗?

看多了,听多了,对于“绑架”这个词或许更适合很多的产品经理,个性张扬的年代,很多产品经理已经被拘束了,没有了想法,没有了激情,更失去了很多机会,特别是在浮躁的一线城市,当没有足够的时间思考时,你只有被架着走的份,不断变化的需求,繁忙的加班,众人的埋怨,自己也逐渐的迷失了自己谁改变谁已经不再重要,一个产品经理,比专业技能比不上团队中任何一员,那你凭什么在团队中立足,用什么让团队走的更远,变的更强?在这人人都是产品经理的年代,每个人都有自己的产品想法,技术要能实现,UI又想酷、炫,交互又想要好的交互效果,而上级除了要有用户,还得要求加入商务,运营得想如何把产品玩转起来,市场BD得想如何获得更多的合适……这不是一个简单的产品了,产品经理如何驾驭?

为什么会被“绑架”?

谁是产品最有发言权的人?CEO。毫无疑问,这个是最直接的答案,CEO是最大的产品经理,如果不服从只有走人的份,多少人是为了老板做产品,多少产品因为这样而变的“笨重”。
谁是产品最核心的成员?没有。因为团队中每个人都不可或缺。从来不相信一个人可以撑起一个产品,但我更相信一个团队可以将产品做强,做大。
谁最可缺?产品经理。移动互联网时代,最缺的是产品经理,最不缺的还是产品经理,看过太多技术直接替代产品经理的现象,或许有时需要的不是产品经理,而是项目经理。

怎么做到不被“绑架”?
学会say no。拒绝一些不合理的需求,人人都是产品经理,但并不代表谁都有权利决定产品的方向和功能。这是你的强项,这也是你要承受的,会挨批,会有不理解,但请保持一颗强大的内心,产品经理必须要有一颗承受的住打击的内心。
懂点技术。或许你可以不懂写代码,但请懂一点技术,不是要你去写代码,而是你知道某些功能会实现你可以在其它产品上看到。当遇到想做的,去谷歌、百度,去咨询,去探讨,没有实践就没有发言权。实践并不一定是自己的,而可以学习的。
判断力。你必须要有分析判断能力,哪个市场你能进入,哪些产品你不能接,谎言和浮躁已经成为行业的代名词,遇到好的公司是你的幸运,遇到不适合自己的当断则断,有时薪资、机遇会成为影响判断力的因素,请给自己一个冷静的时间。
放下、宽容。产品经理很多时候不会放下,抓着一堆遥不可及的东西,想要让上面高兴,也想让自己得到重视,其实你什么也不是,每个人都有一定的价值,但并不是不可缺,你得学会将自己放下,对别人宽容一点,也对自己宽容一点。

不想继续写下去了,多年之后会感谢这些年被“绑架”,让我走的更远,走的更加坚定。产品经理是服务型的,很多时候为了产品、团队在牺牲自己的利益和方向。只是因为有爱,有想做产品的一颗热诚的心。这也是可以坚持一直走下去的勇气,我们有千万次放弃的机会,但我们没有,因为我们是一名产品经理,我们字典里没有放弃这二个字。

产品评审那点事

在产品评审时是否有时候被一位高层打断,明确指出此产品与企业业务发展方向不符,不能实施?是否在讲解产品时,有些人员似懂非懂?是否产品评审太激烈时经常会忘记一些意见收集……
相信类似上面这些情况在你在过产品时也遇到过,产品评审做为产品把关的重要环节,产品评审的重要性不言而喻。那产品评审到底是怎么一回事呢?
评审,顾名思义就是关于审查和批准项目计划,产品变更和工作进展评价的一个步骤。
产品评审在产品过程中占着很重要的一个环节,是对产品成型,产品质量,产品进展等环节的检测和评估过程。

评审的重要性:
1.需求是开发最重要的一个输入,好的开始是成功的一半! 所以,产品需求的质量很大程度上决定了产品质量。
2.产品风险常常是软件开发过程中最大的一个风险 ,要降低需求阶段带来的风险,就要把需求评审做好。
3.产品评审做不好的后果:
1)需求变更
2)产品目标不明确
3)产品周期不可规划
4)产品功能不可实现
导致后续工作难于开展或经常出现变更。
4、产品经理:“不识庐山真面目,只缘身在此山中”,需求是自己写的,容易受到固定思维的限制,所以,需要一双没有看过这个需求的眼睛来检查一下,有什么问题。
产品需求的不同层次:
目标性需求:定义了整个产品需要达到的目标;——高层关注
功能性需求:定义了整个产品必须完成的任务;——中层关注
操作性需求:定义了完成每个任务的具体的人机交互;——执行人员关注
在做产品评审的时候,应该根据不同的产品需求层次,进行不同的评审。

那么究竟如何做好产品评审呢?

建议一:分层次评审
我们知道用户的需求是可以分层次的,一般而言可以分成如下的层次:
目标性需求:定义了整个产品需要达到的目标;
功能性需求:定义了整个产品必须完成的任务;
操作性需求:定义了完成每个任务的具体的人机交互;
目标性需求是企业的高层管理人员所关注的,功能性需求是企业的中层管理人员所关注的,操作性需求是企业的具体操作人员所关注的。对不同层次的需求,其描述形式是有区别的,参与评审的人员也是不同的。如果让具体的操作人员去评审目标性需求,可能会很容易地导致“捡了芝麻,丢了西瓜”的现象,如果让高层的管理人员也去评审那些操作性需求,无疑是一种资源浪费的情形。

建议二:正式评审与非正式评审结合
正式评审是指通过开评审会的形式,组织多个专家(可以是多个不同类型的产品经理,也可以为产品相关部门的负责人),将产品涉及到的人员集合在一起,并定义好参与评审人员的角色和职责,对产品进行正规的会议评审。而非正式的评审并没有这种严格的组织形式(也就是所谓的头脑风暴法),一般也不需要将人员集合在一起评审,而是通过电子邮件甚至是网络聊天等多种形式对需求进行评审。2种形式各有利弊,但往往非正式的评审比正式的评审效率更高,更容易发现问题。因此在评审时,应该更灵活地利用这2种方式。

建议三:分阶段评审
应该在产品形成的过程中进行分阶段的评审,分阶段评审可以将原本需要进行的大规模评审拆分成各个小规模的评审,降低了产品返工的风险,提高了评审的质量。比如可以在形成目标性产品需求后进行一次评审,在形成系统的初次概要产品后进行一次评审,当对概要产品细分成几个部分,对每个部分进行各个评审,最终再对整体的需求进行评审。这样做法对于评审人员的理解能力以及产品经理组织评审的连惯性要求较高。

建议四:精心挑选评审人员
产品评审可能涉及的人员包括:高层管理人员、中层管理人员、潜在用户、开发人员、测试人员、交互、UI视觉等。在这些人员中由于大家所处的立场不同,对同一个问题的看法是不相同的,有些观点是和产品的目标有关系的,有些是关系不大的,不同的观点可能形成互补的关系。为了保证产品评审的质量和效率,需要精心挑选评审员。首先要保证使不同类型的人员的都要参与进来,否则很可能会漏掉了很重要的需求。其次在不同类型的人员中要选择那些真正和系统相关的,对系统有足够了解的人员参与进来,否则很可能使评审的效率降低或者最终不切实际的修改了系统的范围。

建议五:充分利用需求矩阵表
需求矩阵表是很好的评审工具,产品经理需将需求列出,通过个个功能需求进行讲解,以及涉及到人员及实现阶段、重要性等进行划分,让更多的人员了解产品需求是什么,以及涉及到的人员,了解各个需求对于产品影响,是否有独立性,产品需求之间的产品功能迭代。列出详细的产品需求,直观的表达给审评人员。

建议六:建立标准的评审流程
对正规的产品评审会需要建立正规的产品评审流程,按照流程中定义的活动进行规范的评审过程。比如在评审流程定义中可能规定评审的进入条件,评审需要提交的资料,每次评审会议的人员职责分配,评审的具体步骤,评审通过的条件等等。通过评审流程执行可能会避免一些人员对产品问题争吵的场面出现,让所有的人员定位好自己的产品评审领域,发挥人员的专业性。

建议七:做好评审后的跟踪工作
在评审后,需要根据评审人员提出的问题进行评价,以确定哪些问题是必须纠正的,哪些可以不纠正,并给出充分的客观的理由与证据。当确定需要纠正的问题后,要形成书面的需求变更的申请,进入需求变更的管理流程,并确保变更的执行,在变更完成后,要进行复审。切忌评审完毕后,没有对问题进行跟踪,而无法保证评审结果的落实,使前期的评审努力付之东流。

建议八:充分准备评审
评审质量的好坏很大程度上取决于在评审会议前的准备活动。常出现的问题是,需求文档在评审会议前并没有提前下发给参与评审会议的人员,没有留出更多更充分的时间让参与评审的人员阅读需求文档。更有甚者,没有执行需求评审的进入条件,在评审文档中存在大量的低级的错误或者没有在评审前进行沟通,文档中存在方向性的错误,从而导致评审的效率很低,质量很差。对评审的准备工作,也应当定义一个检查单,在评审之前对照检查单落实每项准备工作。

产品评审需要面对的问题还很多,做好准备的评审会让你的产品评审过程事办功倍,做好评审意见收集,把好产品“质量”关。

这是下午与公司的相关人员进行淘宝项目评审后总结的,当然在产品Beta版上线后还会进行产品评审,到时更多的是让用户来进行产品评审。产品评审也就那么点事,反应的是产品经理对产品流程及产品走向的理解,同时更是给其他相关人员心理一个底,让更多的人明白你做的产品是干什么的,为什么要这么做,以及如何去做,什么人去做,如何更好的去做,给所有人一个成功的信号传递—产品一定会成功。

产品过程

产品从无到有,从一个想法到雏形到上线的产品,都有个过程。不论是产品、运营、开发、测试等都有自己的职责和工作。很多公司都希望将自己的产品流程化,正规化,希望按照一定的流程走下去,想的是哪天哪个职位出现空缺了,直接找个合适的人可以顶替。同时也为以后的产品工作或项目进程都提供一个模版。特别是对于中小型公司来说,当没有UED,当没有产品相关流程时,产品是否能够按时完成,能否高质量的完成,成为很多产品经理和BOSS担忧的事情。

结合自己的产品经验,同时在不同的公司的经历,将产品流程规划分为8个阶段:立项阶段、设计阶段、开发阶段、测试阶段、上线阶段、磨合阶段、运营阶段、总结阶段。

1、立项阶段
体现产品经理核心功能的阶段,对于产品需求确定,核心功能提炼。产品提出讨论,输出MRD,与技术、业务、资源的可用性,同时确定产品参与人员,沟通是产品经理的一项职能,如何将所有的参与人员集合一起共事,如何更有效的沟通,明确各自的职责。更希望将产品聚焦于可以满足80%用户需求的解决方案,而非20%的用户需求。
2、设计阶段
设计阶段的首要任务就是将产品周期确认,周期是产品经理需与各部门人员配合确定的。产品、交互、UI、视觉、开发、测试等人员在设计阶段更多的是个溶合过程,信息的溶合,目的的明确,同时对于各自工作的明确。产品经理在做出PRD后更多的是与其他人员中的交流与沟通,同时文档的迭代,这个阶段是让所有的人员知道这个产品的核心及功能,交互根据文档出高保真原型,UI根据文档找到产品的表现形式,开发知道产品的核心力体现在哪,技术难题以及实现方式等,测试除了了解产品外对于产品的测试重点及难点掌握。运营则知道这个产品亮点及产品特征等,“好产品是运营出来的”,越早让运营介入产品只有好处。
3、开发阶段
“工欲善其事,必先利其器”。从服务器的部署开始,到最后的代码存档迭代,都将是开发人员做为主导的阶段,同时对于产品开发周期的确定。产品经理更多的协助开发了解产品功能,测试需配合开发做单元测试、压力测试等。运营则是更多的是配合内容数据的提供。
4、测试阶段
当产品经历过初审,接下来的工作就交给了测试,黑盒、白盒测试,以及三轮产品测试。第一轮测试发现产品bug,第二轮测试围绕着bug、以及优化展开,经过第三轮测试过后产品已经归类为较稳定版本。在三轮测试中测试人员需时刻保持着沟通协作,与技术、产品、UI等,这是个磨合的过程,同时也是质量把关过程。
5、上线阶段
这也是beta阶段,这也是开启产品市场的阶段。但在上线前需对产品的代码、系统接口监控、系统维护方案、数据清理等,上线评估阶段需经过市场、产品、运营、开发、测试等对于上线做出整体评估后才能正式上线运营。同时对于上线后的跟踪,日志分析、服务器监控等,同时从日志分析出做出产品调整同时产品运营计划表制定。
6、磨合阶段
经过上线阶段的数据分析,以及数据日志的分析,程序等调整,对于产品做出优化,对于用户常见的问题及反馈做出调整,这阶段更多的是产品与用户的磨合,做到更好的用户体验。
7、运营阶段
软文?广告?产品上线后的工作都将是围绕着用户展开的,如何让用户第一时间用上产品,如何让用户知道产品,如何抓住用户……提供优秀的用户体验,让用户喜欢上产品,爱上产品,离不开产品,这是运营的能力,同时也是运营人员对产品的信任,同时应证一句话“好产品是运营出来的”。为用户提供产品帮助,软件产品更多的是产品使用说明书,而web更多的是FAQ,减少用户“为什么”。
8、总结阶段
学会总结,学会分析,学会批评,产品上线后需要对产品做出个阶段的总结,不论是产品上的,还是人员相互配合上的,有摩擦,有不同的见解在产品过程中是常见的,但出发点一定是围绕着产品,提出意见,产品二期改进及规划,这都可以做为总结阶段讨论的重点,以及如何加强沟通协作,如何做好产品运营。


产品流程并不是一尘不变的,同时对于不同的产品,会有不同的要求。这样的流程同样适用于做项目,对于很多公司没有UED等组织时,如何高效、快捷的做出产品或完成项目,减少不必要的工作,成为流程简化与规范的基础。8个阶段的相关人员都有相关的侧重点,或许期间还有不同的人员介入,比如市场,比如BOSS,任何一个过程都有可能受到影响 ,这时候需要的是配合、需要的是协作。成功的产品会遇到很多的困难与阻碍,但相信自己的产品只是满足80%用户需求的解决方案,别想100%的压力,没有人会为这100%买单的。

附上整理的产品流程表:[download id=”9″]