|
|
# 05 | 硅谷产品经理每天在做什么？
|
|
|
|
|
|
**前面的文章我讲了产品经理的工作性质和内容，但是还有一个非常重要的话题，就是：产品经理的一天是什么样子的。**
|
|
|
|
|
|
有人说产品经理每天就是和工程师互撕，也有人说产品经理每天各种开会，还有人说产品经理每天就是坐在电脑前画画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日发布。
|
|
|
|
|
|
## 总结
|
|
|
|
|
|
通过上面的这个真实案例，你应该可以发现以下几点。
|
|
|
|
|
|
1. 产品经理的工作内容取决于产品发布的阶段。
|
|
|
|
|
|
> 开发初期，产品经理需要花更多的时间在思考上。这个阶段主要弄清楚要做什么， 所以需要花大量时间做调研、策略以及制定产品功能需求。这时和工程师交流的时间比较少，更多的是和调研、市场的同事们一起。
|
|
|
> 开发最紧张的阶段， 产品经理需要花更多时间在执行上。这个阶段需要花大量时间解决开发难点，根据困难和挑战修改之前提出的方案，并且和营销部门讨论开发的策略。
|
|
|
|
|
|
2. 产品经理每天要开许多会，和各种人交流，目的是统一思想、快速做出决定、了解产品发布的挑战并加以解决。不同形式的会议侧重不一样，目的都是促进产品的高效开发。
|
|
|
|
|
|
> 站立会议让工程师们快速交流昨天完成的和今天要做的事，及时发现开发的问题并马上解决。
|
|
|
> 部门的产品经理会可以交流最新的信息，帮助产品经理从其他人身上学习经验并及时了解高层的想法。
|
|
|
> 优先级讨论会让大家讨论亟待开发的几个功能，砍掉优先级低的功能。到了开发末期，往往要面对各种挑战，需要权衡趋势，砍掉一些无关紧要的小功能，因此这样的会议经常进行。
|
|
|
|
|
|
## 思考题
|
|
|
|
|
|
最后，给你留一个思考题。你现在所处的团队处在产品的什么阶段？如果你是产品经理，你的日程表和我的相似吗？如果你不是产品经理，你的产品经理现在是怎么做的？
|
|
|
|