如果将没有产品经验的经理放到产品经理的岗位，会发生哪些问题，又或者说，会导致转型项目出现什么问题？这篇文章里，作者发表了自己的看法，一起来看一下。

将一个毫无产品经验的经理放到产品经理的岗位，对于整个组织来说是个大问题。

想象一下，你是一名频繁加班的技术支撑经理。你的日常工作包括解决客户的技术问题、回答用户的查询、协助用户设置和使用软件，并与开发团队沟通用户反馈。你对软件的了解主要停留在用户交互和软件功能层面。

然后有一天，公司决定将你提拔为研发经理，负责管理一个小规模的开发团队。之前的技术支撑部门依旧你的职责。惊喜吧，你现在全职负责一个产品的开发销售全过程，尽管你没有读过计算机专业，或者自学过软件开发。尽管你对产品和用户有丰富的经验，但你需要适应新的技术管理角色，包括领导开发团队的日常工作、确保产品的创新和技术的可行性、确保项目按时交付，并与高层管理层共同制定技术战略。

你成功的机会是多少呢？在没有直接的技术管理经验的情况下，你是否能够胜任新的领导角色？同时，你是否能够保持原有技术支撑部门的工作，确保产品的维护？

你现在还能够胜任之前的技术支撑经理的工作吗？你对自己在新的研发经理角色中的表现有什么期待呢？这一变化是否会影响你与产品团队和高层管理层的协作方式和质量呢？

假如这个难以想象，让忙碌的专业人员去承担另外的具有挑战性但是毫无经验的角色，在当前社会和工作环境中，实际上这种情况经常发生。

一、转型的承诺与挑战

我曾经参与多个敏捷和产品转型项目，其中包括过去五年参与过的三个。除了少数例外，我看到的更多是项目团队层面的崩溃。 项目推进因为团队不知道构建什么，如何构建，没有也不知道从哪里获得工作需求，或者不知道下一步该做什么而停滞。这并不是因为他们工作不够努力。督促他们多做一些，或者再努力一些并不能长久地解决这些问题。

如果我们打算解决这个症结，正确地定位这背后的真正原因，我们得回到产品鸿沟的概念上，即对“产品这个角色”的重要性缺乏基础的理解。 一个简单的决策失误可能由关键方向决定，从而产生滚动性的影响导致每个人都失败，导致组织无法获得期待的转型收益。

二、承担一个新角色

很多聪明、经验丰富、有能力的人被安排承担产品的角色，然而他们经常无法成功的主要原因有三个：

1. 他们根本没有足够的时间；
2. 他们没有必要的背景或技能；
3. 把他们放在这个岗位角色上的经理不能很好地培训指导他们提高绩效。

以上三个因素一起造就了产品鸿沟。 有些幸运的人通过了敏捷产品负责人认证（CSPO）培训，然后两天后就理解了一个产品负责人在敏捷团队中的职责。 但是，这并不会让他们获得在产品管理中取得成功所需的工具。

三、产品负责人还是产品经理？

当他们敏捷团队承担“产品负责人”角色的时候，他们已经正式开始了产品管理职业生涯。 很多被任命到这个角色岗位的管理者，是通过在传统、自上而下的工业管理方法上获得的成功而获得这个岗位的。 但是想要在现代软件开发中取得成功需要从根本上不同的思维方式，技能以及能力。

四、为什么产品角色一直被误解？

很多转型中的组织机构的领导认为产品角色是“兼职”的管理职责。 不管正确与否，这些高级领导认为只有他们信任的直接下属是最佳人选，他们最适合根据他们的需求做出正确的决策。 并且，很确定的是他们不在意多做一点工作。

现在，做决策的背后实际上是有可行性的商业原因的。 也许这个组织不太确认他们是否要全力致力于转型，更倾向于在低层次上先尝试。 但是因为他们双方都没有意识到这个角色需要的一切，他们认为他们可以拥有一切，既在他们以前的“业务惯例”角色中继续工作，又能够管理产品。

1. “产品鸿沟”涉及的干系人

• 执行领导：我找到了合适的信任的人来担任这个角色；我不确定产品角色包括什么，但听起来对我来说有点像“管理”的感觉，我有一个非常合适、值得信任的人可以安排到这个角色。
• 已经很忙碌的高级责任人：不确定是什么，但是我得给我领导搞出来；我喜欢对我的领导有所贡献。
• 团队组员：等待产品指导和领导；有很多决策要做，我们先做什么？

2. 团队尝试填补这个产品鸿沟

有时，团队中另外一个经验丰富的人能站出来，弥补这个鸿沟。 也许一个BA（商业分析师）可以通过编写需求文档或者通过促进与团队的细化来支持产品角色。也有其他情况，开发工程师、设计师或者敏捷专家/教练可以提供帮助。 但是这又给其他和他们本来应该承担的角色造成一系列的挑战。

3. 对未知的信息缺乏了解

但没有人会了解到必须做出的牺牲或不得不削减的地方，因为很少有团队中的任何人说出来。 当他们这样做时，往往被视为一种抱怨。 因此，缺席的产品人并不知道他们给团队带来了怎样的压力。 尽管他们拥有多年的知识和经验，但他们和他们的经理都不了解产品人员被期望处理的关键事务。 结果，他们只看到他们的团队陷入僵局，却不知道他们如何促成了这一破裂。

