最近我放了一个小 评估工具 用于产品管理团队。该工具旨在引起讨论并突出团队改进的领域。几名PM遵循“如果我们在特定项目上的评分不佳怎么办?我们该怎么办?”的后续评论和问题。

没有通用的改进处方,尤其是在产品管理方面。不过,值得深入研究一两个项目,并想象我们如何分析情况并采取纠正措施。 

就上下文而言,假设我们是产品管理总监,他的团队在自我评估中的得分很低 开发部将产品管理视为客户的主要代理。” 有多种可能的根本原因,例如...

[1]发展可能是正确的。产品管理可能缺乏真正的客户洞察力。

这是一个很难的诊断,但可能是准确的。有些产品经理只是 没有调入 他们的市场/客户/用例。如果这是整个部门的系统性问题,那就更严重了,在这种情况下,我们需要采取果断的行动,包括:

  • 将PM带到现场以延长与客户的聆听时间(会议室中没有销售人员)
  • 输赢电话和管道审查
  • 与渠道合作伙伴的实况调查
  • 坐下来与技术支持

等等。如果我们不代表市场需求以及客户和潜在客户,我们应该挂起钉子回家。  (希望我们的问题是另外一回事。)

[2]产品管理具有深厚的客户知识,但并不共享。

我们的工作包括 感知的 作为市场专家以及 存在 市场专家。如果我们不销售我们所知道的东西,那么可以原谅开发人员在其他地方寻找东西。检查项目经理为共享和活跃对话创造机会的频率,例如:

  • 通过电子邮件将客户访谈发送给扩展团队
  • 带(表现良好的)工程师参加客户简报会,或邀请客户参加开发团队
  • 为用户故事,角色,市场地图添加丰富的细节
  • 带上披萨参加PM领导的午餐和学习课程。 (食物是很好的出勤动机。)

您知道当工程师开始将您的链接和文章转发给团队中的其他人时,您已经成功。

[3]工程师对我们的目标细分市场或客户感到困惑。

技术人员自然可以想象客户就像他们自己一样。如果您的目标用户是消费者或非专业IT公司人员,则开发人员可能会拒绝您的描述和要求。  (“每个人都知道如何编写简单的SQL语句。”“ Web服务始终是异步的。用户知道不要多次按下SEND。”

说明收入取决于其他类型的客户。详细的角色和一些用户的现场会议可以帮助您保持期望。

等等。 注意 我们的行动计划取决于明确的根本原因分析。一旦确定了他们的担忧,我们就只能解决为什么我们的开发人员可能会考虑我们开发轻量级产品的原因。在我们展示出价值和能力之前,不要以为技术团队了解产品管理(或非常在意产品的详细信息)。

声音字节

在找到解决方案之前,请深入挖掘真正的根本原因。