写点什么

产品经理笔记 1-1

用户头像
🍑
关注
发布于: 2021 年 01 月 19 日

课程重点在于:

产品经理的意识, 理解了解做产品经理岗位, 它的意义和价值。

梳理整套课程

认识产品经理

  • 产品经理日常都是做些什么事情等等; 一个产品是怎么经过一个过程,最终变成线上特性。

产品思维和产品意识

  • 做产品的直观反映的套路;

  • 怎么去理解产品的利益相关者;

  • 怎样把自己代入到这些利益相关者里面去,找到这个利益相关者可能面临的问题,我们怎么去搞,怎么去找到这个产品方案,然后利用方案的设计,解决他们的问题。

解决方案设计

  • 其实应该归属在产品思维和产品意识里

  • 我们怎样才能做出靠谱的解决方案

  • 解决方案其实是偏答案的东西

  • 做解决方案的思路

  • 还会跟大家分享一些: 去哪儿借鉴人家别人产品的解决方案的一些这个源头,包括国外的境内的 APP 的小程序的,等等。

业务流程与产品文档

  • 此部分偏技能型一点

  • 希望让大家手把手地看,一个好的产品文档是怎么写出来的;

  • 一个好的业务流程是怎么梳理出来的;

  • 怎么用合适的产出物,比如时序图,用各种各样的图示去把整个的业务框架建立出来,去把你自己想要表达的东西表达出来;

  • 怎么画原型

  • 最终完成我们产品的这个期望,其实在这个过程里,我们还涉及到怎么去跟我们的交互设计师沟通

  • 你每一个流程文档里面,你有可能摔过跤,你才知道这个地方,为什么要写成这个东西,我会跟大家分享这些坑

需求评审与产品发布

  • 需求评审是一个很重要的过程。

  • 怎么去做需求评审;

  • 评审的时候,别人会来 diss 你、挑战你,那我们应该怎么样去从这个挑战里头,去重取精的找到自己的问题,然后去完善;

  • 怎么去搞产品发布 ;

  • 包括产品发布之后,发布的通知怎么写,这个其实也是蛮重要的;

  • 你要照顾什么样的人、怎么去体现产品的价值、你怎么在这样的过程里面帮助跟你一起做项目的兄弟姐妹们去争取他们应该得的利益,这些都是做产品经理需要考虑的。

项目管理

  • 很多时候产品经理要做项目经理的事情

  • 从产品的角度来看,做需求分析是项目经理的一个关键职能,但现在我们反过来再去看项目管理怎么弄

  • 介绍相关经验

数据分析

  • 了解我们日常见到的各种各样的这个指标 DAU、MAU、MAC、AAC、LTV、Addressable market(可覆盖市场)等等。

  • 我们怎么看用户行为;

  • 怎么看业务数据等等;

  • 怎么去表达这些数据;

产品规划

产品经理必备的运营思维

商业分析

  • 对于做平台型的产品经理或者做商业产品的产品经理是非常重要的

  • 你看商业产品时,会有这样的一些判断(一个产品它存活创造价值、产生收入、他的天花板、怎么区分产品里面的固定成本和浮动成本等等。),就是所谓的商业 sense(感觉)。

产品经理的软技能

  • 我们当产品经理很多时候,都是在搞定那些不是在台面上的事情,比如我们都是在点燃那些浑浑噩噩工程师、相对平淡的同事,让他们全身心地投入到我们的项目中

个人成长与职业规划

大作业:在线需求宣讲 &共议

  • 准备一个你认为好的产品的点子,然后用一个合适的方案去整理出来。

分享提纲

产品经理的缘起与发展

第一阶段:消费品

  • 第一个产品经理、1962 年、保洁公司,其实是一个做消费品的。

  • 产品经理本身就并不是一个某个环节的新增的这样的一个角色,它实际的行业就是岗位本质,其实是把已经存在的所有的过程变得更融合。

第二阶段:软件

  • 最早的软件行业并没有互联网

  • 做各种各样的软件产品的

  • 更注重项目管理,也就是交付

  • 此时,用户是谁,我们是可以看到、可以聊天,可以发邮件、要求他确认需求、要求他为自己的决定负责、可以跟他一起吃饭、可以说服他。

第三阶段:互联网

  • 互联网行业:追求规模效应、追求边际效应、追求大的用户体量

  • 你需要自己去市场上去挖掘、画用户画像、设计的解决方案、试探性的投放市场、看大家的反馈。

总结:所以这是产品经理的一个发展,它其实是从不做什么特别的事,就是没有什么新事情,到管项目、管交互,相当于相对偏向服务行业。一直到互联网,互联网的这个行业特性,彻底的把这个职业的外延、扩大了,但是他的很多本质,其实是一脉相承的。

一个产品的整个的流程是怎么样的?

1.定义:它需要定义(事先设计好样子是什么、功能是什么、它的流程是什么)。

