如果像我一样，您来自Marty Cagan产品开发学院，那么您熟悉作为负责定义和交付产品的核心团队的三体构造。三体是三个角色的简写，它们相互平衡，各自负责不同类型的职责：
- UX Designer：确保产品可用。这可以包括从可发现性到工作流连贯性，从解决实际用户目标到设计漂亮 UI 的所有内容。
- 工程师：生活在可行性领域。根据用户的预期需求，推动技术决策并确保实施是可测试的、可操作的、可扩展的和可维护的。
- 产品经理：对价值负责。这包括对业务的价值（推动采用或收入是常见的例子）以及对用户的价值。
如果我们作为产品经理对价值负责，那么有什么比为产品添加新功能更能创造价值呢？在许多软件公司中，这是衡量成功的最终标准，而激励措施的结构不成比例地围绕着交付新功能（输出）而不是实现用户和业务目标（结果）。
我认为，如果产品经理将他们对价值的理解限制在这个精简的定义中，他们将在未来为自己和他们的业务感到心痛。
我们可以很直观地认识到三体的角色之间的相互依存关系以及他们各自关注的问题。
作为产品经理，我们明白，如果没有工程，我们将不会交付任何东西。
或者说，如果没有设计，我们可能会在实施过程中出现 "开发人员的艺术"，而不会让我们的用户感到兴奋。
在没有产品经理对商业价值负责的情况下，工程和设计会知道哪些投资会产生最大的影响吗？
但是，我们对彼此的依赖比这要深得多。
走出你的习惯
产品经理负责 "什么"，工程师负责 "怎么做"，这是科技界的一个普遍说法。
在粗略的层面上，这是一个很好的指导方针，但如果我们希望我们的产品能够长期成功，我们最好都能关心如何做。(我不是在说围绕技术栈的决定，这些决定最好留给工程方面的专家。)
对于产品经理来说，有一个真正的危险，那就是过度关注新功能的交付，而没有考虑到这样做的成本。
除了少数例外，我们在产品上增加的每一平方英寸的表面积都会增加其复杂性，并降低我们快速行动的能力。所有的代码都需要被审查，被测试，被保护，被扩展，被修补，被维护，被运行，最终被废弃。通过代码库的途径变得越来越繁琐，因为条件逻辑被楔入，以（希望）使所有这些功能都能很好地一起运行。
这也适用于设计。信息架构是一个经常在急于推出新功能的过程中受到影响的领域。
当我们的产品很小的时候，我们可以故意设计优雅的导航和工作流程。在我们急于增加下一个很酷的东西的时候，我们往往会忽略为用户保持这种一致性所需的投资。