更糟糕的是，他们不知道随着更多的项目组在同样的领导力下挣扎的工作会给整个组织带来什么样的影响。

1）转型变的毫无作用

如此，经过几个月的努力零价值交付，领导宣布这次的转型是失败的。 于是，他们解雇所有咨询师以及新雇佣的人，然后把他们的信任经理调整回原来的岗位。 敏捷/产品方法论，在这里没有什么用。 他们如此说道，然后回归到他们以前的工作方法上面了，就是以前PMO办公室主导的模型。

2）时间管理的区别

许多担任产品角色的IT经理将他们传统的公司层级管理方法带入这一角色，着重于与领导层管理政治关系。 同样来自相同的手册/PMO模型，他们要么指挥团队，要么无视他们。 而传统的IT经理可能会将一天中的大部分时间花在与领导层的会议上，产品角色中的成功将需要将时间分配给：

1. 团队
2. 最终用户客户
3. 以及理解利益相关者的需求和限制

为什么呢？

要理解这一点，重要的是要了解软件开发中的两个关键概念：产品三个关键点和四大风险。

五、三个关键点以及风险

1. 产品三个关键点

退一步看，成功的软件产品是通过领导和跨足三个关键视角的协作而创建和维持的：

1. 产品 — 负责确保团队始终提供最大的以客户为中心和商业价值。
2. 用户体验（UX） — 负责确保团队创建易于使用的界面和流程。
3. 技术负责人/架构师 — 从产品和用户体验的角度出发，将它们变为可行、经过测试的软件。

理想情况下，每个角色都会有经验丰富的全职人员。 但只要团队中涵盖了这些视角，它们就不必是个别的人。 在某些情况下，有人可能会承担其中一个以上的角色。有些人可能会通过不同但相关的角色代表产品。在其他情况下，两个人可以共同担任三人组中的一个角色。 但无论它们是如何代表的，如果你希望有望解决四大风险，你将需要这三种视角。

2. 四大风险

1. 价值风险：用户是否认为这款软件有价值，他们是否愿意使用它并持续使用它？
2. 可用性风险：用户能否找到这个功能，他们是否能够轻松地使用它来完成他们想要做的事情？
3. （技术）可行性风险：我们是否能够用我们拥有的人员和技术栈，在我们有的时间范围内构建我们想要构建的东西？可实施性，可实现。
4. （商业）可行性风险：解决方案是否盈利？它是否合乎道德，是否对业务有利？可生存性。

这就是产品三人组如何应对四大风险的方式：请注意，产品角色负责两个最重要的风险。

价值风险（用户）以及商业可行性风险（企业）。

如果这些风险不得到持续关注，裂缝将开始出现。

• 负责产品角色招聘的高级领导：不确定为什么我们在结果方面没有取得太多进展，我一直相信我的可靠人员。
• 已经很忙碌的高级副总裁：就我领导所知，我正在很好地处理这两个角色。
• 团队：我们会尽力协助填补我们能够填补的空缺，但我们仍在等待经验丰富的产品指导和领导。

六、转型不是目标

在这种动态中，执行高级领导层可能并非在追求他们自己的最佳利益，最终可能会使他们自己的议程面临风险。

当产品管理做得好时，它将更高层次的组织战略转化为以客户为中心的最大价值，并付出最小的工程努力。

目标不是转型。而是成为一个更灵活、更有效的组织，能够支持和加速价值交付。

“产品鸿沟”阻碍了这一目标的实现。

七、组织转型的要点

许多高级领导者可能并未充分意识到产品角色对他们战略成功的基本重要性。

如果你正在进行敏捷或产品转型，请了解“四大风险”对你路线图上的所有事物构成的威胁。没有什么是安全的。

并记住产品在产品三人组中扮演的关键领导角色。

强大的产品管理是减少你最大两个风险（价值和商业可行性）的唯一途径。

对于转型领导者：

可能已经陷入困境的组织可以按照重要性顺序关注以下三个关键点：

1. 雇用经验丰富的产品人员。 制定这些招聘决策的领导者可以首先用已经具备合适技能的合适人员来理想地填补产品角色。 如果出于任何有效的业务或预算原因这是不可能的，那么需要做出另外两个重要的选择。
2. 让他们全职工作。 确保无论你决定任命谁为你的产品经理，他们的日程安排中都会有足够的时间来完全投入到这个角色中。
3. 投入时间和资源来培训和提高他们的技能。 确保他们不断获得所需的培训和指导，以达到较高的能力水平，并持续改进，这样他们就可以反过来指导其他经验不足的产品人员。

对于新产品人员：

如果您是产品角色的新手，请与您的经理讨论如何开始将职责从您的工作量中转移出来，以便您可以增加并最终完全专注于该角色。并主动寻求获得快速上手所需的培训和指导。

你的组织正在进行一场转型，投入了太多的资源，以至于不成功是不能接受的。

不管你喜欢与否，你的角色对于成功来说太重要了，无法尝试以任何其他方式做到这一点。