作者:Tina Ruan
全文共 4316 字,阅读需要 10 分钟
———— / BEGIN / ————
因为我在哈佛商学院教一门关于产品管理的课程,经常有人问我 :“PM的角色到底是什么?”
PM常常被称为“产品的CEO”。我不同意这个说法,因为正如Martin Eriksson指出的:
PM无权控制大部分可让他们产品获得成功的事情——从用户、数据调查,到设计、研发,到市场销售和产品支持。
PM不是产品的CEO,在不同因素下,他们的角色千差万别。所以,如果你在考虑PM的角色,你应该考虑哪些方面?
有志向的PM,在衡量角色时,应该考虑三个主要因素:核心竞争力,情商(EQ)和人与公司契合度。
我合作过的,最优秀的PM拥有核心竞争力,高EQ和适合他们的公司。除了定期开发新功能和保持研发与设计小组和睦关系外,最优秀的PM创造的产品,能被用户高度接纳,从而带来收入的指数级增长,甚至颠覆一个行业。
一、核心竞争力
PM必须有的核心技能 —— 许多技能可通过理论学习获得,但大多数技能会随着经验、好榜样和指导而提升。
下面是一些例子:
消费者采访和用户测试
运行设计冲刺
功能优先级和计划road map
资源分配的艺术(不是科学)
进行市场评估
把商业需求转译成技术需求,然后再反过来
定价和收入模型
定义和跟进成功标准
这些核心技能是所有PM的能力底线,最好的PM通过多年定义、传输、迭代产品,磨练了这些技能。这些PM善于反思,哪些技能造成了产品的成功或失败,并不断地通过用户反馈调整他们的方法。
二、情商
一个好的PM知道采访用户时,该做的与不该做的,但是最好的PM有能力与用户共情,懂得他们的身体语言和情绪,并立刻弄清楚产品或功能可以解决的痛点。
一个有高EQ的PM,与ta的组织关系亲密,并且有敏锐的直觉,知道如何克服内外部的困难,推出优质产品。
下面看一下Daniel Goleman定义的EQ的四条特质,是如何影响PM的。
1. 关系处理
关系处理可能是PM能力中最重要的一项。
优秀的PM,通过与内、外相关人员建立互信关系,来激励他们,帮助他们发挥最大潜能。
在成功谈判,解决冲突和达成共同目标的过程中,关系处理都至关重要——尤其在达成共同目标的程中,PM要平衡客户需求,资源受限的工程师队伍和公司目标收入,使得关系处理非常具有挑战性。
组织中真实信任的关系,在项目需要额外资金支持时,或工程师需要在下一次迭代中快速修复bug时,非常有帮助。
组织外,这些能力可以让顾客参与beta测试,获得早期反馈,或在未公开阶段,说服目标客户试用MVP(最小可行产品)。这些关系技巧,也会让因为bug而愤怒的客户变成 “没关系,我知道你们会修复bug的” 的天使客户。
2. 自我感知
PM必须通过自我感知来保持客观,避免把自己的偏好投射到用户身上。
如果一个PM因为一个功能可以解决自己的痛点,而喜欢这个功能——这类PM通常是他们负责的产品的重度用户——PM可能会让用户说出他们喜欢这个功能,仅为了取悦PM(“假正向功能验证”)。
如果没有自我感知,当用户访问和证据都反对某功能时,PM仍会将此功能优先排序。缺乏自我感知会打乱其他优先功能,破坏PM与工程师的关系,因为功能不被用户接受,而让工程师丧失对PM的信心。
3. 社会意识
如Goleman所说,职业能力加社会意识就是同理心,是组织意识和服务意识。
PM必须像懂得销售关心如何销售产品,又或是技术支持如何支持产品,又或是开发团队如何开发产品一样,懂得用户对产品的情感和关心。
PM必须有对组织运转有深刻了解,并且必须建立社会资本让产品成功,从获得预算与人手到确保高级工程师努力开发产品。
最后,社会意识确保最好的PM服务于用户,建立解决用户问题的产品,最终确保产品与市场契合。
三、人与公司契合度
如果最好的PM拥有良好的核心竞争力,高EQ,是否意味着他们在哪里工作都注定成功呢?
并不尽然。
事实上,怀揣着这些技能和人格特质,并把它们应用在对的公司才会最终确保成功。
我还未见到过一个真正标准化的PM职责描述,因为这个角色是由公司的大小、产品类型、平台、行业,甚至是企业文化决定的。如果你拥有了核心竞争力和高EQ,需要获得成功,下一步就是就是搞清楚谁在雇用你,他们真正需要什么。
这里有些关键区,根据各家公司对PM的要求而不同:
1. 技术要求
产品类型,使用对象,和公司类型决定了PM是否需要懂技术。例如,Google要求PM必须通过技术测试,不管他们负责什么产品。如果公司在做SaaS CRM,就会要求有关于市场和用户生命周期的经验要求。
反过来,如果一个数据科学产品,包括机器学习算法和APIs,要求PM有深厚的技术,不只能理解如何搭建产品,还能在与使用客户谈话的时候有信服力。
也就是说:了解基本技术原理并掌握PM常用工具,对PM至关重要,无论在那个公司。
Colin Lernell 关于必懂的技术有更多要讨论的。如果你是个有抱负的PM,并且担心缺乏基本技术知识,也许你可以考虑参加在线课程,如哈佛大学出的有名的《计算机科学入门》(CS50)课程,或其他由Flatiron School提供的许多入门和高级技术课程。
2. 公司关于PM的理念
每个公司都对产品开发过程和PM在该过程的切入点有不同的理解。以下只最普遍的类型,包括类型的优缺点。
(1)产品驱动研发
这是一个“各管一摊”的方法,此方法中PM收集需求,编写需求文档,然后交给研发,规范技术需求。
现在的组织可能会用一种更敏捷协作的方法进行这个流程,但需要PM非常了解用户需求和技术可实现性。
(2)研发驱动产品
更多面向技术的产品公司(如云,大数据,网络)都是有研发驱动,公司里的工程师都是在其领域最前沿的人,PM验证解决方案或者建立前端接口(UIs,APIs)来接入最新科技。
这种情况,会出现客户、PM和研发之间的合作关系与反馈循环。
通常PM在这些公司里服务于研发。
(3)PM-工程师合作关系
在这种情况,PM和工程师有很强的阴阳关系,共同发现、做决策、分担责任。
工程师参与PM的用户调查,PM参与冲刺会议,帮助拆解任务,明确需求。但是两个角色知道在哪里止步,不相互干涉。
PM理解编程内容,但是不会告诉工程师如何编程,工程师有用户需求的同理心,但会把优先级排序留给PM。
我很明显地偏向第三种理念,因为我体验过这三种理念,并发现阴阳体系是最有效率的。
但是并不是说另两种不好—— 这真的取决于在做的产品,公司阶段和其他因素。
3. 公司阶段
PM的角色在创始公司更像是万能角色,而在成熟公司,PM角色被划分的更细(Banfield,Eriksson,和Walkingshaw在《产品领导力》一书中,有一章节详细介绍了此问题)。
(1)创始公司
除了发现、定义和推出产品,PM也许还会负责定价,支持,甚至销售产品。这些PM成长在不连贯的环境中,习惯于公司在努力进行市场匹配的时候,创造的矛盾又频繁的产品方向变动。
(2)成熟公司
PM可能会有狭窄的眼界,有同时帮忙解决定价,入市策略,等等。而且他们属于PM大团队的一部分。
(3)创立者/CTO/CEO 与PM的关系
尤其是公司早期,知道如何让创立者/CTO/CEO参与到项目进程中非常重要。如果他们参与过甚,PM更多会扮演支持角色,帮助他们实现他们的想法或验证用户概念,并与实现PM自己的想法产生冲突。
对一些PM来说,这会非常有趣,与创始人和C级别的执行官们合作,创造产品。
但是对另一些PM,这会让他们非常沮丧。如果他们喜欢自己控制产品方向。这也会非常有挑战性,如果一个更加技术性的创始人或C级执行喜欢直接与工程师合作;这样会让PM被留在圈外,没有威信(有时是无意的),不但造成个人的挫败感,而且会延迟进度。
当考虑一个PM角色可能与创始团队密切合作时,确保了解他们对PM功能的期望,再决定这么做是否符合自己的利益。
当然,对于任何角色,都有很多需要考虑的因素,比如产品类型(B2B,B2C,工业类),与你合作的同事,总体企业文化(多元化,包容心,弹性工作时间,远程合作)当然也包括工资和福利。还有很多关于招聘PM的文章,通过它们可以看出招聘经理想要什么—— 我特别推荐我的朋友 Ken Norton的一篇文章 “如何招聘PM”。
但是,如果你想努力成为伟大的PM,你需要签下一个工作前考虑我上面所说的。发展核心技能是需要贯穿你生涯始终的,而利用EQ可以保证你有正向的经理。但你在哪里工作,他们如何工作,你和谁工作,与谁工作会最终决定你长期的成功。
———— / END / ————
原文地址:https://hbr.org/2017/12/what-it-takes-to-become-a-great-product-manager
原文作者:Julia Austin
译者:Tina Ruan
本文由 @Tina Ruan 翻译发布于人人都是产品经理。未经许可,禁止转载