优秀的产品经理,都做好了这7件事

- 编辑:版本 - 901

优秀的产品经理,都做好了这7件事

【人人都需要的产品思维课】《人人都是产品经理》作者苏杰带班,教你顶尖产品经理的思维方式。戳此查看

本文长度为8000字,建议阅读16分钟

由于环境原因,我们接触到的产品经理似乎总是“特别的”,以至于这个问题困扰了许多人。产品经理到底是什么,我现在做的事情,真的是产品经理要做的事情吗?

作者/枯叶

来源/公众号枯叶咖啡馆

谈到产品经理的工作,“杂,乱”,是最常听到的定义,包括我本人也在许多场合提到了产品经理的工作内容很杂。

这有两个原因,其一,我们并没有掌握这些看上去杂乱任务背后的共性,其二,我们懒惰,相比长篇大论的陈诉以及费尽心思的沉淀,回答杂只需要一个字。

用杂乱来定义产品经理的工作内容,就如同用写代码来定义开发,用画图来定义设计师一样,只是一种自嘲的回应,并不是真正的定义。

这是一个工作的循环,一共是7个环节,分别是接受任务,分析,设计产品,交付产物,跟进进度,验收发布,结果分析。我们来简单讲讲每个阶段的工作性质。

这里提到的接受任务,原则上是产品经理一系列工作的起点,这些任务便是我们的需求

正式工作环境里,我们的需求大部分通过任务性质被下发给我们的,这一点即便是产品负责人,产品总监也不例外,区别只是我们的任务不一样而已。

以产品总监为例,我们会接受到要启动某个新产品的任务,而这个任务或者是由企业上层决定,或者是由战略决定,或者是由市场决定。

其本质上更多的是任务,而不是想做什么就做什么。我们来看看几种典型的任务:

我们增加一个打赏功能吧

我们增加一种消息样式

我们做个转发,怎么样

现在直播很适合我们公司的方向,你来操刀,设计一个直播系统吧

积分等级体系能有效的增加用户的活性,来一发

我们有教育资源,想找一位产品经理来做一款教育类app

当然,除了上级的直接要求以外,我们通过对市场,对用户的了解,也能发现一些问题,发现一些机会,而这部分内容,也同样是任务性质的,只是我们自己扮演者任务分配的角色。

冬日的某天,小雪,A和B两人相约去某地开会,准备打个出租车前往,两人在雪地等了许久,都没有出租车经过。

此时,A抱怨道,要是有一款APP,能让我点一下就能叫到车就太好了(任务下发)

B思考了一下,觉得这是一个很好的想法,于是回应道,咱们自己做一个(任务接受)

于是,有了UBER

于我个人而言,我其实很排斥“想法”,更多的是喜欢以“任务”的概念来驱动项目,想法过于偶然了,具备十足的不确定性,同时又过于廉价,谁没有几个想法呢?而任务却不一样,具备一定要达成的潜意识,我们接受任务或者下发任务时,都持有必须完成的心理.

分析是一个大类的环节,这样的称呼大概会让你感到迷惑,我们先来看看那,分析阶段都包含了那些事情。

市场调研,用户调研,需求调研,技术调研,数据分析,kano模型,马斯洛需求层次,用户画像等等.

在分析阶段,我们运用各种各样的方法来完成对任务的分析,是的,我们所知道的许多看似很高端的名词,大概都是在分析阶段的某种方******。

产品经理是个强思考的角色,这里的强思考主要就体现在分析阶段。

分析阶段在任务接受之后,我们分析的目的是如何去达成任务。

分析的目的在于寻找达成目的的方法,而不是去寻找拒绝任务的理由

很多时候,我们在分析时会有错误的思路,我们会下意识的去寻找能够帮我们拒绝执行任务的理由,这是一种潜意识,是我们需要克服的困难。

我深刻的知晓许多任务,在我们接受时,就已经存在不可执行性,从一开始就注定了失败的,但很遗憾,我们对此无能为力。

就像是士兵一样,服从是军人的天职,达成任务便是我们产品经理的天职,尽管他多么的离谱。

要知道,许多伟大的事情,都是在不可能完成的情况下被完成了。

产品经理接受的任务,极具挑战性质,80%以上的任务都是属于不可能完成的任务.我们的角色,本就是将不可能变为可能,将可能变为现实.

