用于解释产品管理概念的最佳 5 个图表

产品经理有很多责任和责任。 产品经理不仅需要通过创建路线图来制定战略，还需要向团队阐明新产品的发布周期以及介于两者之间的所有内容。

他们还需要具备了解如何确定优先任务并相应地管理团队的专业知识。 不仅如此，移动产品经理还有责任分析添加到产品（移动应用程序）的功能以及它们是否与客户的目标同步。

总而言之，与产品相关的每个流程、活动和决策都由移动产品经理同步和调整。 帮助这些产品经理实现其 KRA 的是一套特定的技能。

现在，显然他们将被要求向他们的团队成员解释某些产品管理理念，以便他们都在同一个页面上。 但是，令人疑惑的是——他们如何解释所有的产品管理概念和关键思想？

好吧，我认为一些对产品经理有用的图表可以解决问题。 如果您有兴趣了解这些图表是什么以及移动产品经理如何以及何时使用它们，请坚持到底。

图 1 – 通信瓶颈

据了解，作为经理，您需要了解团队中正在发生的事情以及团队成员如何管理他们的任务。 但是，任何人都参与到每一次沟通和决策中都是可笑的——一个人不可能一个人处理所有的事情，对吧？ 这不就是代表团被发明的原因吗？

现在，您很自然希望参与所有重要的团队间/团队内对话，但您需要反思一件事——有必要吗？ 是不是应该把其他责任放在一边？

答案是——分析团队是否有能力进行不依赖于你的沟通。 如果是这样，您需要做出一些有意识的决定，以确保流利的沟通等重要事情不仅仅取决于您。 下面给出了一个可以有效解释该案例的图表。

比方说，Web 工程师需要与产品分析师讨论一些事情，然后 PA 说他们需要在这方面与 iOS 开发人员讨论一些事情。 现在，Web 工程师最好直接联系 PA 和 iOS 开发人员，而不是依赖 PM（如左图所示）。

左边的图表显示了团队对产品经理与其他团队其他成员沟通的依赖——这会对工作流程产生不利影响并减慢它的速度。 右边的图表显示了一个不依赖的高效沟通流程，立即消除了不必要的联系点。

图 2：瀑布与敏捷

尽管互联网上有很多资源参与了敏捷与瀑布方法的辩论，但它对于产品管理来说似乎仍然是一个模糊的概念。 因此，让我们清除模棱两可的迷雾。

众所周知，移动应用程序开发的成本是根据开发该产品所需的时间来计算的。

现在，如果那个移动应用程序开发公司的产品经理选择使用瀑布式方法（即产品的大版本），这意味着产品将一次性推出。

现在，当一个产品发布时，它有望成为一炮而红——这在这种情况下并不容易，因为产品是一次性推出的，而且肯定会引发一些问题。 他们从这个版本中获得的价值将不等于开发人员所做的投资（时间）。 这是因为他们需要从一开始就解决问题。

相反，支持小版本和迭代的敏捷方法将显示即时的价值结果，因为您同时识别和修复错误。 上图清楚地显示了选择这些产品管理方法的最终结果的差异。

图 3：交货规模的表示

当谈到按时交付产品时，它是整个开发过程中非常关键的部分。 从字面上看，它可以成就或破坏任何移动应用程序的未来。 如果上市时间过长，其他一些应用程序可能会占领市场，这会使有问题的移动应用程序徒劳无功。

以下是开发应用程序时采取的举措规模的表示 -

左图显示了仅处理大型项目（同时处理大量工作）的交付规模的吞吐量。 绝对清楚的是，只在一个产品的大项目上工作会在未来的某个时间点造成障碍，因为这些项目需要更多的时间、注意力、资源等。如果出现任何问题，影响将是对整个过程造成破坏，不可避免地会增加产品上市时间。

{另请阅读我们关于“项目经理与产品经理：差异、角色和挑战”的文章}

右图是一个经典的“待办事项”。 采用敏捷方法的优势也波及到产品管理流程的这一阶段。 这种方法提倡将执行小任务与大量工作（蓝色）相结合，我们在 Appinventiv 也遵循这一点。

如图所示，与左边的不同，这里的小块工作（粉红色）可以轻松通过漏斗（可以轻松完成）。 如果这些证明是成功的，产品经理可以继续这个想法（黄色圆圈）并完全投资。 如果情况并非如此，那么他们可以再次迭代并进行相应的投资。

{查看这篇关于“产品经理必须准备的 10 个最重要的文件”的详细文章}

图 4：领导参与程度

下图包含两个模型，用于阐述这个产品管理概念。 左边的一个显示计划规模、一次完成的任务数量以及其中的风险因素，另一个涉及与这些任务和计划相对应的产品经理（领导）的参与程度。

左边是团队要执行的任务/计划的金字塔。 金字塔的底部意味着同时执行许多任务，右侧的图表显示了这些低风险甚至无风险的琐碎任务的参与程度。

当我们移动到金字塔的顶部时，任务的数量会减少，而与这些任务相关的风险也会增加，这是必须咨询产品经理的地方，而在形成过程中，他/她可以被告知。 该图不仅可以帮助移动产品经理，还可以帮助团队成员了解何时依赖领导。

图 5：分析分割值

有一些组织习惯于遵循的做法。 其中之一是优化平均值而不是细分的习惯。 这意味着，他们倾向于关注平均水平，而不是需要改进的特定部分。

在目标和假设相当广泛的情况下，产品经理和开发团队很难通过产品产生影响。 这是因为你在这里试图同时满足各种目标，这根本不可能。

图表（如下所示）是一种分析每个部分以识别哪些部分正在影响其他部分的表现的方法。 这一切都是为了解决普遍存在的问题。

上图由三个假设的实验 1、2 和 3 组成，分别是 A、B、C 和 D 段。在三个实验中，在第一种情况下，A 段有上升，随后下降第二种情况，第三种没有变化。

单独来看，在实验 1 中，除了 B 部分，A 部分与其他部分表现良好。现在，该图突出显示了与其他部分并列的该部分的下降。 这可以帮助产品经理找到发生这种情况的原因，从长远来看最终会提高平均水平。

类似的情况发生在实验 3 中，其中 A、C、D 段在显示出显着变化的对立段 B 中表现不佳。 同样，一项研究将阐明发生这种情况的原因。

这些对产品经理有用的图表可以很容易地根据自己的需求进行定制，无论产品经理在哪个行业工作。就 Appinventiv 而言，我认为这些模型确实有助于我们的团队简化流程并保持内部人员之间的开放式沟通/团队内。

经常问的问题

1. 什么是产品管理框架？

所有的框架本质上都是产品管理生命周期中使用的工具。 它们用于各种目的，例如说明产品管理思想和概念并促进其他任务。

2、产品管理流程是怎样的？

产品管理过程包括不同的阶段。 它包括——创意管理、路线图、添加和确定规格、优先级、交付、分析和用户反馈。