2.生产:定义好之后,可能有了一个大概的模型,去生产的这个东西,把它做出来,那你可能要找生产方。那硬件产品要找生产线、找工厂,软件产品要找工程师、找设计师交互等等。

3.营销:做出来之后,要营销,就是我们要把这个产品拿出去,让人想要买,让人知道,让人知道他是干嘛的,让人知道它可以给自己带来什么价值。

4.渠道:再之后,我们要找到渠道,能够让他触达到实际最终的买方或者使用方。

5.销售:有了渠道触达到他之后,再去销售,这个销售有可能用户投入的是钱、时间或者经历,我们作为一个价值的呼唤。

运营部分:运营就是把整个过程串起来的。我们要知道什么时候做什么事情、在哪投多少资源、选择什么渠道、选择什么样的品牌调性。

案例:某实体产品经理

  • 他的过程就是他决定要做一个东西去卖。

  • 他在定义产品之前,是把所有我们看起来这个一个一个步骤,好像一个线连起来的过程,但在他脑里是一个整排的东西。

  • 他首先想到的是他最熟悉的渠道是什么,比如说直播带货的 MCN 的机构、线下这个销售的大型会员店的会员体系,以及他们采购方的做事风格,这是他最熟悉的,他从这个地方着手。

  • 他说,我要做一个产品从这里卖出去→看这个渠道里现有的产品结构和产品模式是什么样子→看现在这些渠道所能触达到的用户的客单价是多少→这些用户的需求有可能是什么

  • 他在定义这个产品之前,其实是不知道自己在做什么时,就已经知道这是个客单价 150 元上下,与美相关,功能性很强的产品→再思考这个产品是什么,是面膜/护肤品/运动裤/瑜伽服等等→能找到什么样的生产方,跟什么样的工厂是比较容易能打交道的→例如选了一个品类是做裤子→看材料,从什么工厂,能找到这种生产线,能够做这种材料,在哪儿能够找到这种材料的供应方,现在市面上都有哪些材料,他们的成本大概多少→前面已经确定售卖的大概价格,比如说服装会有一个定倍率,那毛利在什么样的程度,成本大约是多少,成本之下它的材料是多少钱→通过前面销售渠道定义的产品,再看生产能够提供的材料或是供应方的情况→最终反推回定义,这个产品应该做成什么样子,营销的时候要讲什么故事,因为要讲它的功能性,所以说它必须要有功能性→举例:销售渠道和营销渠道,视觉尤为重要,比如直播需要视觉沟通,那么产品要具备视觉卖点和视觉冲击力,需要在产品上加什么样的特性去满足渠道的要求,材料是进口或者国内可以供应,如果是进口,怎么去搞定进口的渠道,搞定仓等等→比如又发现进口的整个过程,是他搞不定或者成本太高。那么回头去调整在所有的渠道里,有一些渠道不能使用了,一些卖点不能讲了,有一些比如说营销故事,要改一下口径

案例:传统的方式

“保洁”产品经理

  • 我定义出一个产品→交给下一个部门,他们负责把我的产品生产出来,沟通=我们开个会,我给大家讲一下需求评审,大家同意了→生产→我在后面盯着,比如你生产的东西是不是我要的呢?不是的话,他可能有什么问题呢?→生产出来后交给营销部门说,你去想一下要讲什么样的品牌策略,什么样的一条故事→营销部门弄完后说,你们去找用什么渠道能卖下去,在这些不同的渠道里,分多少点→给销售定一个业绩去卖

  • 像是一个线性的东西,互相之间用线连接在一起,各个部门互不买账

那我们以为的‘产品经理’,包括互联网行业里面以为的产品经理,是集中在最前面的一个‘定义’环节的,思考一下,我们是不是在干这个事情,每天看用户、老板的反馈→自己有一个规划→定义产品→然后就推到后面去,让工程师生产→给营销部门、运营部门去玩转→找渠道部门最终把它卖出去。是这样一个链式的过程。


我们真正在做产品的过程,所有的东西应该都在我们脑子里,我们要知道用户的反应,怎么样去把内容推给用户,怎么去运营。

上线其实是开始上线

  • 很多产品经理觉得产品发布就是终点,不是结束,是刚刚开始

产品经理简历上通常写的是具备从 0 到 1 的能力,从 0 到 1 不难,真正难的是你做完之后,有了 1 你怎么让它持续地活下去,怎么从 1 到 10 到 100,那才是难的所在。你什么都没有,从什么没有做到有的东西,没有用户灌进来了,没有人骂你,也没有去迭代过,没有看过数据,这并不是产品经理的本职工作所在。

产品经理的职责范围

产品经理是有非常强的横向,可能什么事情都不会自己做,永远都是要借别人的手完成事情,所以它是横向的,他总是需要别人来帮助他完成自己的目标。