所以,你还在排斥任务吗?或者你是否做好心理准备,迎接一个又一个的不可能完成的任务。

再来说到具体的各种方******,如同我们刚才列举的许多方法一样,其目的都是为了帮助我们分析。我们已然清楚分析的目的是什么了,那如何分析便是这些方******发挥作用的时候了。

这些方******并不神秘,只是包装过于华丽了,我们简单列举几种分析方法吧。

市场调研

我们在获取需求时,最先做的就是市场调研,简单的来讲,就是去分析任务所对应的目标市场,具备什么样的特点,需要什么样的服务。

需要注意的是,此处调研对象是“市场”,比如出行市场,IT市场

用户调研

任何一个产品都是被某人所使用的,我们借助市场调研明确自己要做什么服务以后,就需要做用户调研了。

用户调研的落脚点在于某人,正确的讲,应该是某类性的群体

技术调研

技术调研是在有一定想法以后,我们找上开发人员,简单评估一下技术的实现成本,如果某个idea的实现成本过高,我们可能就要重新想想方案了,许多产品经理在设计产品时,会忽略技术实现难度及成本,这是不可取的。

在应用层面,大部分的需求都是不需要强行攻关的,比如我们要实现支付功能,但并不是一定要自己开发一套支付系统以及安全系统,直接接入第三方就好啦,当然资金量很大时,我们的收益足够平衡我们的成本时,就很有必要自己开发了。

kano模型

需求总是很多的,但前人经过研究,提取出了需求的共性,并总结成了需求的五个类型。

使用这个方法,我们可以很轻易的判断某个需求属于何种类型,再借助该类型需求的价值以及效应,最终来判断出某个需求的优先级和重要性。

产品是被精心设计出来的,这是我所遵循的产品观念,在我体验一款新产品时,我会尝试站在对方的角色,来思考。

如果是我来做,我会如何设计呢?

当我们结束了分析阶段后,我们会根据自己掌握的信息,根据自己分析所总结出来的信息,来设计产品。

我们所使用的每一个参数,都是精心设计的,不仅仅是参数,一句提示文案,也是可以被精心设计的。

只是我发现许多产品落地很差,这点在设计上可以充分体现出来。

于分析阶段相同,设计产品也有诸多的方法,并且经常被我们使用到,只是很多时候,我们并不曾注意到。

设计产品的方法:结构设计,业务设计,流程设计,原型设计,情感设计,MVP设计原理等。

产品经理行业,由于外界盛传的0门槛或者门槛低,导致许多朋友尚未准备好,就进入到这个行业,再加上目前尚未出现通用的技能体系,在实际工作中,许多leader,许多产品老人,都尚未将自己的经验沉淀,最终的结果,是比兴奋更为巨大的迷茫。

迷茫:

从心底里想要学习,并认真的热爱这个行业,但却连自己应该学什么,都感到疑惑。

看不清当下,也看不清未来。

自己现在能力到底怎么样算好还是算差,又或者是一般

下一步,我应该学些什么,如何才能变得更好

其实没有那么复杂,这个行业远比我们想象的还要接近事物的本质,你所欠缺的只是应用的技能,以及对技能的熟练度。

在产品设计阶段,我们的差距更多的体现在思考面积的强弱上,我们掌握的设计方法越多,便越能设计出好的产品。

最合适的就是最好的。

在创业团队里,产品经理可能不会决定项目的成功,但却极大的决定了项目的死亡。

若产品经理没有掌握MVP设计原理,以及产品结构设计,极有可能在1.0版本花费太多的时间,并给未来的产品迭代遗留许多问题。

这将极大的增加创业团队的时间负担,创业而言,每一个小时都是极为珍贵的资源,可以想象,浪费一个月等同于将整个团队置于死亡边缘。

而一次版本迭代,若牵扯到了结构重构,几乎是必然超过一个月的时间耗损的。

在不同的时间,不同的阶段,不同的环境里,我们需要使用不同的设计方法,这就需要我们不断的充实自己,不断的学习。

设计方法之间是不存在正确或者错误的,这完全取决于我们是否在合适的地方,用了合适的方法。

因此,我们无需因为自己设计出来的产品被排斥,被冷淡,而动摇自身的信念,也无需为了失败而感到沮丧。

我们所欠缺的,其实只是方法,那便学习方法就好了,不需要漫无目的的学习。

