技术产品经理建议

这篇文章是翻译稿,不是David原创,原文在这里:Technical Product Manager Tips 作者:Scott Sehlhorst
小D非专业翻译人员,译文中语句不通,表述不清之处都是小D的过失,与原文无关。
如有转载,请注明原作者和出处。谢谢。

翻译这篇文章是有感于资深技术人员在转型当产品经理或者项目经理时,需要转变的一些思维方式。

———————————

你是一个有技术背景的产品经理吗?你是否经常发现自己被强迫拉进这些战术角色:像提供演示或者在设计方法上提供反馈意见?你是否被隔离在关于价值、目标和“商业驱动”的战略讨论之外?或者你的行动敏捷果断并且在从业务到开发的转换上表现才华横溢的功绩(并且在从开发到商业的转换上也一样呢)?

往下读,这里有一些建议关于应该避免什么和如何有效的平衡你的技术

一个真正的关注

回到2008年2月份,在几天的课程中,我和一位读者(也是一个评论者 –再次感谢)有一次很好的交流,讨论作为一个有深厚的技术技能的产品经理面临的一些挑战。在后来的3月份,硅谷产品组(译者注:Silicon Valley Product Group–SVPG)在他们的邮件列表(和他们的博客上)包括了一个专题:从工程技术转为产品管理。那篇文章的作者提供了一些很棒的建议,针对“技术怪才-转型的-产品经理”的沟通活力。今天,我们将这些想法聚在一起,并且新增更多,以建议的方式来帮助那些有技术头脑的产品经理。

首先,让我们声明你不需要拥有技术背景来成为一个优秀的产品经理。我曾经合作过的优秀产品经理中的一位他的知识背景是历史。以MBA为中心的、高商业悟性、非技术出身的成功的产品经理比比皆是。并且 — 技术背景,对于一个即使是在高科技行业中的产品经理来说,也不是成功的保证。

技术产品经理的工资数据

去年12月,我们从Pragmatic Marketing的产品经理年度薪资调查分析了薪资调查数据。在那次分析中,我们发现:

product manager compensation by experience, title, and tech [点击看大图]

结论
技术产品经理们,至少那些比较资深的,比非技术产品经理得到更少的报酬 –当你仅仅看标题的时候。然而,有技术技能的产品经理总体比没有技术技能的产品经理获得更好的报酬。对于这些数据的一个解释可能是在技术技能帮助你在任何产品管理角色上赚得更多的同时,技术产品经理的角色通常赚的较少 –可能是由于职责范围的理解或影响。

注意到有两个“technical product manager”变量。其中一个是自我陈述的技术专业级别(从非技术很技术),另一个是职务名称(有三个选择:产品经理、产品营销经理和技术产品经理)。调查分析这个链接包括了更多详细内容,分析和看法。

如果我们觉得这些产品经理比较那些产品经理相对来的成功,那么我们可以得出结论:技术背景能够帮助你成为一个更加成功的产品经理(忽略产品营销经理和技术产品经理的数据),但是仅仅在拥有10年的经验之后。可能对于技术导向的产品经理来说需要花费很长的时间来吸收那些重要的软技能。

SVPG的建议

SVPG关于从工程技术转向产品管理的文章是篇好文章。阅读它以获得更多信息.
简单的说,作者给出了半打建议,所有的建议对于担任产品经理角色的工程师来讲都很重要。同时也要注意到文章作者也相信这是个强有力的结合:

不管怎样,我所知道的许多最好的产品经理们来自工程技术,并且在本篇文章中,我想宣布我所发现的对于工程师在他们开始转变时所遇到的主要挑战。

意识到工程师有一个很大的优势在于他们通常对于现在什么是可能的有很深刻的认识。如果他们能把这些与对用户的深入理解结合在一起,并且发展出一些新的技能,那么你已经获得了成为一个优秀产品经理和设计优秀产品的基本素质。

SVPG的建议 (在这里改写并且缩短,而且链接是我们的)

  1. 要知道你和你的用户是以同样的方式思考。

    “Cooper 称程序员为 单逻辑,
    来把他们和正常的用户区分开.因为程序员懂得计算机如何工作,他们对结果与其他人相比有着非常不同的期望。”公司可用性认识的8个阶段

  2. 要对你的用户换位思考 (记住,他们不是工程师).
  3. 不要关注在(那是你的老工作)优化开发者的便利,- 关注在优化用户体验.
  4. 学会谦卑 – 人们不会总是对你的产品创意想表现出你所期望的那种反馈。
  5. 精炼你的争论风格来处理不清晰的情况–有的时候并没有所谓的正确答案。
  6. 在和你的工程团队合作时,不要退回到老习惯中,让他们来做工程技术。

一个现实世界的例子

这里是一个经过编辑的(用来保护匿名者,并且集中精力在拥有技术技能和产品管理上)我和我的读者之间交流意见的版本。

产品经理

我非常喜欢产品管理工作,并且很擅长于与客户和跨团队之间的关系搭建。但是,因为我有一个非常强的技术背景,并且由于在我们公司的实际情况,我的责任在实际上变成为业务分析员角色 –更多的关注在产品规格胜过在产品策略。

我正在努力的树立个人品牌。开始时,我抗拒回退到一个更加战术性的角色,但是后来发现你可以在业务分析员和产品经理的界线之间自由的切换。也许被知道有很强的技术实力也不是很坏的事情。我现在的角色是我第一次作为软件厂家的产品经理,因此我能够用上一些我的想法。

Scott