产品经理是重叠的,什么事情都会要知道一点,什么事情都要跟别人去沟通,去了解一点。 那意味着什么呢?

  • 产品经理的硬性意义有可能是缺失的。拿案例肥皂来说,过去没有产品经理,人家肥皂卖得挺好,有了产品经理也依然卖肥皂,那产品经理是不是做了别人缺失了他,肥皂就卖不出去的过程呢?其实没有,它是有一个软性的意义。 他把所有做其他事情的人更好地结合在一起,协调的更好,把这件事情做得更成功。

  • 创造的价值和自身边界很多时候是模糊的,要做好‘待到山花烂漫时,你在丛中笑’的心理准备。你要把大家推出来,让大家做成事情,让大家共同的产生价值。但在这里所有的事都可能是别人做的,你只是去协调,把大家放在一起而已,这个很重要。

  • 产品经理最重要的是主人翁意识,分享一个关键词‘责任心(Ownership)’,这就是这个岗位被创造的缘起。 所有其他的人都只关注自己的点,需要有一个人为整个产品的成功负责。要有事情不论是不是你的,你都要去关注并愿意把它完成的意识,或者这样的一个性格偏向。这也是面试里最着重考察的一个性格特质。

协调和安排,就是让正确的事情相继发生,我们不是去做事情,每一个环节都有人做了,营销、生产、销售等等都有人做,我们更多的是 Make things happen,把这件事情营造成 OK 的。


产品经理在软件/互联网行业里的发展,有这样一个过程,项目管理→需求分析→产品经理,其实就是刚才讲的那个内容

最早,我们看需求分析的相关内容,是购买软件工程的书。看怎么去立项、做需求的拆解、研究可行性、研究迭代上线。这里面有大量跟产品经理相关的内容。

  • 推荐一本软件工程的书叫《构建之法》。

最早是项目经理,把客户和开发也就是需求方和实施方粘在一起,把方案定下来,最终交付出一个软件,而我们都是在项目管理里的一个技能。

后来衍化成有专门的需求分析师,把需求方的东西翻译成实施方能听懂的,把实施方能够完成的事情翻译成需求方能听懂的,这样的过程。尽可能的去挖掘需求方需求背后的动机是什么

到了互联网时代,需求慢慢失焦。所谓失焦,以前可以抓住一个邮件,你签字画押,就是这个需求,不能反悔,在这个前提之下去做,是有焦点的。但是慢慢到了互联网行业,我们就很难找到这样的焦点了,我们自己就要负责了。所以逐渐我们就变成产品里面的一个关键角色,就是我们要协调大家去定义产品。

产品经理究竟在做的什么事情呢?

  • 以需求为起点,以方案为桥梁,最终把需求方送到他想要的终点/想达成的目标。

产品经理的工作内容

第一行:来自于需求的来源

  • 是我们自己跟外部关联之后的内容

  • 需求来自于哪?

第二行:在重组过程里面要做什么事情呢?

  • 回到内部,做重组、分析、处理,我们要去识别所有的利益相关方,识别他们的问题,也就是利益相关方的识别和理解。 我们要发现他们的需求,把他们的需求挖掘出来,分析好,就是需求挖掘和分析。 我们还要去做解决方案的设计,比如说拿充值来举例子,我们会发现虽然苹果丢单严重,但是我们没有办法把它换掉,因为苹果要求必须走 In APP purchase,那么我们还能有什么解决方案可以缓解这个环节里面丢单吗?我们可能随便想了一个说,我们干脆微信充值吧,发现这个不可行的对吧,因为苹果不让,那我们再去看我们是不是能捕捉到它是否丢单,帮助用户自动重新开始,其实我们就要看具体的需求文档,看技术文档等等。 像这样的内容,其实就在于自己的内部,你每天大量的时间都是去做这些东西,去探讨去挖掘去思考,把别人给你从外部输入的东西放到肚子里面,去重组它处理它理解它,接下来你形成了自己的想法,你要再走出去,不是自己在闷头想。

第三行:进入到输出的过程,这也是一个对外的过程

  • 走出去,你要评估、协调、规划、列出产品的这个方案、汇报、申请资源、说服你的利益相关方、一起来完成这个项目、把上下游聚在一起等等。

第四、五行

  • 接下来,汇报成功了,你要成立项目组、协调和管理、跟进; 开发做完之后要做测试,功能测试、可能性测试,写出各种各样的非功能性的需求点等等; 然后你要验证和发布。

  • 发布之后→分析有没有发生了什么事情→观察和反馈→不断的调整迭代

输入→校验→处理→输出

  • 这就是整个产品在进行过程中,每天要做的事。不断的是从外部输入进来→自己沉淀、理解、思考,处理→输出去→外部的反应又输入进来→去做处理。

  • 我们在做需求时,理解产品和用户之间交互的一个大的框架,我们后面讲写 User case(用户案例)用户操作流程也是这样的四步。

  • 所有的用户和系统之间的互动,都可以用这样一个大的框架去套,而我们的工作,也可以用这样的一个大的框架去套,外界的输入→自己的重组和理解处理→最终可输出。

