美文网首页
【PM】如何当好PM的PM?这里有一份产品经理进阶版实用手册

【PM】如何当好PM的PM?这里有一份产品经理进阶版实用手册

作者: 在这蓝色天空下 | 来源:发表于2020-03-02 16:32 被阅读0次

    转自:如何当好PM的PM?这里有一份产品经理进阶版实用手册

    Jack Krawczyk曾就职于StumbleUpon和Google,有着丰富的工作经验。2013年Krawczyk加入互联网电台服务公司Pandora,负责广告产品团队的管理。他的工作不仅是要推出听众认可的智能广告产品,还需要带领团队快速地成长。

    Krawczyk认为,领导一支产品管理团队首先做到以身作则。他在接手后立即投入到产品一线,参与到Pandora广告嵌入逻辑的重构。他说:“这个过程不仅让我更好地理解了产品如何运作,也让我真正认识到Pandora整个开发环节是怎样的。”

    Krawczyk曾见证过许多创意演变成为真实的产品,也遇到过不少难见天日的失败品。他的团队经常能拿出创意十足的解决方案,但也有不少项目以失败告终。在这些经验的基础上,Krawczyk总结出6条具体的策略,帮助产品主管开发优秀的产品并培养杰出的产品经理。

    1.了解团队的邓巴系数

    上世纪90年代,英国人类学家罗宾·邓巴提出一个理论:由于人类平均脑容量所导致的认知局限,一般人只能与150人维持稳定的社会关系。Krawczyk在管理中也运用这一理论,使每个人不需要处理与太多人的关系,确保同事之间交流的广泛而深入。

    Krawczyk说:“我认为每个好的产品经理本质上都是领导者,只是没人向你直接汇报。但是产品经理必须激励那些并不算自己下属的工程师,同时还要满足公司其它利益相关方的需求。”管理产品经理的人则必须成为领导的领导,并且深入理解公司内部业务关系架构。以下是负责一支快速成长的产品管理团队时需要注意的几个关键点:

    1.1 和工程师搞好关系,让他们不仅知道该做什么,还知道为什么要这样做

    Krawczyk说:“对于早期团队来说,工程师和产品经理数量的黄金比例通常是5:1。这个比例有利于产品经理和工程师保持足够亲密的关系,也让产品经理知道如何与工程师交流,如何激励他们,如何带来最大的产出。”

    随着团队扩大,职能会变得更加分散。这时,PM和工程师之间的数量比就没那么重要了,取而代之的是双方关系的紧密程度。工程师不仅需要知道工作是什么,还要理解每个产品功能背后的决策过程。对于一支交叉职能的团队来说,了解一项工作的前因后果非常重要。Krawczyk说:“如果产品经理能够清晰表达出需要做的工作及其原因,那么他们最终就有可能会开发出惊艳的产品。”

    1.2 小团队需要更紧密的联系

    Krawczyk建议,当一个产品团队在10人以下时,应该充分利用这种小规模的优势,尽可能让所有人聚在一起,开工作计划会议时可以邀请工程师和设计师也参与进来。在Pandora,这种方式不仅增进了同事之间的关系,也让产品经理在会后能对各方面情况有更加全面的了解。

    在Pandora早年,前CTO兼执行副总Tom Conrad为所有参与Pandora产品开发的员工建立了一套“美元决策体系”(dollar-decision-making system)。每次季度会议上,来自公司各部门的参会者将讨论Pandora最重要的产品和创新点。为了确保员工的参与度,并对工作的优先级进行排序,每个参会者都会收到5“美元”,用于投资他们认为最关键的领域。尽管钱很少,但这种形式却促使人们仔细权衡自己手中的筹码。

    对于很多团队不大的创业公司来说,这个方法都非常有效。尽管Pandora现在人数不断增多,但依然在使用这套“美元决策体系”,只不过是在各个产品团队内部,比如广告产品团队用“美元决策”的方式来制定产品发展的路线图。归根到底,还是要加强团队内部各个部门的充分交流和沟通,推动公司的不断成长。

    1.3 大团队需要重视流程

    Krawczyk说:“我遇到的最大挑战之一,就是如何保持Pandora早期形成的合作机制,同时又不断调整,适应不断成长起来的专业化团队。”在Pandora人数不到500时,我们可以把所有负责产品的人召集到一起开会。但现在,公司有超过1600名员工,包括25个产品经理和主管,如果还用老办法只会导致混乱,有些话题被重复讨论,有时候部分参会者与会议内容毫不相干。

    当你不得不为产品会议准备更大的会议室时,你就需要关注到决策流程了。
    2013年Krawczyk加入Pandora时,只有3名PM负责广告产品。短短两年,PM的数量已经增加到了12人,其中既有产品管理的新手,也有具备十几年经验的老将,和他们一起工作的工程师还有55位。这些人都在Krawczyk的管理之下。

    在产品经理数量接近两位数时,为了保持队伍的紧密联系和高效率,Krawczyk建立了一套“产品组经理”(group product manager)汇报制度,将12个产品经理分成3个功能组,覆盖到广告产品的各个方面:听众广告体验、广告分发技术、广告购买体验。每个组设置一名产品组经理,每组中有4名PM,每个产品都有专人负责。

    这个结构使得团队行动更快,每次开会的内容更有针对性,将来PM团队进一步扩大也不用担心。Krawczyk说:“如果有很多人向你直接汇报,那你就没法对某一项具体事务做到深入理解,交流效果也会大打折扣。而且在这种工作方式下,作为管理者的你总会为工作增加障碍。你工作本应是为大家消除障碍的,而不是增加它们。”

    2. 把所有工作落实到文字——然后进行分类

    Krawczyk说:“把想法组织成语言,再形成文字,然后根据文字进行讨论并不是一件容易坚持的事情。很多人认为把想法写下来是重复性的工作,即使写也是草草记录一下。这种观念实际上是错误的,团队的人越多,就越要做好文字工作。”

    Krawczyk之所以得出这样的结论,是因为有时候他发现在开完每周例会之后,产品经理、工程师、营销人员和执行团队看起来对会议所作决定的理解完全不同。在随后和员工的交流中他发现人们的观点确实存在偏差。如果每次开完会是这样的结果,那集中在一间屋子里开会还有什么意义?想要解决这个问题,团队管理者就必须经常与员工交流,确保他们对于手头工作的理解是统一、清晰的。

    在某次无果的会议之后,Krawczyk团队中一位产品经理想出一个办法:把相关信息提炼出来整理成一个分类文档。

    有一天,Krawczyk团队中的一位产品经理注意到,开会讨论时,一边是工程师拿着他们的产品需求文档(Product Requirement Document, PRD)在陈述观点,谈论的都是各种预测和用户故事;而另一边,营销团队则在解释他们自己的策划案。双方的信息是不对称的。为了弥合这种断层,这位PM决定把PRD中与营销有关的信息摘录出来,单独形成一份文档,保留原有形式,方便查找原文。通过这种方式,他给出了一份对双方来说都有用且比较熟悉的文档。

    Krawczyk发现了这一方法,于是就把它运用到了整个团队中。他说:“要想成为一名强大的产品主管,关键并不在于你自己能提出多少想法,而在于倾听团队的声音,发现最优的工作方式,并决定如何将其运用到整个团队中。”经过一段时间的发展,现在Krawczyk的团队主要利用4种类型的文档来保持团队中信息对称(按照从基础性到拓展性的顺序):

    • 执行总结(Executive Summary):关于产品团队在做什么的一份总结性、概括性的文档。是对产品的高度概述,让人们能够以最快速度了解产品。
    • Wiki页面(Wiki Pages):由各个产品部门编写,在内网流通,居于核心地位,是对每个具体领域的高度概括,包括工程进度以及要实现的里程碑。Wiki页面有每个分支部门的工作进度图以及按季度划分的时间线。
    • 产品需求文档(Product Requirements Documents):一份全面的产品规划文档,包括产品标准,产品特性,用户案例研究等。是一站式、细致的产品计划。
    • 发布计划文档(Lauch Plan Document):一份包括所有执行计划的综合性文档,用来协调产品、销售、营销和开发等各个团队之间的工作。这是两年多以前由于Pandora团队规模扩大而新增的文档。
    image.png
    • Pandora的Wiki页面模板

    在这4类文档中,Krawczyk特别强调了wiki页面对于团队的重要性。产品经理可以通过wiki页面说明自己的工作内容,设定季度目标,其它人也可以通过这些页面来了解产品的发展历程。那么,一个高效的wiki页面应该如何完成呢?以下是一些实用的原则:

    • 透明性和可见性。wiki这个词本身指的是“由用户群共同维护、允许所有用户添加或修改内容的网站或数据库”,基于这个特性,我们的wiki页面是由大家合作完成的,公司内所有人可见。在每季度和管理层进行的业务总结会议上,我们就可以通过wiki页面清晰地看到我们的团队做了哪些工作。
    • 简明的总结和清晰的表达。“每个wiki都链接到一份执行总结,让所有的参与者能够实时能保持信息对等。”此外,PM还需要简单说明他们正在做的工作,以及做这项工作的原因,在和领导、同事或者顾客交流的时候可以快速引用,非常有帮助。
    • 季度目标的设定。“我们不会具体到这个季度要做的每件事。因为在公司快速发展过程中随时会有变化,比如某个季度可能新招来二三十位新成员。因此,我会建议产品经理逐步把这一季度中所有的测试、项目里程碑或者新产品上线写出来。当然,产品开发周期常常超过3个月,通过wiki的方式可以促使PM把大项目切分成小的版块和阶段。”
    • 明确定义下一步要做什么以及不做什么。“在每组的wiki上,会有产品发展规划,列出了即将开发和发布的所有产品功能。同时我们也要求写出不准备开发什么。这样可以在将来避免模棱两可,导致开发出一些本不想开发的功能。”

    如果说文档对于产品经理可以用“关键”来形容,那么对于产品经理的领导来说,文档就是“不可或缺”的。

    Krawczyk把自己看做整个产品团队的产品经理,这个团队就是他在开发的产品。“不论是说明公司的价值主张(value proposition)还是我对产品的修改意见,我都需要向团队解释我的理由,让PM理解决策过程非常重要,这样,他们才能在充分了解各方面信息后完成艰难的工作。因此,这些文档对我非常有用。”

    3. 做好团队沟通的组织者

    作为产品经理,你需要清楚别人是否真正理解了你们所达成一致的内容。你不仅要让大家完全理解该做什么,还要让他们知道所做的事情与最终目标有着怎样的关系。

    当Krawczyk和一位产品经理意见不一时,他会先质疑是不是自己的理解出了问题。他说:“我发现很多时候我不同意某个方案是因为我对于问题本身的理解不够清楚。这时,我会向PM坦言我可能理解不到位。但是如果我认为我没有错,是PM提的方案不合适,那我会进一步分析,消除PM对于我所做决定的疑虑,最终达成一致。整个讨论的注意力都是放在问题本身,而不针对这个人。”

    然而,如果团队还是不理解你,那就是你的错了。你是团队交流过程的组织者,你需要确保大家在某些问题上达成一致的,也可以选择一些问题让大家各自保留意见。

    寻求最适合团队沟通的方式,确保每个人都能理解关键信息。

    “人们在提产品需求时常常只说‘我要你做这个。’实际上,接下来非常重要的一步就是说明为什么要首先做这些。”

    几个月以前有一次,Krawczyk在一个部门的wiki页面提出了一些新的要求,但是这个部门的产品经理看起来很困惑。于是他又进一步做出了解释,说明了之所以提出这些要求的完整背景。他说:“说明做出某个规定的原因比反复强调新规定的内容要容易得多,在大家充分理解之后,我们就能行动得更快。”

    4. 把团队管理当做你最重要的产品

    产品经理如果工作做得比较好可能会被提拔去领导一个产品经理团队,这时他会发现,虽然自己善于做管理单个产品开发,对于创造新事物也非常有热情,但是现在自己的大部分时间却花在了管人上,与实际产品的接触越来越少。Krawczyk就曾经历过这样的阶段,也知道如何应对这样的挑战。

    Krawczyk说:“我喜欢做产品的整个过程:跟团队核心成员一起,讨论出一个想法,招人加入团队,在挫折中不断学习,最终从不断的失败中走出来,取得成功。但作为整个团队的产品经理,我的工作就是帮助PM理清思路,深入分析产品,最终把想法变成现实。产品经理就是我的产品,因此产品经理所能使用的方法对我同样适用,只需要根据情况做一些微调。”

    想要成为一名好的产品团队管理者,你需要首先成为成功的产品经理。
    那么,究竟该如何培养最优秀的产品经理呢?Krawczyk提供了6种适合管理团队的方法:

    4.1 设立良好的倾听机制

    “很多产品经理只相信自己内心的声音,但最好的产品经理大多数时间是在倾听别人的想法。我在开会时一般都尽量少说话,只是提一些问题让人们表达自己的想法。这个过程就好像产品经理看着自己的产品成型、为人们所使用最终取得成功一样,非常美妙。”

    策略:首先问产品经理一些顾客在第一次使用时可能会问的开放性问题。产品团队应该对这些问题有所准备,并在产品发布之前想好应对方案。

    鼓励你的产品经理去接触真实的消费者,倾听他们的意见,在提问的时候可以不提及Pandora,比如问:“迄今为止,你遇到的最让你兴奋的产品是什么?你喜欢哪些品牌?它们有哪些让你感觉做得非常棒?”

    4.2 不惜一切代价保持反馈渠道的健康畅通

    Krawczyk每周会和部分员工进行一对一的交流,整个团队每周还有两次例会,一次在周一,主要讨论产品问题,另一次在周三,讨论管理问题。这些会议不仅给团队更多机会来表达自己的关切,也让离开产品一线的Krawczyk在各种报表文件之外有了进一步了解情况的渠道。

    Krawczyk说:“周一早上9点半是一周最重要的时间,因为整个团队的25个产品主管和经理会聚在一起开论本周的工作。我们会先看一下wiki页面,了解各团队进展,然后再深度研究产品的开发情况,包括产品更新等各个方面。在周一例会上,我一般会简要记下准备跟进哪个产品经理的工作,随后跟他的产品组经理沟通或者是直接通过Slack跟他们交流。”

    每周三上午,Krawczyk还会和团队开个30分钟的短会。“这次会议主要是用来讨论管理上的细节,包括员工的休假以及新政策的宣布等。我刚来的时候一般不会专门开会讨论这些问题,或者就排到议程的最后,我觉得给所有PM发一封email就解决了。但实际上这些问题也非常重要,应该面对面地进行交流,即使时间很短。

    策略:为团队会议和一对一交流安排固定时间,最好是在每周伊始,这样有助于明确本周的工作,保持所有人在同一个节奏上。安排好会议的顺序,使之相互促进,比如先开一个会收集信息,随后再开另一个会处理收集到的信息。可以设定不同级别的会议,以便参会者选择最合适、最相关的场合来提出议题。

    4.3 团队管理的目标应与产品的目标相一致

    Krawczyk说:“我要求每一位产品经理都能够明确地说出产品开发的宗旨和最高目标,帮助产品经理更加深刻地理解自己的产品。这里的目标并不一定是收入目标,因为对有些人来说,激励他们做事的动力并不一定是金钱。”

    Krawczyk也发现,不同的人在做事时追求的目标也是不尽相同的。他十分认同Daniel Pink在《驱动力》(Drive)一书中关于工作驱动力的总结,即人的驱动力可以分成三类:

    • 自主型——自我驱动是人的天生动力。那些靠自主驱动的人十分希望得到信任,不喜欢被别人盯着管教。
    • 专精型——主动提升专业能力和职业水平(而不是随工作逐步提高)是关键。这部分人经常会问:“做这份工作如何让我变得更好?”
    • 目的型——找到共同的使命或目标最关键。这部分人由做事的目的驱动,他们经常会问:“为什么我在做这件事情?”

    Krawczyk把这套理论运用到了整个Pandora团队,他说:“我的同事中有些人特别热衷于解决复杂的数学问题,而另一些人天生就是做用户界面设计的。”Krawczyk要做的就是帮助团队学习如何更好地理解同事属于哪种类型,并利用这种信息让大家按照最适合的方式工作。

    策略:在开发产品时做用户和市场调研是很正常的。而在管理团队的过程中,也需要对团队成员进行调研,了解如何激励他们,如何使他们的个人目标和团队的使命结合起来。

    4.4 提供适当的资源

    每个产品开发团队都有时间和资源上的限制。如何分配有限的资源是一门大学问。以下是Krawczyk在这个方面给出的两个有效的策略:

    (1)紧跟现实情况。在从无到有开发产品的过程中,人们很容易做出错误的假设,然后开始“放卫星”做一些不切实际的功能。当然,一个好的产品主管会尽可能地促使产品经理提出更多好创意。但如果不给资源就异想天开是很容易让人泄气的。

    “如果PM没有足够的工程师做某个项目,你肯定不会把工作交给他的。”所以,一定要确保你提出的想法紧跟现实情况的。如果一些条件暂时还不具备但将来有可能实现,那么你要做的就是先好好规划一下。

    (2)给PM留够思考的时间。“有时候产品经理需要花上两三个季度的时间去深入思考一款产品,形成对重要数据的敏感度,然后深入研究这些数据,最终做到从噪音中发现信号。”

    4.5 团队快速发展过程中管理的变与不变

    随着公司规模的扩大,产品管理职能会发生显著变化。团队可能重组,人员发生变动,员工的职责也会有所调整。Krawczyk在Pandora、StumbleUpon和Google的几段工作经历中都注意到了这样的变化。为了快速地适应变化,他提出了两条策略:

    (1) 以产品为基础管理产品。在现在,一个年轻的创业公司有3个产品经理并不稀奇。其中一个可能向CEO汇报而另外两个则向曾当过公司产品经理的一位创始人汇报。这种结构的混乱可能会导致一个产品经理管得很多,但却没法覆盖到任何一个完整的产品,最终导致产品开发的不规律,因此在管理中需要以产品为基础。

    (2)对产品保持深入的理解。开发出一款产品时,需要对于产品有着深入的理解,但要做到这一点需要花费不少时间。每次开发出新功能以后,我们要求产品经理不仅展示新功能的数据,还要求他们说明新产品将如何影响到人们使用Pandora的方式。Krawczyk说:“让PM感到产品属于他们非常重要,但同时要让他们形成一种责任感,并且对于产品有着深刻的理解,这种理解将会对产品产生重大的影响。”

    4.6 经常公开地表扬和赞美团队的优秀工作

    建立渠道让团队分享成功的喜悦和失败的经验非常重要,对此Krawczyk给出了两条建议:

    (1)知道荣誉归属于谁。如果Krawczyk的团队发布了一项非常棒的功能帮助Pandora登上了行业顶级期刊的封面,他就会去了解这是哪个团队的成果,团队的产品经理、工程师、设计、业务都是谁。此外,如果要发外宣稿介绍新功能,Krawczyk也不会代笔抢占荣光,而是会交给产品经理,他才是产品的主人,也应该是产品故事的讲述者。

    (2)所有的项目都要做总结,然后在内部进行分享。项目结束后的总结不需要很长,也不要都是歌功颂德的话语。Krawczyk和他的团队所做的总结通常都很简明扼要,也不是特别正式。每次新产品发布或功能更新后,他们都会在他们的内部wiki页面上写一句话,清晰地概括核心要点,然后在后续补充更多细节,把产品发展过程中学到的东西记录在这个wiki页面上,为将来的产品开发做好记录。

    5. 永远要培养新领导者

    在谈到团队时,Krawczyk说:“我不喜欢说‘我的团队’,听起来就很老套,我会称之为我们的团队。我认为通过这种方式我可以更好地理解每个产品经理在做什么,以及我该如何把大家凝聚起来。”

    Krawczyk会积极地发现团队中优秀的人才,有意把一些员工往经理的方向培养,这种培养有时候甚至在新员工入职之前就开始了。

    (1)候选人面试的时候就要明确他的使命和目标。在Krawczyk看来,面试环节最值得讨论的就是公司的使命,因为这不仅展现了候选人对于公司是否足够兴奋,也能看出他们是否理解公司的使命以及他是否愿意为之付出。

    “我希望每个加入团队工作的产品经理都能够从一开始就对自己所做的工作感到兴奋。好的应聘者会在入职前就去接触他们即将从事的工作。而最优秀的人才已经着手了解消费者想法了。如果你做了这些准备工作,说明你已经理解了公司的发展目标,并且非常渴望学习如何为了这个目标而努力。”

    (2)聘用那些充满好奇心的倾听者。在Pandora,申请广告产品部门的应聘者会首先由Krawczyk进行电话、视频或者现场面试。他喜欢问:“你最近一次自学学的是什么?”这个问题可以深入了解应聘者心中对于挑战自己是怎么看的。

    如果这一轮聊得比较融洽,候选人就会进入后两轮面试,一轮是来自几位产品经理的面试,包括所申请部门的产品经理;另一轮来自其它部门的产品经理、营销人员和工程师。在面试环节的最后,Krawczyk会让候选人回答他们对于这份工作的看法,然后看看与岗位需要是否契合。

    (3)请优秀的PM来培训新员工入职。“随着团队的扩大,要给产品经理带新人的机会。这是培养产品经理晋升为主管或者产品组经理的好机会,也有利于新人在实际环境中快速了解日常工作。如果有些PM就只想做好自己的本职工作,那也不要强求。

    6. 不断从新的角度重新回顾你的使命

    Pandora的使命是帮助数亿用户轻松愉快地寻找音乐。Krawczyk反复向团队强调着这个目标。在产品开发中遇到艰难的决定时,他总会想:“新产品如何增加收听时间?新功能会引起人们的共鸣吗,还是会打扰他们?”

    Krawczyk每天都会回顾公司的使命,他电脑的屏保也在不断循环着他的目标,看起来就像是战斗口号:“发现音乐的无穷能量,让品牌引起听众的共鸣!”

    作为整个团队的产品经理,以下是2条保持公司使命处于核心地位的方法:
    (1)用数据来验证产品开发是否与公司使命一致。在产品开发过程中,有时很难把某个特定的功能和公司总目标对应起来。Krawczyk说:“在广告随处可见的今天,我们的核心目标是让用户通过广告与品牌建立起联系。但如何做到这一点?我们会通过一系列具体的指标和参数来进行验证,判断产品的关注点是否偏离了公司的总目标,接下来我们会调整产品直到得出正确的数据。”

    (2)团队使命应该是可拓展的;有时候需要跳出来寻找灵感。想要成为电台领域的佼佼者,可以从其它行业寻找灵感。Krawczyk举了一个例子:很多人都听说过米其林星级餐厅,但却没有意识到一个轮胎厂商为什么要给餐厅评级。实际上米其林餐饮指导手册是在100多年前开始编制的,这个评级的初衷是鼓励人们多出去吃饭,外出吃饭会增加汽车的使用频率,进而增加轮胎的消费。所以说,最好的广告可能根本就不是以广告的形式出现的。”

    做广告产品很像是中央情报局(CIA):当你工作做得好时,没有人会注意;可是一旦你搞砸,全天下就都知道了。

    相关文章

      网友评论

          本文标题:【PM】如何当好PM的PM?这里有一份产品经理进阶版实用手册

          本文链接:https://www.haomeiwen.com/subject/fqevkhtx.html