有技术技能对我来说已经证明是一个巨大的资产,虽然它随之带来一些风险。每一个软件项目都要求一个连续的思考 – 从“问题是什么?”,“为什么它有价值”,到“我们怎么实现它”。作为产品经理,我们不得不关注在价值和公司的战略。这是一个大的图景的决策,关于选择什么问题值得解决是大头,它的软件设计和实现是“尾巴”

指定正确的战略决策要求我们理解问题的价值和解决方案的成本-根本上讲是投资回报率(ROI)。针对一个价值1000万的问题开发一个耗资500万的解决方案来比花费9900万在一个价值1亿的问题上要好的多。所有的产品经理必须能够清晰的说明问题的重要性-并且我们能够用最少的技术深度做到这一点。在这里技术深度帮助辨别用来降低问题大小的解决方案(可以认为是机会成本)。这样我们可以高效的验证。

举个例子:如果很多公司花费10%的收入在订单的处理,那是一个非常大的机会。并且我们的目标市场是垂直型的公司-例如医疗赔偿,典型的收录是1亿,这样对于每一家这样的公司这是个1000万的问题。然而,拥有技术技能,我们能快速的知道已经有耗费10万的解决方案存在。通过分解问题,我们能够想象结合一些开源软件来“基本地解决问题”。这意味着在价值$1000万(每个客户)的需求的同时,有仅仅需要10万成本的可以接受的解决方案。同样的结论也可以以另外的方法得出,不需要技术能力而是通过知道已经有一个厂家在计算机领域解决了类似的问题。不管是那种方法,我们要从某个能概念上的解决它有多容易中分辨出问题的大小。这样的防止我们实现一个$500万的解决方案并且很快会被其他人所替代。

技术深度在查看成本和解决方案的可行性时可以更加容易地制衡。我们必须不仅要校验我们解决的问题的重要性,而且要校验解决方案的可行性。我们需要同时与我们的客户以及我们的实现团队沟通。我的经验是我能够平衡利用我的技术在获得交付团队的信任和促进与这些团队更有效的交流上。并且我能够对他们理解我询问的问题和我明白他们的响应上更加的自信。 它偶尔帮助我能够在交流中对于“这样的方法有用吗”这样的问题能够“清除云雾”。

我不是在说我专门成为设计师的角色,仅仅是指出在交流想法时能够偶尔帮助实施团队产生他们自己很棒的主意。并且帮助我建立更加高效的关系。

在充当“演示小子”的角色或者在一个客户来访时, 技术深度再次帮忙。在RFP/RFQ响应的会议室里经常有技术背景的“守门人”和“影响者”。他们偶尔会挑战一下一个应用的技术途径,或者表达为什么“他们的问题太难了”或者“不符合”。当他们是正确的,我能够帮助我们达到一样的结论,并且决定是否是时候增加新的特性,或不同的客户。 当他们是错的,我也能够帮助他们明白并且协调他们作为传递一条“他们的产品能够为我们所用”的内部消息给他们的手下的人。

我在前面提过它是有风险的。 风险在于我过分的强调了技术工作,甚至将它优先于其他事情。策略产品管理是我们必须做的-并且实际上也是正确的 – 如果我们不做,谁做? 因为我们能够回答技术问题,这里存在一个风险是我们会不断的提出技术问题。对我来说办法是在通过两种方式平衡我的技术:
1) 提高我的理解能力
2) 和技术人员交流

我积极的避免在与非技术人员的交流中展露我的技术。风险在于他们开始依赖我。

技术产品经理

您的思想也有很多与我的经验相响应:

  • 曾经有几次我能够使用技术技能,就像您所说,用对可能的解决方案的想法“清除云雾”。有的时候想法卡住了,有的时候这种方法没起作用有很好的原因。不管结果是什么,内部的改变是有趣的,并且在最后,我们都更好的理解为什么在从一个技术的角度选择一个特殊的途径。
  • 关于展示技术技能的“风险”是很好的观点。有些时候我和非技术人员交流太多技术,我发现很容易被归类成一个纯战术的科技家伙。然后,当你被建立与这些技术技能联系,你就很难在和那些人交流中往前走。
  • 你关于问题大小和解决方案的测定的例子很有意思。你强调提供可接受优势的解决方案。竞争门槛是由手边的对问题最有性价比的解决方案决定的。我们作为产品经理的工作就是不仅仅找到市场问题的解决方案,而且要找到问题最高性价比的解决方案。这是一个很明显的事实,但是我没有以竞争进入门槛和可接受的竞争优势的方式来思考它。

我的角色更多的集中在执行 — 确保我们准确的理解了需求,从理解市场问题到用例和框架。对公司来说目前的第一优先级是使我们的平台稳定下来,其中很大的一块是对我们的需求要非常的清晰。我将参与到总体优先级讨论,但是我现在更多地关注这些优先级的执行,胜过优先级本身。我听说我现在所作的称为“需求分析师”。

再次,谢谢您的回复,我们会继续关注您的博客。

Scott

再次感谢这个很棒的讨论,有你们阅读Tyner Blain – 真的让我很开心。

谢谢你们阅读Tyner Blain – 它让我每天都很谦逊和兴奋。

诚挚的。谢谢。

——————————————————————–

本以为翻译一篇文章很轻松,没想到那是相当的累。

————-我是坚持 的分割线 广告时间———————–

[hao8ma竞猜]你知道邓小平的三个名字吗?

——————————————————–

发表评论

电子邮件地址不会被公开。 必填项已用*标注