第六行、七、八行

  • 产品上线后→进行推广和运营。 小的团队其实没有专门的测试人员,产品经理负责做测试、验证和发布、做客服、运营和推广。 大公司别人主做,你要参与在旁边看看,从别人做工作的角度里面去看自己的产品有什么改进,做设计组织和流程。 带团队之后,可能要考虑把不同性格的人,放在不同的产品里去等等。

没有测试人员,我们产品经理是要写测试用例的。有时候会用 User story 方式来写:我是谁,我接下来想做什么。这些东西我们会提前给开发,这也是环节里面非常重要的一点,开发里有 TDD (Test-Driven Development 测试驱动开发),而做产品时,我们也要 Test case Driven design,直接站到场景里,用户要做什么事情、遇到什么困难,我们把这些东西放在最前面,放在需求分析、设计评审前,让所有人知道我们做这些东西是干什么用的,去描述产品具体的场景,我们最终的落地场景提到前面去,可以帮助我们比较好的去做设计,比如说验证和发布也是产品经理的工作,先发到预发环境上,你点一下看一下,没问题,说发,发到服务器上,去发布通知、发用户通知,这都是产品经理的工作,所以把可能的工作都列在上面,都是在干这些的。

举例:邱岳本人经历

  • 我们有一个产品叫拍东西,是一个拍卖的产品。当然这个产品不是特别成功,它的用户量和交易量都没有达到我们预期的效果,但他依然还在运行,因为我们的功能非常完整。 这里面的具体的特性,叫做降价牌,传统的拍卖就是我们在一起,我说 20 你说 30 你说 40,最后 40 没有人再加了,数三次,一敲锤 40,你买了。 什么叫降价拍呢?比如说只有一件,从 1000 块钱开始,我们所有人都在等着,每过一段时间降到 900 降到 800 降到 700 降到你的心理预期的时候,你说我买了,那只要你买了这些东西就归你了,其他的竞价者就抢不到,所以他也叫荷兰式拍卖。我们传统拍卖产品,最早是一口一口叠加式这种,叫英格兰式拍卖。 后来什么原因我们决定做降价拍/反向拍的功能呢?我们发现有两个问题,一方面是网上叠加拍卖的方式并没有很好的用户传播,好像大家对这个事情并没有多感兴趣,没有达到我们预期的那种大的用户体量和大的交易量的规模,另一方面,我们发现这种加价式的拍卖,一次只能卖一件。比如说你 30 我 40 一敲,最终你 40 买走了,一次只能卖一件,但是减价式的拍卖可以卖很多件,这个需求是哪儿来的呢?是我们做了拍卖、研究拍卖,我们天天做所谓的行业学习,也就是第一行的第四个,我们就去研究拍卖的各种各样的方式、他们的故事、他们的规则,发现有降价拍的方式,那是不是可以引入呢?相当于来了一个需求,在开会/日常聊天的时候,说那我们做一个降价拍的功能呗。产品经理拿到了这个降价拍,其实就是一个需求的输入,就是一个可能做的方向。降价拍其实是一个解决方案,这并不是一个非常好的典型的产品需求发现的方式。但是,他接下来要做的是,从这个方案拿进来之后,去看,如果做了降价拍,完善了拍卖的功能是不是可以批量的卖出产品?因为降价拍就意味着,比如我有 1000 件,不断地把它降价,降到的 900 块钱的时候,有些人觉得 900 块到了我的预期了,我就开始买,其他的人看到一边买一边的库存量会降低,就会跟着去买,有可能在一个拍卖的过程里会卖出更多的产品。那他可能把这个拿过来,在自己的框架里分析,发现拍卖有发起方、买家、卖家、围观的,其实就是在做第二行的相关方的识别和理解,去需求挖掘和分析,最后觉得这个事情似乎可以一试。有了输入、重组和处理之后,有了这么一个判断,他就去研究这件事情可能给系统带来什么样的影响,界面做出来有可能是什么样子的,他开始去做解决方案、设计,找开发研究说,我要做这个功能,每 30 秒,降一个价,它必须是同步的,所有人看到都是一样的,买的时候要锁掉库存,不能超卖等等,开始研究这些具体的细节,把各种可能的意外情况列出来,具体的线框图列出来,跟开发讨论是不是可行的,如果要做,需要多少工时,做了一堆线框图和大概评估,有了评估后,做一个方案,其实是一个汇报过程/商量的过程,我们说要花 7/8 个工作日做这样的一个功能,做这个功能有可能会产生什么样的影响,有可能会让正常的拍卖的数量减少,有可能会让交易下降,但同时又可能让我们一下卖出多个产品,可以吸引一些要批量卖东西的,而不是卖非标品的人。在这个过程里我们要去把运营也抓进来,聚拢上下游,问他说,我们现在要做这个功能,你能不能帮我们去找一些有类似需求的人呢,运营看了看来说我可以试试,我们有一个这样的用户池,他可能是微商,要不断的往外甩货,我们就不断的去碰,不断的去完善这个过程,接下来就是整个的判断,可以那我们就搞吧,我们做一个功能尝试一下,这时候呢,我们又提出一个观点,我们不能一下把整个功能全部做完,我们是不是先做一个小的功能点试一下,比如说做一个入口,看看大家的反应,不要做的很复杂,一下子就卖很多件,我们就先做一件,然后又有人提出来,是不是要做预定功能等等,围绕这个大家不断地去聊,最终就圈定了一个相对比较小范围的东西,也就是 MVP(最小的可用模型),先试试这个需求是不是真的存在、用户是不是真的买账、大家是不是真的能够聚拢出这么高的一个参拍方的水位,让这个事情可以 work,然成立项目组,接下来可能不到一周时间要设计需求文档什么时候出,前端什么时候介入,做完了之后什么时候测试,什么时候后端,什么时候发布。大概是一周的时间,每天产品经理要做的就是去找这个人问,你怎么样了呀,然后找那个人,你有没有遇到什么困难呀,或者去给后端讲讲需求,有时候后端会发现说你这个不对,你的逻辑不完整,再去改改具体的需求文档,等等,每天就是很细碎的事情, 发布上线之后,把这个功能跟运营说好,推出去给一些微商让他试用一下,我们观察这里面可能会遇到什么问题,发现其实有大量的流拍,如果没有很多的人,只有两三个人,降价的时候,不会有那么强烈迫切的购买冲动,你觉得反正就两个人,不会有很很热烈的竞争,就等,他可能一直从 1000 降到 100,你还不买,它流拍了,最终大家也就走了,其实成交是很少的,或者都买在了底价上。当时我们还认为可能有一个前提条件是,必须具备大量的用户参与,也就是提前等在这儿/围观在这里,相当于买家水位比较高,它才有竞争,所以我们又做了一个预约和提醒的功能,甚至把这个拍卖的时间压得尽可能短,让大家都在这里面不要走掉,我们持续做了这样的调整。后来发现我们依然没有办法把这个事情做得很好,这其实就是你发现了问题,我们做了调整后又上了新的特性,不断的想要回答这个问题,发现都没有回答的好,最终我们认为这个功能最早的判断,相对来说不是那么的成功,我们就没有再继续在这个功能上迭代了。大家可以看到整个的这个过程产品经理都是参与其中的,他要做的大量的事情就是输入、思考、方案、输出,团局,推着事情,把事情推上线,接下来就是去看,没成功,为啥没成功呢?是因为水位不够,那我们再上两个特性,把水位往上推推,提前预约,让买家都来盯在这儿,后来发现做了几个之后依然不行,要不就是我们的流量能力不行,要么就是我们对这个行业的理解不够,要么就是用户卖的供应选品不行,但是到了那个时候,我们认为继续试下去,对我们来说已经是一个投入产出比不高的事情了,那么我们就暂停了。这就是我们整个做的一个过程,就是刚才说的 MVP 第一次效果不好。

  • 要做迭代吗?要,一定要做迭代,比方说,我们认为水位不足我们要把水位推起来,我们是用很方便的方法去做的:如做预约的功能,把大家招进来;或我们有流量池,在那个时间点,把流量大量的放进来,用一个相对来说比较低的代价去完成这个假设。但是还有一个选品不行,像这样的假设,我们要去验证它,对我们来说就是一个投入会比较高的事情,我们认为以我们团队的资源储备,不应该再试下去了,跟大家对这个事情投入的决心和对这个事情投入的资源情况都是有关系的,我们就喊停了。但一定是有一个终止点的,迭代之后的终止点的。 这个是跟大家分享的一个我们实际的过程,输入重组输出调研聚拢上下游测试迭代,其实做的就是所有这张 PPT 里面的事情。