这些方法并不在已有的产品相关书籍里,而是在于传统行业的金科定律里,相对历史悠久的传统行业,互联网作为一个行业而言,显得无比稚嫩。

现在大家所认识的kano模型,金字塔原理,马斯洛需求层次,没有任何一个方******是属于这个行业原创的,均是来自于对前人知识的学习以及再应用

要知道,早在互联网之前,人们就已经设计出了许多精美的”产品“,我们其实早已掌握了产品设计的”精髓“,我们也早已接触了数之不尽的”产品“。

一段文字,一本书,一部电影,一场真人游戏,乃至我们所使用的碗筷,衣物,都是被作为”产品“被设计出来的。

因此,你,无需感到畏惧,也无需感到迷茫。

我一直信奉团队至上的观点,个人的力量无论多么强大,也需要团队的支撑。

我们在工作中,常常感叹,有一位助理多好,那就能帮我们分担许多工作了。

我们希望有位助理,或者有人协助,本质上是对个人能力的一种危险预警,潜意识在告诉我们,你不行了,你需要团队。

正确处理团队关系,高质量提供交付产物,是我们获得团队帮助所必须要付出的代价。与不同角色合作,需要交付不同的产物,需要记住的是,没有谁是谁肚子里的蛔虫,也不要寄希望和谁心意相通,正如我们无法揣测BOSS的想法,放之他人,也是相同的。

在我们与团队合作的过程中,90%以上的分歧,不愉快都是因为产品经理没有严谨的对待自己交付的产物。

原型图和需求文档是我们最基础的两份输出产物,可直到现在,仍然有许多产品经理以思维,思考的名誉,剥削产物的意义。

产品经理确实是一个强思考的行业,但这不代表我们不需要执行,不需要输出。不需要将我们的思考过程交付给团队。

我把我应该做的做完,我就成功了,置于对方有没有做完,抱歉,这不是我的责任,可我们真的知道自己应该做哪些事情吗?

绝大部分的时候,我们是不知道自己要做哪些事情的,这是这类角色的一个特性,似乎没有人为我们安排明确的任务,于是,我们出现了各种问题,各种花式秀矛盾,如果我们是开发人员,我大概会这么说。

你不是来写代码的,你是来写bug的。

我们来简单罗列一下要交付的产物:原型图,原型全景图,需求文档,变更记录,业务流程图,数据流向图,迭代故事,材料准备,沟通,调整。

并没有完全列举完,我并不想去堆砌交付产物,这似乎没有价值。

交付产物并不是越多越好,而是越有效越好。

以需求文档举例,我们可以看看自己写的需求文档,是否方便研发阅读,是否有歧义,是否已经将功能大部分都覆盖了,一份好的需求文档可以极大的增加团队效率,减少低效时间的耗损。

我曾关注过一个现象,相同的团队,相同量级的需求,实际开发中所消耗时间的差异高达60%期间,发生变化的只是需求文档更为精致,交付产物质量更高。

仔细想想,平时耽误团队时间的,不恰恰是因为需求描述不清晰产生的沟通成本,调整成本,以及由于需求颗粒度不够导致的变更成本吗?

而这些问题,只是需要提高我们交付产物的质量,就能有效解决。

所谓的交付产物是指接力的介质,产品经理所需要做的事情做好了,然后慎重的将我们的努力交给我们的团队。

这是一个很庄重的仪式,很严肃,是对团队的尊重,也是对自己的尊重。

在野外,我们猎杀了一头野猪,大概有100kg,我们嫌弃搬运太重了,就只切了一条猪腿,带回部落,大概只有10kg。当我们再回到狩猎地时,被猎杀的野猪已经被其他野兽吃完了。

野兽就是我们所接受的任务,由于嫌弃麻烦,我们很粗暴的对待自己的原型图,很粗暴的对待需求文档,对待我们的交付产物。

似乎是没有时间,实际上只是因为我们偷懒,而且还是很不聪明的一种偷懒。

如果用正确的方法画原型图,写需求文档,你会发现,这样才是最大限度的偷懒。

现在你知道如何面对交付产物了吗?他并不难,只是需要我们额外的细心,额外的认真,同时,也需要我们尊重团队,尊重自己。

切忌将产品经理等同于思考者,我们除了强思考以外,也是团队中的一份子,思维固然重要,团队力量却远胜于个人的思维

想的再多,做不出来,有什么作用呢?

