首页 > 业界 > 向平台转变的产品管理
2016
04-18

向平台转变的产品管理

  很多创业公司都从某个优秀产品开始——在市场上取得成绩之后,却倒在了过渡到平台的路上。本文探讨很少被人提及的、向平台过渡所需的产品管理哲学。「平台」使得各种产品相互分享数据和体验。举个例子,从庞大的代码库,迁移到一套通用的 API 或服务,常见于 web 服务或操作系统中。在我职业生涯中,我曾在三家这样的公司做过产品主管,这三家相对成功一些。事实上,平台的产品管理需要一组技能,它不同于面向客户的产品管理角色所需的技能,而是需要不一样的面试流程和职业道路。我真希望在 10 年前,我就能详细筹划出平台产品管理所需的变化。

  很多创业公司有着共同经历,从单一的客户产品,转型为共享已有组件的多种产品。还有另一种经历,核心产品的成功,促使需要扩展潜在技术和面向客户产品之间的、一定程度的抽象,但是很少有文章提及驱动产品管理组织转变的文章。

  对于那些想扩大增长、或开发新产品线的技术公司而言,问题不在于他们「是否」要开发一个技术平台,而是「什么时候」开发,这是因为规模经济使然。

  当你决定过渡到平台时,需要在面向客户的产品经理(SAAS 公司称之为「解决方案产品经理」)和平台产品经理之间,划定清晰的界线。

向平台转变的产品管理 - 同创卓越 - 1

基于一套共享组件、开发的支持多产品的产品组织的例子

  平台产品经理的职责是组件、或一套组件工作的优先级,面向客户的产品、以及潜在的终端用户都会用到组件。下面列出了一些平台产品管理的必备特征。记住,重要的是掌握全面的产品管理技能,否则,平台的产品经理(PM)就不会成功。

  1. 平台 PM 理解宏伟蓝图

  平台 PM 负责创建功能,它用来拓宽多个产品线。这些 PM 需要需要充分理解大的战略愿景,才能在不同产品之间做出短期和长期权衡。PM 有时候不得不做出有损产品线短期收益的、不得人心的决定,但从长期看,它促使所有产品变得更好。

  2. 平台 PM 高效地管理着各种利益相关人

  平台 PM 服务的对象有三种不同用户。一个是终端用户——或客户,他们在使用着你开发的服务。你需要理解影响客户体验的相关权衡。其次,就是各种 GM 或解决方案产品经理,他们尽量让其特定产品线达到某个目标,因此需要团队支持。最后就是开发人员了,他们基于你的服务做开发,也会提出一套需求,包括他们喜欢的框架和工具。关于这三种用户群,有篇文章写得很好。