产品经理典型的每日工作内容

第一件事情,就是看数据看反馈看资讯。

注意: 1 这件事情,其实是独处的,看后面写了一个‘自己’。 2.‘↑’代表这部分的时间是应该想办法增加的。

  • 每天上班第一件事,通常是看看不同的数据平台昨天的 DAU(日活跃用户数量)是多少、昨天的交易是多少、昨天的迸失/流失是多少、昨天的转化数据有没有问题、关键的业务数据是什么,这是日常的例行看数据,可能花一个小时,或者更长一点的时间。

  • 然后看反馈,看用户的反馈,看用户发的邮件,也可以上网去搜用户给你产品的一些建议,看媒体对你产品的一些评价等等。腾讯有一个要求是产品经理每天必须要有一定时间去看用户论坛,看用户怎么谈论你的,怎么骂你的,做用户干预。

  • 行业资讯:国外的行业资讯、微信公众号

  • 每天不停去看,玩,下载一些新产品,或者打开一些没有听说过/过去听说过的产品。 有时可能也玩不出什么特别的,但你不断地玩,你会跟这个行业有一个共同的脉动,你知道他每天发生些什么。

  • 你要拿出更多的独处的时间来看数据、吸收、思考、玩新产品、看业内的资讯,看别人的反馈,大部分的产品经理应该努力让这段时间增加。

  • 可以记记时间笔记,看看每天都在在干嘛。