产品经理需要跟进版本进度,毫无疑问,我需要再强调一下,只有思想,只有想法,是无法做好产品经理的,我们不缺少想法,每一天我们都有许多想法,成出不穷。

2011年,在我第一次创业时,认识了一位灰色产业的朋友,他告诉了我一个很棒的想法,他想要消灭钱包,消灭现金。

人们每天买东西要带钱包,多么麻烦,还要找零,现在手机那么方便,做个软件出来,直接扫一下就能付钱,多方便。

光是手机付费还不够,金额太高,用手机也不方便,我们还得带个手机,最好还是刷身份证,刷脸,这样什么都不用带,要付钱的时候,扫一下脸就好了。

很遗憾,他不是马云,也不是马化腾,他只是一位不那么普通的普通人,现在,人们手机支付已经非常方便了,平时的生活中,我也很少再用现金了。

移动支付产品经理的想法与我这位朋友的想法并没有什么不同,但将想法实现出来却是截然不同的两个概念。

想法固然重要,但也只是重要,真正起到决定因素的,还看我们的做法。

当我们把产物交付给团队以后,我们的事情并没有结束,你需要留意一下,此时你的身份已经变化了。

你的产品从交付的时候开始,出现了变化,此时,团队就是你的产品,团队效率就是你的产品质量。

如果一个团队中没有更高的角色,那产品经理就是这个团队的leader,产品负责人就要对这个产品负起责任,还要对这个团队负起责任。

早会,需求卡片,周会,进度跟踪,风险报警,日报,周报,需求调整,需求管理,资源协调。

这些是我们最常看见的在交付后的任务,尽管我们在交付产物之前,有做技术调研和需求评审,但这并不能保证在开发过程中出现需求障碍。

实际上,无论我们的技术调研和需求评审做的多么细致,总会出现意料之外的问题,这是因为我们的开发同学,在技术调研和评审时,只能根据大概情况进行预测,而在执行时,却会考虑的更深更全面。

在研发阶段,开发会遇到一些较为复杂的需求,会消耗较多的时间,此时,我们就需要根据开发的反馈进行再评估。

慎用技术强攻关,大部分的产品并不是以技术决定胜负的,超过80%的团队,并不需要过于强硬的技术,尤其是小团队,初创团队。(技术性项目例外)

在我接触的许多项目中,再也没有任何一个方法比修改产品方案更快捷了,当出现研发障碍时,修改需求方案,能够节省1天至1个月以上的时间,这需要我们每天跟进跟进研发进度。

仔细想想,我们真的有必要花费这么大的成本去实现某个功能吗?

当我们参与到进度跟进时,会收获许多的调整,为了避免出现需求不统一,也是为了提高交付给测试同学的产物,我们还需要对需求进行有效管理。

需求管理

目的:统一需求,提高需求溯源性,也是为了测试时能依据最新的,正确的需求进行测试,减少我们的沟通成本,也减少需求的不确定性

需求本身首先要能被管理,我并不提倡word版本的需求,也不提倡原型图上写需求,两者皆因为需求无法被管理

其次,当需求评审以后,不再对已评审的需求进行编辑和删除操作,原则上,我们将以取消和新增的状态进行标示。

同时,我们还要维护变更记录,让变更原因,变更内容清晰可见。

这并不是一件简单的事情,需要我们掌握一些方法,比如尝试用excel来编写需求文档,并且在需求文档的撰写过程中,遵守一些规范。

资源协调

产品开发过程中,其实需要用到很多资源,包括内部的和外部的。

当我们需要使用第三方系统时,需要为开发同学准备好第三方系统的账号,key或者其他什么,比如第三方统计,第三方图片处理,第三方登录,第三方地图

而内部的资源集中体现在接口API和设计图输出上,许多时候,我们都是由前端驱动的,我们设计的多数是前端的产品,比如APP,H5,WEB,PC,但前端的功能需要依赖后端的接口,以及UI的效果图。

等接口,等设计图,这两种时间的耗损虽然很可惜,但却是我们经常遇见的问题,如何妥善的安排资源,如何取舍,便是我们要做的资源协调,尽量的减少等待,这需要我们知晓各个功能的优先级,复杂度,尽快进入并行轨道,避免等待

我带产品团队时,会经历两次验收,这里提到的验收是整体验收,我并不是很提倡在开发过程中频繁打包,但我也很理解许多团队,都会频繁的打包验收。

