05 | 硅谷产品经理每天在做什么?
下载APP
关闭
渠道合作
推荐作者
05 | 硅谷产品经理每天在做什么?
2018-05-01 曲晓音 来自北京
《硅谷产品实战36讲》
课程介绍
讲述:丁婵
时长12:44大小6.03M
前面的文章我讲了产品经理的工作性质和内容,但是还有一个非常重要的话题,就是:产品经理的一天是什么样子的。
有人说产品经理每天就是和工程师互撕,也有人说产品经理每天各种开会,还有人说产品经理每天就是坐在电脑前画画 UI。作为一个在硅谷工作多年的产品经理,我每天的日程其实都在变化。 下面我就通过一个真实的案例,详细说说产品经理的每一天是怎么度过的。
案例背景: 发布新版视频版权管理系统
我们要发布一个最新版的视频版权管理系统,目标群体是视频制作者, 包括传媒公司、音乐公司、电视台等。在 Facebook 上有大量用户的视频,我们需要确保视频制作者的版权内容不受侵害,并及时处理掉侵权内容。
我们的第一版产品,可以帮助视频制作者非常轻松地管理自己的版权内容,在 Facebook 上为他们寻找侵犯自己版权的内容。现在,我们需要确定下一个版本应该有什么新的功能。所以我花了大量的时间,和用户进行一对一的讨论,和市场营销经理一起做市场调研,同时和数据科学家一起仔细研究已有用户的特点。这个阶段, 一般会持续两到三个星期, 最终的结果是制定一个详细、具体的产品功能需求列表,并且弄清楚每一个需求的优先级。
我们通过一系列的市场调研和用户调研发现,第一版的产品虽然可以帮助视频制作者找到使用他们版权内容的视频,但还是需要他们手动找出哪些视频是已经购买了版权的人发的,哪些视频是侵权用户发的。然后,他们要将这些侵权视频报告给 Facebook,Facebook 才能删除。这个过程对于那些小的视频制作者来讲还比较轻松,但是那些大的媒体公司会有数以千计的侵权视频,所以手动报告对他们来讲是非常痛苦的。
其实,我们还发现了一些其他问题,比如第一版的产品只能在电脑上使用,而不能在手机上便捷地处理,这对于每天奔波在录影路上或者片场的独立视频制作人来讲很不友好。但是,这个问题与手动低效的问题相比,对用户的影响要小得多。毕竟,这个版权管理系统的用户大多来自中大型的视频制作公司,帮助他们通过最聪明的方式报告侵权视频非常重要。因此,我们决定第二版的产品主要解决这个问题。
产品经理在开发初期的日程
2 月 15 日
10:00 用户调研
12:00 团队“头脑风暴”产品功能
13:00 午饭
13:30 和其他组产品经理谈合作
14:30 和工程经理讨论产品的成功指标怎么确定
15:00 思考时间:思考一下如何整合用户调研的结果
17:00 和营销经理讨论一下市场调研的情况
18:00 晚饭
19:00 下班时间, 但是要回复一堆邮件和工作信息
这天早上,我首先完成了最后一个用户调查,其实我们已经通过之前的调查发现了手动低效这个问题是最大的痛点,所以今天的用户调查是通过采访一个中型媒体公司来确认我们的发现。
然后我就和工程师一起讨论, 有什么方式能够解决这个问题,这就是 12 点到 1 点的会。在会议开始前我需要做一些准备工作,布置好场地,提前准备好“头脑风暴”流程。
因为我们现在所想的功能需要使用另一个产品的一些功能,所以我需要和这个组的产品经理讨论怎么能够利用他们已有的资源。
之后,我马不停蹄地去了成功指标的会,讨论怎么才算解决了手动低效这个问题。 最后我们一致决定, 判断是不是能够提高效率的方式就是,对比视频制作者在有这个功能之前和现在每天举报视频的数量。如果能够提升 10% 就算成功,否则就需要修改一些产品功能,来提升这个数字。
然后我花了很多时间在思考,把前几天做的用户调研以及和大家“头脑风暴”的内容进行整合,撰写产品需求文档。对我来说每天能有属于自己的时间非常不容易,但是我只有在这样的时间里才能真正思考,所以我非常珍惜这两个小时。
最后一个会,主要是看营销经理给我的市场调查报告,然后我发现市场调查的结果和用户调研的结果非常相似,并且一个竞争对手已经有了类似的功能。
产品经理在开发末期的日程
4 月 20 日
10:00 Stand-Up 会议,也就是“站立会议”
10:30 和设计师一对一
11:00 和工程师、设计师一起决定方案
11:30 和老板一对一
12:00 和新来的同事吃午饭,介绍我们组的情况
13:30 部门产品经理组会
14:00 自由时间,和几个工程师分别讨论他们遇到的问题,帮他们和其他组沟通
15:00 讨论几个产品小功能的优先级
16:00 面试产品经理
17:00 讨论营销公关策略
这时离我们预定 5 月 5 日进行产品发布的时间已经非常近了,所以最重要的开发部分其实已经完成。 但是上周, 其中一个工程师发现已有的架构无法实现设计师的这个功能,所以需要设计师用我们能够支持的方式,修改之前的设计,这就有可能增加开发时间,发布时间有可能被拖到 5 月 8 日。
在这个背景下,4 月 20 日,我先参加了工程师的站立会议。因为我们正处在最紧张的开发阶段,所以每天早上所有工程师、工程经理和产品经理都会在一起,交流昨天完成了什么, 今天要做什么。目的是激励大家高效工作,同时也可以及时发现工程师的开发难点,并当天解决。这样的站立会议,一般都是在早晨大家开始工作的第一时间进行。
我今天最重要的任务是,帮助设计师修改产品设计方案,从而解决我们现在的架构限制问题。我先和设计师两个人坐在白板前思考有几种方案,每种方案有什么优缺点。然后,11 点,我、设计师、工程师坐在一起商量,决定哪一种方案能在最短的时间内完成。
之后,我和老板每周的单聊时间开始了。我需要和他讲讲最新的进展,有什么需要他帮助我的,有什么是风险较高的内容。一般对于比较重要的决定,我会拉他来一起参加会议。这次设计师方案修改的问题,我们自己已经做好了决定, 所以我就和老板简单地说了一下,他表示赞同。
其实产品经理还有一个重要的任务,就是帮助团队招人。我现在需要招聘两个工程师,所以我的午饭是和一个刚来公司不久正在选组的工程师吃的,目的就是了解他的情况,向他推荐我们组。一般这种对话,产品经理需要讲讲未来的策略和愿景,让新人愿意加入,并且觉得有很大的发挥空间。
下午一点半,是我们整个部门的产品经理要一起开的例会。例会一周开一次,整个部门 20 多个产品经理都要参加。具体内容是,分管我们部门的副总裁和大家讲讲公司上层近期的想法和决定;邀请其他部门的高管来讲讲他们的计划,看看有什么可以合作的;如果有什么新产品发布,负责的产品经理会和大家介绍一下。
之后我有一些自由时间,一般会找到具体的工程师,到他们的办公桌前,问问他们有什么需要我帮忙的,现在有什么风险高的问题还没有解决。我发现,这样的形式比动辄开会要高效很多。所以,如果不是需要每个人坐在一起解决的问题或决定, 我一般都会采取这种方式快速解决。
3 点我要和技术主管、工程经理一起讨论一下现在还没有完成的 5 个小功能里面,需不需要砍掉几个功能。因为发布时间近在咫尺,我们具体分析了功能的优先级。我跟大家说了说我的想法, 大家表示赞同,速战速决。最终,我们决定砍掉 2 个功能,保留剩下的 3 个。
4 点我面试了一个产品经理。因为是第一轮,所以是视频面试,主要考察他的分析能力。这个面试进行了 45 分钟,我觉得他表现一般,按能力进不了最后一轮。
5 点的这个会是临时加的,因为 5 月 5 日发布的可能性不大,所以我们想讨论一下推迟发布的事情。我现在的想法是 5 月 8 日发布,但是营销经理说他刚刚了解到,我们部门的另一个产品也要 5 月 8 日发布。如果一起发布,就需要找到一个共同的主题;否则,最后发生冲突,就会丧失宣传的好机会。所以如果不能和他们一起,他推荐我们 5 月 10 日发布。
总结
通过上面的这个真实案例,你应该可以发现以下几点。
产品经理的工作内容取决于产品发布的阶段。
开发初期,产品经理需要花更多的时间在思考上。这个阶段主要弄清楚要做什么, 所以需要花大量时间做调研、策略以及制定产品功能需求。这时和工程师交流的时间比较少,更多的是和调研、市场的同事们一起。
开发最紧张的阶段, 产品经理需要花更多时间在执行上。这个阶段需要花大量时间解决开发难点,根据困难和挑战修改之前提出的方案,并且和营销部门讨论开发的策略。
产品经理每天要开许多会,和各种人交流,目的是统一思想、快速做出决定、了解产品发布的挑战并加以解决。不同形式的会议侧重不一样,目的都是促进产品的高效开发。
站立会议让工程师们快速交流昨天完成的和今天要做的事,及时发现开发的问题并马上解决。
部门的产品经理会可以交流最新的信息,帮助产品经理从其他人身上学习经验并及时了解高层的想法。
优先级讨论会让大家讨论亟待开发的几个功能,砍掉优先级低的功能。到了开发末期,往往要面对各种挑战,需要权衡趋势,砍掉一些无关紧要的小功能,因此这样的会议经常进行。
思考题
最后,给你留一个思考题。你现在所处的团队处在产品的什么阶段?如果你是产品经理,你的日程表和我的相似吗?如果你不是产品经理,你的产品经理现在是怎么做的?
分享给需要的人,Ta购买本课程,你将得18元
生成海报并分享
赞 13
提建议
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
上一篇
04 | 产品经理和项目经理有什么区别?
下一篇
06 | 硅谷产品经理们都来自什么背景?
精选留言(41)
- 徐东鹏~种下一朵太阳...2018-05-01我是产品经理,身处创业公司。负责用户端产品、运营管理后台。同时身兼二代产品(智能硬件)的项目经理,并负责软件部分的产品规划与设计。 我认可不同的产品阶段,产品经理的工作内容不同。我负责的用户端产品是入职后交接给我的,产品体验很差,花了一周多的时间了解业务场景及功能逻辑、了解用户使用习惯及存在的问题,其中会和工程师、用户、老板、运营多方沟通,真正画原型、写文档的时间仅用了两天。 产品上线后非常成功,也明确了产品信息架构、培养了用户习惯,后续功能基本不会对这两点有大的改动。 二代产品(智能硬件),目前是初级阶段 需要每天跟进各板块团队的工作进展,了解存在的问题及解决方案, 每天和核心成员开会统一个板块进展及协调问题。软件产品部分 我刚明确了人机交互方案,目前在调研可附加的商业模式(涉及硬件元器件及系统底层设计)及梳理第一版产品功能清单。之后的软件产品设计部分基本雷同,不再赘述。 产品工作日程和作者差不多, 在9:30~10:00我会了解行业资讯; 下班后我会接听部分客服电话,了解用户反馈的问题。展开59
- 这个粗狂的土豆2018-05-01请问你懂技术吗
作者回复: 我是计算机和经济双学位哈
27 - Ada.Zhong2018-05-06讨论成功指标这点很有启发,这样让执行有一个迭代导向15
- 吕韬2018-08-01以老师的日程猜测,FB属于矩阵型人员架构,多个项目并行开发 多条产品线,开展不同的项目,每个项目自组团队,产品经理去游说,去拉工程师进组 由产品负责项目的需求发掘到项目落地,最好验证市场,好则继续,不好就拉倒 这套流程很完美 我们是小团队,一个产品一条线,人员架构比较固定,久而久之形成了稳定的周期。 在开发1.0的时候,设计已经在做2.0,产品在调研3.0的节奏。 所以产品的工作大概分为70%做需求,30%跟当前版本,循环迭代。 当前很多时候会遇到大大小小变更,然后开会衡量,随机应变。展开13
- 问剑2018-05-02不知道能否在产品经理自己每天的时间和精力规划上提供一些建议?很想知道资深产品经理是如何处理每天频繁的context switching的。
作者回复: 我觉得每天要知道重点是什么,早上开始上班的时候先记录好,今天要做的三件最重要的事是什么。因为很容易就会被工程师设计师的各种要求跑偏了,还没有把时间花在重要的地方。
10 - Raymond吕2019-12-26老师这个案例里产品经理开了挂,完全尽在掌握的状态:有明确的日程schdule,优先级,清晰的会议目标;关注眼前并着眼未来,业务、策略、人都涵盖了。 现实估计会比较残酷,国内跟国外的项目文化差异、资源情况都会导致产品经理动作变形,疲于奔命。 每天给自己列个带优先级的do to list,just do it!6
- Knight²º¹⁸2018-05-09我是开发,通设计师的设计并不能有效的实现,流程对接,需求管理,都是由产品经理在中间对接。所以常会遇到设计师和开发两边的接收的信息并不同步。由于现在都是微服务,用户看见的产品实际上是被打散到各个微服务系统,我们只是这个产品中的一环,产品经理对整个服务链路并不能完全熟悉,服务间存在一些跟用户需求不强相关的但不得不去面对的问题,因此一个产品的设计从初稿到定稿往往需要开花费相当多的时间,开发提出问题,产品经理需要在不同的服务开发团队,设计师团队间来回沟通确认。展开
作者回复: 我可能比较例外,但是我特别鼓励产品设计师和工程师自己交流,甚至可以绕开我。我觉得让他们自由交流,最有效率 如果需要我的时候,比如产品功能,或者他们发现的问题不知道如何权衡取舍 我可以随时出现
5 - 我只是胖的精致2018-05-03讨论产品的成功指标这点很赞同,以数据驱动业务4
- 发条2018-05-04有个问题,似乎曲姐您每个时段的任务都完成地很顺利,没有卡壳的时候,而据我观察,会议过程中偶尔出现一些没有进展的时刻,导致整个schedule都被打乱了。如果应对类似情况呢? Plus 听日程安排那段感觉安排得好紧凑,本想说一句SV machine!但是末了一说七点下班,心疼我自己:(展开
作者回复: 我觉得没有进展主要因为1。事先不知道你要开会解决啥。2。没有足够信息。这两个情况第一个是通过更好的准备。另一个 如果没有足够信息做决定 建议提前结束会议。下次再议
3 - Lee2018-05-01身处不大的公司,近期突然接了很多业务,且手上的产品线较多,几个维护几个新开发的,新增人员又没那么快到位,那样怎么去权衡工作优先级和合理管理安排时间。3
- 温小宝💗💞2018-06-08我是一名新产品,我们公司产品处于高速迭代的阶段,每个产品经理负责整个产品中的其中一个相对模块,每个模块的开发周期一般是两到三周。在开发的前期,产品经理的主要日程基本是用户调研或向市场部了解用户需求,之后几天的时间里都是产品自己整理用户需求并制作产品原型,这个时间一般是2-3天,之后会同领导、UI、技术讲解产品,这个一般需要半天时间,之后会有将近半天的改进时间。在交由技术开发阶段的日程,基本是配合技术测试,同时进行其他项目的设计。 相较于硅谷的产品经理,我们的日程显得非常宽松,会有大量的自己思考和创作的时间。但是,这样的缺点是,因为是一个人思考,如果因为对于某个问题理解不到位,之后会有大量的修改,极大降低了工作效率。但是不拿出原型的情况下,又没人愿意拿出时间跟你讨论,这是比较尴尬的。 我朋友是另一家公司的技术,因为产品人少,技术常常被产品拉着开半天的会,讨论的基本都是产品流程的合理性,每个产品本就可以有多个解决方案,大家看法不一,很难达成共识,却又无人敲板,导致会议时间延长。对于一名技术来讲,有必要花费大量时间参加此类会议么?展开2
- 想2018-05-02作为产品经理,公司是做安防行业,目前在研发产品共享中心,负责3条产品线的需求把控。因为需求都是从市场部门直接递交过来的,没有切实的用户调研,这是个痛点,同时产品没有量化的成功目标,不利于产品生命周期管理和迭代,总之在产品开发之初,需求明确很有问题。不知道该怎么办😱
作者回复: 你看看你能否争取和客户自己聊聊 看看能否直接了解客户需求。说服是市场部的同事
2 - 跑马堂2021-03-20我是个设计师,我不知道我们的产品经理每天在干什么,甚至连产品什么时候上线都不知道1
- 孤城寡事2018-05-20请问如何对需求进行选题
作者回复: 你是说怎么知道解决什么需求吗?一般一个具体需求涵盖在一个高层次的策略下,所以你的问题是说高层次策略如何确定 还是有了策略,如何选择进一步的需求
1 - linda.zx2018-05-09目前产品处于翻新版的阶段,目前主要的工作是总结老版的坑,调研行业趋势以及竞品分析~公司小,也没有什么市场部门和调研部门,一般就和高层、销售聊聊他们的想法,看看能不能碰撞出新的ideal~也会找开发聊一下技术的支持情况,让开发提前进行技术调研~1
- Geek_58fcf22022-03-24总结: 1.产品经理在不同阶段内容不不一样。解读初期、中期、后期。初期调研、策略形成产品功能,中期解决开发难题,和市场的人制定营销策略。 2.和各职能部门的人开会交流。目的统一思想,促销产品高效开发。获取信息,快速做出决定。
- Geek_4d836c2021-09-07这一段话 “一般会找到具体的工程师,到他们的办公桌前,问问他们有什么需要我帮忙的,现在有什么风险高的问题还没有解决。我发现,这样的形式比动辄开会要高效很多。所以,如果不是需要每个人坐在一起解决的问题或决定, 我一般都会采取这种方式快速解决。” 感同身受,开会往往会降低效率,我的开发同学就和我直接反应过这个问题,不愿意和我开会讨论需求,太浪费时间。 往往站在工位上,把相关的几个人叫过来,10 -15分钟或者更短的时间 就可以很高效的讲解完需求。展开
- Geek_matrix2021-03-14产品经理,产品和管理的双重结构洞
- w.k2021-01-26羡慕可以每天都可以与各部门头脑风暴的产品经理,现在好多产品都是负责全产品生命周期的杂活,什么都做且不精通。1
- 风信子2020-11-11只能做参考,工作内容在不同公司还是不一样的,而且作者是管理层,具体的功能是给设计师来做。 虽然工作流程和内容不一样,但是还是有很多相似的地方的。产品经理都要把握好用户的需求,不管是不是外包。 而且沟通,是在协作中非常重要的一件事,很多时候开发不会主动找你,有问题也会当做没问题。 所以主动的沟通,是解决问题,提前发现问题很重要的方式。展开