第二部分的工作就是开会和聊天,是产品经理占用大量时间的一个事情。

  • 甚至有的产品经理一天八小时可能有六小时都在不停地开会、在 emile 上跟别人聊天,这很重要。重要是因为:

  • 这一部分我不认为他需要增加/减少, 我认为这一部分的工作需要调整、观察,需要注意你在开会和聊天过程里面的信息消费效率,什么意思呢?就是你要保证你开会的半小时是有效信息沟通的,或者能有效的目标达成的,你要注意跟别人不能真的去聊跟工作不相干的事情,要学会让自己聊天的时候,尽可能地提高在聊天里,大家互相交流信息效率的这样的能力。

第三部分:思考分析

  • 第一、二部分都还是在输入,是在从外界向自己的体内输入东西。

  • 而思考分析是你要把业务、需求、要做的项目、当前的部门形式和团队形式等等放进心里。你要去想、去推演、去摆出这些逻辑,所以这个也是独处的时间。

  • 然而对于大部分产品经理来说,这一部分的时间偏少,应该尽可能的增加。当然大家日常都被开会什么的占用了,但我觉得是要有这个意识,我们需要有更多的独处沉淀思考的时间这个是很重要的。

第四部分:图文写作

  • 图文写作也就是写文档、画原型、画概念模型,画业务图例、写备忘录、写会议纪要等等,要有产出。

  • 很多人会把需求分析和写需求分析文档,这两件事情混在一起,大家觉得需求分析就是写需求文档,写需求文档的过程就需求分析。事实上应该把这两件事情分出来,拆开来看。需求分析是做需求分析,是一个思考的过程、是一个推演的过程;写需求分析文档是把你成型的思考落在文档上的过程。

  • 大家要有意识地把这两个过程分开,需求分析就是分析,就是思考、就是自己独处的时候;图文写作是写文档的过程,属于技能性的东西,回头我们会讲。 我们应该尽可能降低图文写作中纯写作过程的时间,提高自己独处去思考的时间,这是一个很重要的,我想跟大家分享的东西。

第五部分:干活

  • 典型的每日工作内容,大量时间里的干活儿可能是测试、客服、运营执行、帮人提数据、跑来跑去等等。要关注一下占比,不要太多。

  • 随着你向上的晋升,负责的内容越来越多,带团队后有可能逐渐的减少干活时间,你要关注自己每天干活的时间,让自己干活的效率更高,你要知道这段时间,我可能做一些事务性的工作,它对自己的成长,并没有那么大的帮助,你要关注这个。

产品经理的工作内容的分类方法和分类维度

把所有的事情收归到一个叙述框架里面,我们去分类,不同的事情分别是什么样的类型,我找了很多的分类方法和分类维度。

执行/规划/创意是一套方法论。 【1】是俞军老师的,推荐书《俞军产品方法论》就是对于产品经理工作的分类,协调、生产、需求、定义和销售。 【2】是结网的王坚老师写的一本,很早以前互联网产品经理的书,战略性工作、阶段性工作、日常性工作。 最后这个调研推演/推进落地/总结调整/收拾烂摊子,是我自己的一个维度。

这个维度是什么意思呢?

是你从不同的维度去看,做的虽然都是这些事情,但是你用不同的方法把它分类,你可能会看到产品经理工作的不同的叙事框架,有时候叙事框架可以影响我们的工作态度和工作流程,所以大家选一个自己觉得符合你业务,且你自己也喜欢的叙述框架,根据这个叙述框架把自己的工作安排在里边,你看每天在这个框架下你执行了多少时间。

根据自己工作的框架,看自己分在不同分类里面的时间大概是多少,我在哪一个分类下做的事情不是那么的好,效率不是那么的高等等,有了这样的一个框架,你会有不同的对你自己工作的理解。

  • 比如说,我举个例子,刚才讲到 To G 的产品,你可能做出 To G 的产品,你的工作的框架就会跟我刚才讲到的这个是不一样的,你可能会有很多的时间是用来沟通的,你要面对那些职能部门,你需要跟他们达成一致,你可能会把自己的工作分成沟通解释和对齐,方案生产和落地验收等等,你会有这样的一个框架,所以你要根据自己的工作,有自己的一个每天工作内容的框架,这样是很重要的。