当开发阶段结束后,测试介入前,产品经理有义务进行一次验收,目的是确保主要功能逻辑与需求符合,没有遗漏需求功能,可以称之为需求验收。

当测试结束后,产品经理还需要再进行一次验收,目的是确保产品无明显Bug,能够正常使用,此时,才是真的产品验收。

需求验收

有时,我们需要做好心理准备,也许开发实现的功能与我们的想象的有所区别,甚至南辕北辙。

我们首先需要确认一下,有没有需求遗漏的,通常情况下,会有开发漏做了部分功能,此时,我们就要判断这部分功能是否可放到下个版本迭代,还是当前版本非常重要的功能。

面对一些实现效果与预期效果不一致的功能,我们还要冷静的分析判断,开发这样的调整,能否接受,如果能接受,那就要根据调整结果,来修订我们的交付产物。

原则上,我们希望尽快的切换轨道,需求验收是一个阶段,更多的却是一个节点,我们要把关,但也要灵活,尽量避免过多时间的反复调整。

如何判断哪些需求调整是可被允许的,哪些需求遗漏是可悲允许的,便是我们在这个阶段所需要锻炼提升的技能,MVP原则在这个环节也是适用的。

产品验收

确保产品上线没有明显BUG,不只是测试同学的职责,也是产品经理的职责,当然,我们无法像测试同学一样细致,成体系,成规范的进行模拟操作。

但我们却可以从自己的角色出发,确保主要路径不出明显bug,我们需要保证业务是正常的,核心功能是能被使用的,大部分使用场景是没有明显Bug的。

同时,产品验收阶段也是我们对需求逻辑的最后审核阶段,我们的业务逻辑,功能逻辑这样做是否正确。

这需要我们站在用户的角色,真实的进行体验,可以说产品验收时,我们便是这个新功能的第一位真实用户。

当我们已经完成产品验收了,此时,我们就会通知开发同学。没有问题,可以打包了。

打包的意思是将已经验收的程序独立生成安装包,在android平台,我们往往需要打多个渠道包,每个渠道一个唯一的标示,这样我们就能知道我们的用户都是从哪里下载的。

当然,发布一个版本可不是这么简单的。

产品发布

从硬性角度来讲,我们要为产品发布准备一些材料,比如更新文案,上传安装包以供审核,特别是IOS平台,要预算3-7天的时间进行审核,且可能审核被拒绝。

从软性角度来讲,当我们发布一些特殊的版本时,还需要配合运营的规划拟定发布策略,必要时,可以封包待发布。

即,我们将可发布的版本准备好,但却不真的发布,等待机会成熟,再进行发布。

为什么在一些重要节庆日,成熟的产品都能准时准点的上线特殊版本呢?比如圣诞节版本,如果延期一两天,是否表示这个版本的时间完全浪费了,毕竟圣诞节可不会等你两天。

特殊的版本,我们往往会提前将安装包准备好,进入封包待发布的状态,只要等待某个特定的时间,便可以直接发布版本。

这是最后一个环节了,也是最容易被大家忽视的环节,我们习惯性的将希望寄托在下个版本,寄托在下个功能,却很少对结果进行分析。

当我们产品已经发布了,此时要注意观察相应,观察数据,通过实际市场结果,我们再来思考和评估。

这个功能是否被用户所喜欢,用户使用情况怎么样?有没有提高的方法?

我们知道一个页面,不同的位置,人们的点击欲望是不一样的,相同的发布功能,以点击次数来判断,右上角的发布只占底部菜单的发布的1/10。

我们需要通过产品发布后的结果来持续的去改进,去分析,为下一个版本提供总结性材料。

作为产品经理而言,我们所设计的功能,应该是越来越有效的,而不是越来越多的,我至今仍然记得一个案例。

某网站,进行了一次改版,改动内容是将注册的按钮做的比以前更突出了一些,新版本的网站,注册率比老版本的提高了30%

这里提升的是注册率而不是绝对值,因此我们可以忽略运营或者市场情况带来的影响。

如果我们每次发布后,不对结果进行分析,我想一年经验和两年经验,区别真的不大,甚至再做到第三年,第四年也是相同的。

我们在入门的时候,是以能做出产品为目的的,但当我们能做出来以后,就要学会去分析,去改进,而不是一层不变