平台 PM 要想成功,除了必须理解他们的客户,还要理解客户的客户。如果他们失败了,多半是因为他们只考虑了开发人员。

  3. 他们制定简明的长期路线图

  我坚决支持面向客户路线图的清晰,当满足客户需求时,团队才能快速响应。然而,有了平台产品路线图,就需要从长期视角审视,这比较重要,因为你需要为不同的利益相关人设置期望。这些路线图也需要更加详细的简明方式,因此你们开发的技术才能可扩展、可依赖、以及可维护。平台 PM 必须回答一个问题,「如果流量增长到 100 倍,目前的技术该怎么应付?」

  4. 项目管理技能是加分项

  除了平台 PM,你还需要项目经理,我不是这个意思。但是,优秀的项目管理执行技能有助于平台团队的成功,比如依赖管理、团队障碍清除、以及过程健康。具备了更长期的路线图、复杂的依赖管理、以及更加多样化的利益相关人,项目管理技能对于团队就弥足珍贵了。

  5. 技术背景的帮助

  在某些大型产品组织里,我们把平台产品经理又称作技术产品经理(TPM)。在 Amazon 或微软,他们有时候称之为 Program Manager 注1。很多平台 PM 以前都是工程师,这是有道理的,因为这个角色对内要面向工程师团队,对外要面向客户。人们常常问,「只有做过工程师的产品经理才能成功吗?」我答,这取决于哪种产品经理。通常来说,不是这样的,他们不必做过工程师,我曾见过没有工程师背景的、世界级的 PM。然而,和客户产品管理相比,在平台产品管理上有技术背景是有帮助的,因为你要解决的很多问题都是传统的计算机科学问题,比如扩展性、可维护性和架构设计。何况你的技术平台上的核心客户之一都是其他开发人员了,因此有技术总归是好事。

  6. 痴迷于准确、简明的交流

  拿「平台即服务」的公司来说,比如 Stripe,开发人员喜欢它们的其中一个特点——优雅而简单的 API。平台 PM 需要打磨服务的交流方式,便于用户轻松集成。


  当产品组织渐趋成熟、具有平台思维时,对外(客户或解决方案)和对内(平台)的产品经理就变得有必要了。对外,「解决方案」产品经理要提高用户基数、财务标准和使用。同时,此时的平台 PM 热衷于让其他人成功,当其他人完成目标时,他们则扮演着散发巨大热情的「幕后人」。平台 PM 常常是参与者,热衷于和团队打成一片;而面向客户解决方案的 PM 有一半时间不在公司,而是和客户们在一起。

  当过渡到平台(每个人都想成长为平台!)时,请注意下面列出的平台产品管理所面临的一些常见陷阱。

  1. 象牙塔、而非以客户为中心的思维

  当我转向平台情景时,我注意到一个变化,工程师团队考虑的是产品开发、不再以客户为中心。在开发平台之前,大部分产品团队完全是跨职能的。在跨职能的情况下,我们的工程师和产品经理、设计师一道,花时间和客户交谈。一旦我们切换到了平台模式,工程师团队就拥有了 API,我们整个团队都致力于计算机科学方面的问题,就不再和客户交谈了,甚至长达几个月。最糟糕时,我们的开发团队对解决方案的架构做了过度设计,客户反而不需要。站在客户角度考虑,是平台 PM 需要努力去做的。平台团队过于信奉:如果他们给内部利益相关人、或其它开发人员提供价值了,就足够好。但是,只有把客户需求、利益相关人需求和开发者需求结合起来,才能做出伟大的平台。从这个意义上说,客户的声音对于平台 PM 才是至关重要的。

  2. 产品组织需要很强的架构领导才能与合作能力

  意欲成为平台是好事,拥有架构方面的领导才能、并付诸实施却非常困难。我不打算展开讨论优秀软件架构的定义了,但是,如果你的组织制定了一些务实的、经过思考的架构,就可以让 PM、软件开发人员避开复杂,开展对话,这是必要的,因为他们真地理解什么才是可能的。架构团队在帮助 PM 做决定时,必须对整个系统的全局视角牢记于心。优秀的平台 PM 明白,要早些着手于架构,要常常研究新的开发。

  3. 过早地投入平台

  开发新产品,会因为不明确而感到忧虑,需要快速响应客户、调整、规划原型、hack,只要能找到适应市场的产品,做什么都可以。在产品没做好之前,还不适合开发平台。我建议,在投入基础平台之前,要给产品时间,以找到可持续的增长。当另一个 PM 还在尽量寻找适合市场的产品时,就同时开发平台,将减缓面向客户产品的进度,降低成功概率,并让所有同事感到沮丧。


  世界上有成千上万家公司,均成功发布了一款产品,但是未能过渡到平台、也未能有成功的二次动作。网上有很多优秀资源,做了细致探讨。采用 MVP 注2 或原型,开发出耀眼新产品和功能,让想法一飞冲天,但是很少能过度到可扩展的基础架构,而后者是用来系统化地启动新产品、以及增长业务的。只有理解了平台产品管理将会怎样改变你的产品组织和公司,才能理解基业长青的公司和跳梁小丑之间的差别。


  译文: 《向平台转变的产品管理 》 腊八粥

  注释

  1.  一个 Program Manager 需要项目管理的技巧,Program Manager 也需要负责功能需求、Program Manager 还要写功能规范说明书、Program Manager 还要负责设计原型。Program Manager 要有三大硬功夫:Technical Proficiency,Project Management 和 Design Sensibility,而且还要有内功,拥有非凡的 Communication 能力和 Leadership。http://www.360doc.com/content/06/0702/19/9564_147415.shtml 
  2. 最小可行产品(Minimum Viable Product):维基百科解释:http://en.wikipedia.org/wiki/Minimum_viable_product 
 
最后编辑:
作者:同创卓越
这个作者貌似有点懒,什么都没有留下。

留下一个回复

你的email不会被公开。