笔记软件推荐:flomo 记录灵感

产品经理的考核标准

判断一个创业者对这个行业是不是理解,或者对自己的产品的本质能不能讲清楚的时候,你其实一个特别容易的方法,就是你就直接问,说你日常关注的最重要的指标是什么?举个例子,我问他,你现在这个阶段最关注的知识星球的三个指标是什么,他会给我讲一个指标,他关注的是 7 日 3 活,就是七天的市场里面有三次活跃的这个数据,从他的这个指标里能看出大量的他关于这个产品本质的理解,以及他产品的特性、他对这个行业的理解。

  • 如果你做的产品是一个很特别的社区,像知识星球这样的,你会发现做这个产品久了的人,他对这个产品的的理解是有意思的,他能够告诉你很多关于这个产品背后或者关于这个业务背后的核心的洞察。那如果你问一个创业者也好,或者你问一个产品经理也好,说你的日常关注的指标是什么,他告诉你就是 DAU、次留,只能说明他对这个产品或者说业务的理解不深入,这是我自己的一个经验。我在面试产品经理的时候,有时候也会问这个问题,比如说他是一个做工具的。我问他,你最关注的数据是什么,做电子词典、天气预报、手电筒的合作计算器的都是软件工具, 他们要关注的指标应该是不同的,应该这个指标里面蕴含着他们对自己的这个业务的深刻的理解和洞察,我们很多时候是要通过考核指标来看行业的本质和不同阶段的工作的。

怎么给产品信息定 KPI 定呢?

过程性的标准,考察的是执行力。我们会定,比如说你的延期率是多少,你要做的项目是不是每一次评估都有问题,你带的项目是不是总是在延期,可能有一些相对来说比较成熟的产品线,延期率就会成为他的一个比较重要的考核指标,注意,成熟的产品线也意味着对这件事情的理解,成熟产品线的产品经理很重要的是要保证你规划的东西每次都能落下去的。

延期是项目经理负责,但是产品经理也要负责,如果产品经理不能在前期把项目范围和需求描述得足够清楚,势必会导致评估的不准确和延期,所以产品经理也是要参与评估的。

比如你能做一个 1000 人日项目,我就觉得你肯定比做 10 人日实验项目的产品经理能够协调的事情要多一些,那这也是一个考核标准。

  • 人日:就是我们在项目管理里,我们说项目的规模是需要 10 个人干 5 天,10*5=50 就是 50 人日,人日越大就意味着我们涉及的人越多,涉及的项目周期越长,也就意味着项目的复杂度越高,所以我们会说规模用人日来评价。

ToB 产品经理经常是要把满意度放在考核指标里。

如果你带的不是一个具体的业务,就是一个做功能模块的产品经理。比如你这个月的 KPI 就是把邮箱的抄送功能上线,只要上线你的 KPI 就完成了,没上线的 KPI 就不好,这个阶段考察的是你能不能按时交付的能力。

数据指标通常一个成熟的负责产品线的产品经理,大部分的 KPI 都是数据指标,最主要分两种

  • 一种是产品的数据指标,新增:你一个季度新增了多少用户;留存:你的新增留存是次留或者周流能够做到多少,你的转化率能做到多少;传播等等,跟产品实际相关的这些指标。

再往上走,业务指标,你负责的这个产品,一年能赚多少钱,平台规模能做到多大,兼并能做到多大。这是更高级一点的产品经理的工作。

团队规模,比如你带了团队之后,你的 KPI 里有一条是招满/裁掉类似这种。

个人成长的指标,学习/读很多书/建立自己的影响力/在团队里做分享/你的判断力怎么样,你过去判断的事情,多少准多少不准的。

你在不断往上走的过程中,你会发现是从模块的交付→对产品整体效果的负责→对整个的公司业务负责的这样的过程。

产品经理的上下游与环境

我们平常接触什么人?

在公司内部: 我们接触的最多的,从上到下首先是业务和运营,很多时候就是他们在一线做直接跟客户和业务运转相关的内容,他们会给我们提很多的需求,会帮我们反馈不同用户的诉求以及反馈现在遇到的问题。 往下,我们会跟设计,做页面交互的人联系,会跟研发就是开发工程师有关系,会跟测试工程师有关系,会跟我们的运维和项目管理就等等。这些其实是在实施过程中,我们需要联系的不同部门的人。 再往下呢?市场/营销,算下游也算上游,他们会决定做什么市场活动,决定打造什么品牌调性,决定做什么样的营销策略。 我们还有一个特别重要的接触方是财税法合规,尤其是在大公司里,财税法合规基本上是压在我们业务部门和产品部门头上的三座大山。你要做什么,财务告诉你这个不行,税务告诉你这个不行,法务告诉你这个不行,都是有可能的。 所以我们一定要知道,我们要跟这些人打交道,每个人会有不同的诉求,比如说业务和运营,他们直接对业务指标和运营指标负责;设计研发测试,他们要对交付负责、要对自己的质量负责、同时要对自己的个人成长负责;市场营销可能要对品牌负责、要对市场的营销策略负责等等;财税法合规他们只有一个目标就是不出事儿,不出事儿的意思就是他希望你什么都不做就不出事了,但你还是要跟他打交道,你要告诉他业务的意义,想办法来找到一个他能够接受的方式去跟他把这个事情推下去。


