根据Wrike产品团队的说法，我们将继续讨论成功的产品经理的关键素质。 在本系列的第六部分（！）中，我们将与Anton Stozhko交谈。 Anton担任副产品经理已有1.5年的时间，从客户支持团队迁出。
嗨，安东！ 我建议立即从一个关键问题开始：您认为想要成功担任产品经理的产品经理的三个主要素质是什么？
-最重要的是计划和确定优先级的能力。 计划和优先重点不是产品管理，而是个人文化甚至卫生。 该计划很重要，因为它有助于与未知事物作斗争，很少有人喜欢它，而大多数人都试图避免它。 但是，如果您想发展业务，就必须应对。 优先级很重要，因为永远不会有资源来完全完成所有事情（好消息-这不是必需的）。 最主要的是在适当的时候做最重要的事情。
-以及如何发展这些技能？ 是否可以说它们来自对您的团队和您的业务所产生的责任感？
“好吧，当然不是因为发生的一切，而只是因为您负责的领域。” 您可以像其他任何事物一样通过重复来开发它们。 一个小警告：在您自己成为产品之前，很难学习如何制定良好的计划。 这种或那种活动的需要不是特别明显，真正的价值尚不清楚。 Wrike在这里使我感到震惊：我意识到没有那么多的个人时间，而且优先任务的列表往往是无限的。 在我开始的支持部门中，我仍然有很多请求队列。
要开发这些技能，您需要尝试将这些原理应用于所有发生的事情。 当天的案例，假期计划，对来自三个或四个渠道的消息的答复，季度的团队计划。 接下来，您需要学习如何将技能转移到其他人的活动上：团队及其计划，产品经理及其愿景。
我注意到，计划和优先级排序的强大动力使人们能够首先想象“完美状态”。 完成工作后，就可以做出决策，解决功能，实现指标。 在某个时间点在头部形成理想状态后，就可以开始放松球了。
-以及如何放松？
-当然要问问题。 这只是第二项关键技能，即向自己和他人提出问题的能力：“您需要什么才能做到这一点？”，“缺少什么？”，“对于没有上下文的人来说，这是不可理解的？”。 大而口齿不清的问题会倒退为小而具体的问题。 同样，不要一次全部回答。 记住第一个原则。
提出问题的能力的重要性可能已写在有关该产品的所有书籍中，但重点是“为什么？”问题。 我不会争论-客户研究是一个有用的话题，但是其他问题同样重要。 利益相关者通常对“什么和什么时候？”感兴趣，团队对“为什么和什么顺序？”感兴趣，每个人都对“什么以及为什么？”感兴趣。
产品工作的独特之处在于，口袋里的答案总是比问题多。 但是渴望获得答案是与常规作斗争的秘密。
-作为策略的一部分，作为产品的所有者，您需要在多大程度上制定任务？ 您是只广播一般性愿景还是其他一些特定的事物？ 例如，当他们向您求助时，情况就是典型的情况：“我们希望产品的这一部分像这样”。 然后，您组成一个团队，说：“伙计们，这样做吧。”
-我最喜欢锤子和铁砧的隐喻。 产品在这里生活，在那里它们相遇并散发出火花。 锤子是自上而下的运动。 这里是高层愿景，战略，OKR，有时还有非常具体的任务。 洞察力以不同的形式出现，其重要性和复杂程度不同。 这些都是欲望。 铁砧是自下而上的运动。 这是代码库，资源，团队成员的心情，当前优先级和现有计划。 这是现实。 在欲望满足现实的地方，必须同时管理两者。
因此，问题的答案是：“这是怎么发生的？” -“以不同的方式！”
碰巧您从高层经理那里解开了一个主意，并了解到某种流程可能具有巨大的价值。 我的任务是识别该值，了解如何将其集成到工作流中，并检查它是否不干扰现有的优先级任务。
碰巧一个非常具体的任务落下了，需要采取并完成它。
顺便说一句，从深度上讲，直接由思想，洞察力或策略设定的任务只能通过近似度和复杂度来区分。
-请告诉我，就Wrike而言，产品和关联产品有什么区别？
-首先，这是您做出决定的级别。 看：我来担任副产品经理，我的经理对我说：“让我们日历，以便使用Wrike的营销机构感到满意”（我的意思是Wrike产品中的“日历”功能）。 我回答：“好吧，如果我们看到了它们，那么它们应该像那样。 应该有过滤器，建立用于共享的外部链接的功能等等。” 我描述了尚不存在的功能的详细信息，但是该功能本身已售出。 对于某些事情，我会得到批准，而在某个地方，我会回答其他问题。
同时，该功能将如何运行以及为什么需要它-每个人都可以理解。 因此，在此阶段，您将获得以下形式的任务：“来吧，做吧。” 团队的运营管理取决于您，积压的工作量由您承担。 这不是产品的主要组成部分，而是一个很好的出发点。
填充积压很多知道如何。 写下功能制作后如何工作，然后与开发人员讨论的过程并不复杂。 接下来的所有事情都是评估和计划问题。
我所描述的只是起点。 在决策的下一阶段，您已经有其他问题。 不是“会有什么功能？”，而是“我应该做什么？” 当我开始研究蓝图时，这是我问自己的问题（请注意-产品中的新功能之一）。 没有人告诉我：“制定蓝图并决定它们将是什么。” 有人告诉我：“重复工作存在问题。 我们该怎么办？”
然后是第三级决策。 在这里，他们不再为您指定问题，而是说：“我们认为这里可能存在问题。” 您的任务已经找到了问题。
-也就是说，在第三级，您首先要突出显示问题，然后自己提出解决方案，然后将其全部解决？
-是的 对我来说，它已经看起来像是毕业作品。 当您自己进行研究时，您会理解所有内容，与所有人交谈，将您的愿景与现实融合在一起，向所有人展示一切，并说服所有人。 总而言之，在每个阶段，您总是得到一些介绍。 问题是它们的定义如何。 随着决策水平的提高，巨大的视野越来越广泛。
-知道了 您说过，在蓝图级别上，他已经在第二级决策级别上工作，而在第三级上已经解决了入门问题。 是否有第四，第五级，依此类推？ 还是还有终点？
-第四个大概是当您有一组产品经理时。 在Scrum团队中工作不再是您的例行工作，您将拥有一个由产品组成的新团队。 他们每个人都有他们要解决的某种愿景和问题。 利用这些产品的实际情况，您的任务将变成有效的欲望管理。
也就是说，从本质上讲，扩展的范围更广：需要接受的视野数量增加。 这要归功于委派。 在第四层上，您需要确保现在处于第三层的人向您提供这些建议和演示，在此基础上您可以做出决定或提供建议，以使车轮旋转。
-好 让我们回到原来的问题。 您已经提到了计划，优先级划分和提出问题的能力。 您认为成功的产品经理的第三项素质是什么？
-正如我的导师喜欢说的：“唯一的产品资源是与他人的关系”，即沟通。
-作为沟通技巧的一部分，您每天必须处理哪些问题？
-在日常工作中，存在两个常见问题：沟通不畅和沟通不足。 信息要么接收量不足，要么转化为恶性肿瘤。 结果，进行了额外的移动，并且某些过程停止了。 纠正这两个都是额外的费用。
这些问题可能在任何级别上都是相关的。 级别越高，修复成本就越高。 Scrum命令中的一个示例：员工不在计划中，信息也没有传递给他，或者产品的生产行为被歪曲地规定为完成。 什么都可能发生。 结果，Sprint的任务尚未完成所有步骤，因此可以将其用于开发。 假设它的开发非常简单：他们实现了它，然后发现它要么开始做得太早，要么根本不需要做。 下一个乐趣是团队或部门之间的沟通管理。
-我想问几个问题。 请告诉我，您的背景最初是否是原始的？
-不 我一生中从未写过任何代码。 好吧，也许是100年前在BASIC的6年级计算机科学课上。 在我的工作中，这不是关键因素。
-许多人在这个问题上意见分歧。 您认为拥有技术背景会帮助您成为更好的产品经理吗？
“这将帮助您关注开发人员的事务。” 如果这对他们有帮助，那么这是一个加号。 如果这阻止了他们，或者您无法更快，更有效地完成工作，那么这就是一个缺点。 无论如何，该产品并不是孤零零的狼。 我喜欢《权力的游戏》中的一句话：冬天来了，孤独的狼死了，但狼群得以幸存。 这关乎团队中游戏的价值。 我不需要懂JavaScript，但是他们需要知道如何填写杂货店简介。
-如果您不完全理解某个主题，那么您会向团队提出问题并根据他们的答案做出决定吗？
-这正是正在发生的事情。 我坚信我们正在做最重要的事情，而且我知道这要花多少钱。 我应该始终牢记并将复杂性与结果相关联。
这是通过特殊的余额系统在每个步骤上设置的，在该系统中，您必须查看将这一步骤与将产生的价值相关的成本是否过高，如果您没有错过可以从中获得很多价值的步骤，同时又要它便宜。 这里的重点是我确定获得的价值量-这就是我的余额。 开发人员要权衡成本。 我们进行沟通并确定要采取的步骤。
-也就是说，可能出现以下情况：您进行研究并找到一个价值巨大的点。 然后，您来给出所描述的问题或解决方案，然后开发人员告诉您，权重太大且难以估量。 然后您可以拒绝进一步处理此决定，对吧？
-在这种情况下，所有希望都寄给开发人员，因为单位价值无法更改。 但是也许有机会改变单位成本。
它通常取决于您如何解决问题。 您可以说：“我们需要确保可以在重复任务中复制重复子任务。” 您可以在另一方面进行一些操作：“当存在子任务时，我们正在尝试解决问题，我们需要使其得以解决，以便在父任务中对其进行定期创建和记忆。”
陈述的任务看起来非常相似。 但是在第一种情况下，我告诉开发人员他们需要修复重复性任务的现有机制，在第二种情况下，我没有进行此类限制。 还有语义。 不是“必要”，而是“我们”。 提出问题非常有效，而解决问题的方法则是团队的职责范围。 这是他们的创作自由和实现自我的可能性。
-如果他们提出了解决问题的几种方法，那么谁能估算出最好的方法呢？ 蒂姆利德？
-我很感激。 此外，如果我不了解哪种解决方案更有效，则意味着我没有向团队提出必要的问题。 顺带一提，这使我想到了一个非常重要的话题-有关团队。 使团队超越目标很重要。
当然，在某些情况下，可以设置例外。 例如，如果设置了一个非常紧迫的截止日期，该截止日期是从外部设置的：为大客户进行紧急开发，为战略合作伙伴发布版本，您需要与之同步集成输出，等等。 然后我们只需要坐下来做就可以了。
但是您常常会发现，截止日期比参加会议的火车要软一些。 然后，您需要选择团队的一面。 在Wrike中，我真的感觉到了，因为动摇团队比改变产品要昂贵得多。