【产品管理】产品管理堆栈

“该死的，墨菲斯。不是每个人都相信你所相信的。”

“我的信仰不需要他们这样做。”

矩阵

有很多文章、博客文章、视频、播客和书籍描述了理想的产品堆栈。其中一些专注于产品战略，一些专注于执行，一些专注于两者兼而有之。有些比其他（软件、硬件、服务、运营等）更适用于某种行业或产品。有些比其他的规模更好。它们都很好，它们都很有用，而且它们都很好。

多年来，我对适合我的产品管理堆栈（简称“PM 堆栈”）形成了自己的看法。我所说的 PM 堆栈是指对管理产品及其相互关系的大的、不可协商的元素的全面视图。我所说的开发是指涂鸦、白板、尝试、测试、烧伤手指、精炼、进化、自学 Canva 并绘制可接受的图表。在与利益相关者、同行和 IC 沟通时，我使用了这种观点的不同版本，当然取得了不同程度的成功。

它有点拥挤，很难接受，尤其是如果您不习惯在梦中/噩梦中经常看到它。让我在这里强调关键概念，在以后的文章中，我将解开一些值得注意的概念。

PM 堆栈从顶部的公司愿景开始，到右下角的按需发布结束。因此，它涵盖了产品副总裁/产品负责人/CPO 的开始和产品负责人通常会结束的要点，产品经理的角色涵盖了混乱的中间部分。

没有健全的公司战略就没有有用的产品战略，同样的推理也适用于愿景和使命[1]。这是显而易见的、困难的和被低估的——这可能是我近年来学到的最重要的事情。

右上角不断提醒人们构成良好战略核心的 3 个要素：诊断、指导政策和连贯的行动[2]。

然后我们进入了每个人都相信的有趣的部分，很少有人理解，甚至更少人做对：OKR。我发现，如果关键结果不容易一直追溯到 sprint 目标，那么就存在必须紧急解决的沟通鸿沟。这是授权团队的关键推动力。

从产品路线图到产品待办列表，逻辑分组，如价值流（特别是如果你遵循 SAFe）或主题对于组织工作、抽象细节和理解团队之间的依赖关系至关重要。在堆栈的左侧，持续验证过程确保：

• 只有经过验证的工作才能进入积压工作（稍后会详细介绍）
• 对于主要功能，在投入工作之前会进行构建/购买/合作伙伴分析[3]
• 用户反馈、见解和分析反馈到工作流中

产品积压由史诗、用户故事（为内部或外部用户提供有形价值）、促成任务（“幕后”工作、工具、研究高峰、技术债务）、想法和错误组成。请注意，持续集成并不自动意味着持续交付。它有助于将交付与集成分离，使用分支 [4] 或功能标志 [5]。

我相信对于每个产品负责人以及产品、设计和工程团队中尽可能多的人来说，对 PM 堆栈有一个高层次的理解是必不可少的。它可能是我在这里提炼出来的，或者类似的，适应公司/行业的现实。在 PM 堆栈中，产品负责人可能专注于大型组织的不同领域，或者在雄心勃勃的初创公司中做任何事情。

参考资料/延伸阅读：

1. Recent tweet by Melissa Perri. For more read “Escaping the Build Trap”.
2. “Good Strategy, Bad Strategy” by Richard Rumelt.
3. An example of a Build vs Buy framework is here. I use an adapted version based on the same approach.
4. Trunk Based Development
5. Feature flags
6. “How to Define Your Product Strategy” series by 

   Gibson Biddle

原文：https://medium.com/product-leadership-journal/the-product-management-st…

本文：https://jiagoushi.pro/node/1994