对外:以后再讲

奥利奥:很多产品经理都会发现自己的角色,就是奥里奥中间的白色的奶油,两边又黑又硬跟自己夹在中间。你要把两边又黑又硬的诉求利益和原则,尽可能的弥合在一起。你自己的身段要足够软,你才能保证这件事情能够把大家协调在一起,当你觉得特别不爽的时候,现状的两边都是又黑又硬了,你中间要软、要纯洁要雪白,也想跟大家讲产品经理的一个很重要的特性吧,好的产品经理通常在做的过程中,他的身段是很软的,他有可能态度是很硬朗的,有可能做一些判断的时候是非常果断的,但是他的身段柔软,他知道怎么协调大家把这件事情做成,但是内心是非常硬朗的,这就是好的产品经理的一个特性。

产品经理的不同种类与发展

介绍不同的种类有些什么区别?

一策略产品是这一段时间逐渐活下来的,产品什么是容易抄?脸是最容易抄的,你做什么样的功能,做什么样的界面、做什么样的交互,很容易被抄走,但是你的策略是抄不走的。做策略产品是做什么呢?比如说,你是滴滴的策略产品经理,你要确定一个分发/派车的策略,确定这个人叫了车之后,从哪里去给他调度车、调度什么种类的车,才能保证整体的调度效率最高、用户体验最好。其实是需要非常强悍的建模能力的和逻辑思维能力的,他可能不用去考虑界面,也不需要去考虑各种其他的用户方面的东西啊,它重要的是要去看怎么去建一个很好的模型,把不同的参数放到里面来,给不同参数不同的权重以便得到一个最好的目标结果,他很像是我们大学里头学的数学建模那门课。比如说我们知道在派车的时候,距离很重要,司机的排队时间也很重要,某一个区域的用户密度很重要等等,这些可能都是我们要考虑在里面的参数,我们要有一个建模的能力,算法工程师在这里面有很重要的工作,但是在业务方面的判断很多时候是策略产品经理来做。

AI 产品经理是干嘛的呢?他需要去规划算法的数据,比如说测试数据训练数据,他需要去找到不同算法落地的产品方案,他还需要把那些算法做得不够好的东西,用工程的方式给他兜住,用产品比如说文案的方式把他兜住,所以说,它更多的是要严密的和算法工程师结合的一起,知道算法的局限性,把算法的这个局限性包装成产品特性推出去。 数据产品经理很多是做数据产品的, 现在有很多用户增长产品经理,其实他要做的就是把不同的产品部门串起来,然后共同的完成用户增长的目标的这件事情 商业产品的产品经理就是你要知道怎么赚钱,成本怎么估算,利润是多少,你要设计出什么商业场景来商业化变现 内部产品就是我们内部公司内部用 ERP 等等。 你怎么看哪一个方向适合你呢,其实你就把这个岗位拆成两个维度来理解,一个是技能维度,一个叫行业维度,有一些是跟行业相关的。比如说供应链,你知道这个是行业维度。你要想的是自己喜不喜欢这个行业,在比如说这个这个音乐产品经理。其实他说的也是行业维度,你你再看这种领域的时候,你要优先考虑的是,我对这个行业是不是热爱,我喜不喜欢这个行业里面做事情他跟技能是没有关系的,你想这个行业,你想象成为这个行业的专家,你在找工作的时候,就先想这个问题, 然后另外一个方向就是看技能维度,你从不同的那个岗位描述里面就可以看到他需要学什么技能,然后你也可以去问一问,在我们的群里头去问一问相关的产品经理,你比如说做策略,你需要些什么样的技能,建模能力、逻辑能力、学习能力, 然后你做 AI 需要一些什么样的技能,你是不是要大概学一些简单的算法买本入门,或者在 B 站看几个算法的教程对吧? 你比如说做这个云计算,你是不是要大概了解一下啊!不同的就是计算机或者服务器的组成结构对吧?等等, 所以说,你再选工作的时候,其实是这两个维度去看了一个是你喜不喜欢这个行业。一个是这个行业相关的技能,跟你掌握的技能,以及你想掌握的技能,有没有一定的关联,就是用这样的方式去思考。

课后解答


发布于: 2021 年 01 月 19 日阅读数: 83
用户头像

🍑

关注

歪比歪比,歪比八卜 2021.01.07 加入

goodgoodstudy,daydayup!

评论

发布
暂无评论
产品经理笔记1-1